Meeting minutes
wendyreid: Welcome the first f2f of the NEW pmwg
<wendyreid> https://
wendyreid: Quick agenda overview, no real change except the times
… start with comics, mostly focusing on the overall topic. Not really a tech conversion which will be tomorrow
… (see agenda for details)
… no buffer for today, so we may have carryover into tomorrow
… Questions?
Makoto: When will we discuss ISO?
wendyreid: I don't think we will discuss, we are waiting for feedback and reaching out to some folks
Digital Comics
shiestyle: I have a presentation for this. We have already had our first TF meeting last month
Hadrien: Just to clarify, we shouldn't be touching on tech stuff?
wendyreid: Yes, tech is fine but we should be more on the general side, tomorrow will be better for tech (more participants)
shiestyle: In Japan we already use epub for scrolled comics
… We have two approaches both are being used
… There is also a new proposal from Hadrien
Hadrien: just to clarify, I am just proposing 'scrolled' to replace the existing methods
shiestyle: We agreed that this is a new feature
… so the charter is updated for new features
… We still have no conclusion to the method
… Some proposals, first Hadrien's proposal
… second proposal is a new proposal that keeps pre-paginated but adds new metadata
Hadrien: What are we trying to achieve?
… 2 things - we are trying fit on width
… and the other is continuous scrolling
… Scrolling exists, but it is really a hint so it is different than what we want
… pre-paginated doesn't do what we want, flow doesn't fit
… This is a new type of publication
… for instance it doesn't even have pages to pre-paginated is weird
… Since it is a new type, layout makes sense
… We could alias pre-paginated and scrolled to mean webtoons
… I think a new type makes sense
ivan: I do not disagree
… my question is actual practice
… do we have feedback from Amazon and Apple
… will they adopt the new ?
… Are they flexible enough to switch?
Hadrien: This happened with fixed layout
wendyreid: I agree, but I also wonder to take a step back we have an underlying problem in fixed layout
… Since webtoons is chapter based, this exposes a problem. This content is very chapter based
… for instance, rendition flow breaks because we don't really have chapters in pre-paginated
… What if we keep things as they are currently implemented and add better chapter breaks
… How are these actually created? One file er chapter? or per image?
Hadrien: One file per chapter
… It could be used for selling full seasons
shiestyle: Regarding epub structure, webtoons and manga are all the same structure except the metadata
shiestyle: we don't use very long images, so as a result the structure is the same
duga: I was hoping we'd learn more about what is actually being sold on the various platforms. It's hard to think of a technical solution without knowing the business specifics
… it is a single book, are there collections, will there be collections?
… what is the problem we're solving, what are people selling, what do people want to sell?
… it would help to have real cases or an actual webtoon file
… do we have examples?
… where is the industry right now?
Hadrien: It's a complex question, complex market
seth: Is each episode just one image? Are the images huge?
LaurentLM: The people around the table have the freedom to change
… Can we take a new value? Yes, we can add a note and explain that there are other implementations that should be considered aliases?
ivan: So do we have any chance to pass the CR criteria?
Hadrien: Yes, no problem, I am aware of multiple presentations
dhall: We would continue to support for now, can't discuss future
… And agree that fit width is important and we need to be able to specify it
Hadrien: No one today produces episodes as a single image, largely for performance
… no one really divides things on semantic boundaries, they are arbitrarily split
… it is meant to be displayed as a single image, so these are really just tiles
… Also want to point out that html is not really used to display this
… Everyone uses images outside of Apple (not sure about Amazon)
… Back to market question, mostly done in specialized readers
… Mostly this is done by free with ads, or perhaps subscriptions, sometimes there is microtransactions
… much more like games
… Mostly this is done in those apps, not epub readers
… These apps are designed around the model (calendars for upcoming, package purchases, etc)
… almost all done as individual episodes
Hadrien: usually is a giant file or zips of images
… Most places use psd or zip, not epub
… Korea is interesting as they are pushing to a national standard
… they are adopting a Readium approach
… they looked at epub, and thought it was too complex and had too many problems
… so for their archiving work they are using zips
shiestyle: Regarding long images
… some services accept long images, but these are not in epub
… I strongly propose to not add a new value for rendition layout
… we cannot move to the new system until everyone adopts the new values
… In Japan we have a big market, but we cannot shift to the new standard due to compat issue
sue-neu: Does anyone know about the copyright?
wendyreid: Webtoons is ok, webtoon is not
<delackner> You can say kleenexes but not kleenex?
ivan: Why are we doing this? Why not just leave the specialized apps to do it?
… we seem to be pushing ourselves on people that don't want it
seth: I wanted to ask about the Korean model
… We have html for a11y, voiceover, etc
… that is the push to have epub wrap this
… does the Korean format have an a11y answer?
Hadrien: We are looking at it, it has more of a media overlay flavor
… We really want to have the text become accessible
duga: I've had Ivan's question too
… we're doing it because people have asked us to
… EPUB may not be the right format, but some people want to do it that way anyway
… and we can let them, we can make it work
… if I were to start a company doing webtoons today, I wouldn't use EPUB, but if they wanted to, I could make it work
… even manga was a zip archive of images, there was a push to using EPUB, we ended up supporting it because its nice to have metadata
… issues with pages being wrong order, EPUB fixes that with metadata, it is nice, there are uses
wendyreid: The feedback we have gotten is some publishers might want to sell big collections
… I agree that if people want it let's help them
… this group also supports other formats like publication manifest, which might be a more flexible format
… we need to be responsive to industry need, and we don't need to be stuck in just epub
… for instance webtoons have terrible a11y, and it would be great to make this better
ivan: I checked the charter, we can update the publication manifest
Hadrien: This is broader and goes into digital comics entirely
… We should keep in mind, this one distribution channel is not the only one we should consider
… e.g. libraries making collections
… And there is also the case of storefronts that might want to sell them
… You can't really separate the business models from the technical
… back to zip vs epub
… what Korea said was metadata was bad for archival in epub
… for instance, spread placement isn't a big issue for webtoons
… we need to look at what works and what doesn't
… and I think the most problematic is forcing images into an html wrapper
… I don't think this just solves the a11y problem. We have a lot of inaccessible xhtml content out there today
… we really need to focus on what does and does not work
… for a11y we need to focus on specific use cases
Avneesh: I am a little alarmed about Korea taking readium manifest, I am concerned about Korea going to ISO quickly
… I think it is a problem if we are against the Korean national standard
ivan: 2 things - first according to the Koreans epub MD is not good for archival
… This is something we should address
… the other is, what is wrong with saying we can put images in the spine with an xhtml fallback?
… but the xhtml fallback isn't the image it is just alt
sue-neu: I have clients looking this as parts of courseware, say for a history book
wendyreid: We will continue this tomorrow
Accessibility TF
Avneesh: We didn't have time to plan for the a11y TF
<Avneesh> https://
Avneesh: so we thought we could use this meeting for that
… so we have a wiki with a list of topics
… we have strong demand from APA for wcag version
… then there are some issues from the cg
… for instance metadata to say text/audio mix
… then we have a11y md that is missing, for instance no publisher contact info
… Then with AI we have to know if TTS is AI or human based
… Then we have to define skippability and escapability
… Some liason work
… any comments?
<Makoto> I had a teleconference with AGWG people including people from the team about the lack of support of non-western languages in WCAG 2.2. People are inclined to create WCAG 2.3 as a solution but I am not sure if AGWG reaches cosensus.
ivan: We should not forget to officially issue a new a11y guidelines with the proper version. We need wg consensus
Avneesh: Yes, let's do that tomorrow
… now harder topics
… we maintain a mapping to EAA
wendyreid
Avneesh: do we need to add anything to that?
wendyreid: One thing I hear a lot is parts of wcag like image desc where publishers have trouble doing it in the context of books
… Wcag doesn't seem to make sense to them, that is mapping web/app descriptions to book descriptions (what to say, how to integrate, etc)
… may be related to footnote work
… maybe we need some guidelines
Avneesh: Yes we should discuss, and yes footnotes is similar
gpellegrino: Mybe we need something like an index page to link to everything we provide
… it is hard to find all the documents we have
<sue-neu> +1
George: I agree there is a lot going on in different places, and I am often confused about where the right place to take issues is
… For instance back links to a footnote, but if the reading system had go back it wouldn't be needed
… it is determines how things might be referenced
… for instance a glossary term that is pointed at 3 times, a back link doesn't work
… so who addresses these? Us? CG? somewhere else?
wendyreid: I think the CG is usually right, but sometimes it is us
Avneesh: EAA and title 2 - anything else we need to do to support this?
… and then there is dpub aria
… Matt is the liason
… It has strong use cases and long consistent systems for implementing
… if we want some new roles we have to do it now
Hadrien: On Readium we plan to improve read aloud, the other readability
… we will have a lower level building block that supports dpub and dpub aria
… This will help identify a11y behaviors
… eg move where footnotes are read
… We will use the dpub aria for read aloud, which hasn't been used yet. This will be a pretty open implementation
… We will have multiple implementations, not sure if that counts as 2+
… this will be coming this summer
Avneesh: Jaws is supporting 50% of dpub aria coming up
… so screen reader are starting to support it
gpellegrino: we found out a while back that talkback on chrome supported all dpub aria roles.
… the browsers are there, there is still some discussion with Apple
… I think the dpub aria roles are deeper than epub ones
… We used to have epub types, then we had aria which lost some things
… In many cases these roles are important for the production workflows not just end user
… There is a request to add common ways to identify certain items in there books
CharlesL: couple things, on title 2 we have heard that the dept of special ed still exists
… but there has been a de-emphasis on title 2, unlikely for justice dept to start filling lawsuits on day 1
… but individuals still can
… on dpub aria, one thing we may want to require is digital only publications for page breaks (some publishers having issues with that)
… there is a dpub aria role for it, in our tests everyone handles it differently
… Then there is the question if it is in code only but doesn't appear
… or it appears and has more words, etc
… that can be problematic for AT
wendyreid: dpub aria is similar to footnotes, needs best practices
… so we need expected behavior when we see it
… page breaks is similar to footnotes on when and how to read
… Then there is FL with dpub aria
… Not every page is a chapter so you can't add it to every files
… Need to see where the gaps are
George: Excercises are important, it would be good to address the issues of how to do exercises and workbooks
… Publishers will move the epub into an LMS
… so it would be great to address exercises and workbook completions in an epub
mgarrish: We have had problems with roles, and too much verbosity
… so we can't just keep throwing in new roles
… For work on 1.2 Tviya works with me, but we will need a new person to help with editing that spec
… because we can't have just one
Hadrien: There was also the structural semantic vocab
… in readium we primarily target dpub aria, but we have other properties we are pulling in
… Also aria, which isn't used much in epub
… So we are agnostic and pull in all 3
… we have to take into account everything
Avneesh: There are some things we will bring to the TF, not sure if the topic George raised can really be handled there
… We already keep a list of actionable aria roles
… It is missing some details (e.g. footnotes go back), but the high level is there
gpellegrino: And we have a test book that has every role
George: And we have a published book with all the dpub aria roles we can support
wendyreid: we're now speaking about annotations
laurent: I'm going to share some slides
… today I would like to discuss an agenda of work, not to discuss the single items
… we would like to start about discussing the incentives for TF participants
… use cases, business cases, etc.
… then discuss for annotations, bookmarks, annotations
… then discuss the scope of the project (embedding, rest protocol, etc.)
… find existing apps that are already exporting annotations
… check to look at the data model available: W3C Annotation Model, Readium Annotation Model
… to find differences, and common elements
laurent: so we'll start with the incentives for the participants, what are the market requests
… is there anyone that wants to propose incentives?
Annotations
mgarrish: we worked on open annotations years ago with edupub
… it didn't work
… I think you should clarify if it's for publishers to distribute them, or for users to share them across reading systems
ivan: I have here the list of people that wants to partecipate to the TF
laurent: I asked to ReadWise (readwise.io), I may ask to hypothes.is
… because I don't have contacts, and their solution is based on URLs
ivan: I think also Matheus may want to partecipate
wendyreid: may you publish these slides?
laurent: sure
<ivan> Participants as of now: Brady, Hadrien, Eloisa, Ivan, George, Laurent, Leonard, potentially Lars Wallin
wendyreid: about incentives: I think the focus should be on the readers, to allow them to share annotations and move them around
… a lot of platforms allow to export annotations
… I think it's also important to have educational publishers on the table, because it's relevant for them
laurent: these two use cases are quite different
Hadrien: I think focusing on the user is right
… I think we should keep attention on two things: one is DRMs, the other is the possibility of make it work outside EPUBs
… we should take one challenge at a time, focusing on endusers
… when thinking about annotations I would ask: what about bookmarks? what about highlights?
<tzviya> very old list of use cases: https://
ivan: when I think to web annotation standard, I see it as an interchange format
… meaning the standard doesn't say anything about UX of the enduser, it's all about sharing data
… I think we should do the same here, not dictating what reading systems should do
George: I think we should start discussing the difference between annotations and footnotes
… annotations (like the annotated Alice in wonderland) that are provided by the publisher
… while the ones made by users are totally different
… there is also a use case for excersices in text books, the fill-in-the-blank is an annotation
duga: I think that there is something we should carry on styling (like the color of the annotations)
… about business cases: I think we may invent something really interesting, but we have to be sure that someone will implement it
laurent: we also have to find companies that may make money out of it
… Readwise may have benefits from a standard for managing annotations
wendyreid: sure, there are some companies that have direct interest, but we also have "secondary market"
… were companies may be interested in offering the export/import of annotations as part of their service
… similarly this may help the switch from one ebook vendor to another (Kobo, Amazon, Apple, Google, etc.)
Hadrien: in Readium we'll implement this spec in our toolkit for desktop, mobile and web (Readium)
… this interoperability will help the interoperability inside Readium ecosystem as well
… we also have some statistics from Readium users, so we have some idea on how users manage annotations, exports, etc.
George: I see the business case for selling annotations, for example for receipts books
… I think people would like also to be sure to be able to maintain bookmarks in their life, from one vendor to another...
ivan: do you have any relation with people working on legal replica?
… in that business there is a lot of use of annotations
… similarly if we look at specialized business, we may look at translations and multi-lingual content
<Zakim> tzviya, you wanted to say there are so many biz issues
tzviya: I'm not sure if translations is a use cases, on the legal side I think we should discuss with someone who has specific knowledge
… in particular if we rely on the original content, so IP issues may raise
gpellegrino: I think there is a huge demand in the publishing industry
… like working with vendors
… providing feedback is tricky, you can't reference exact locations
<sue-neu> +1
gpellegrino: maybe vendors or conversion houses, may want to have part of this
duga: will we be able to move annotations from one edition of the book to another?
laurent: it's part of the scope we have to discuss
laurent: I think we should also discuss about annotations vs bookmarks vs citations
<CharlesL> Another use-case EPUB certification & remediation annotate exactly where issues were found to give the feedback back to the publisher.
laurent: for us, for annotations we need: publication metadata, the document, the text selection, the textual note
… for bookmarks: (similarly) publication metadata, the document, pointer (mark)
… for people using assistive technologies is tricky to highlight text, so for them using bookmarks and adding notes to the bookmarks is simpler
… so bookmarks and annotations are similar
… for citations we need: publication metadata, page, text selection (quote) in a specific format
… for use citations are not part of the model, are more an export format for annotations
is there consensus on this?
shiestyle: for use cases: how can it work for part of publications that are sold separately? (what is the relationship with the complete edition)?
Hadrien: for me the annotation is a text on top of a highlight, or on top of a bookmark
… if we take this approach, we can make it working on other types of publications, like audiobooks (you mark a timestamp and you add text)
… the problem with highlight is that is very related to text, while we need something that may work with multimedia as well
wendyreid: abstracting it, the user is selecting a fragment, attached to the publication metadata, has some form of locator and has some content attached
… I think we have to find a way to identify selected fragments
… on another side, more and more reading systems allow users to take hand written annotations
… so the content attached may be images
ivan: for me there is no difference between citations and annotations
… the real difference is on how much metadata we have, for providing a high quality citation
… while on the color side of highlights I think we should work on a higher level
… not about colors, but based on categories, also for accessibility issues (e.g. color blind users)
George: I agree, we should add semantics to the annotations, to categorize them
<Zakim> tzviya, you wanted to talk about citation
George: I think that audio annotations are also a thing
tzviya: I think we should allow the user to select if in copy-pasting content wants the citation references or not
Hadrien: I think we should be able to attach every type of multimedia to an annotation
… about color related to annotations, I agree, at the same time I think that people are used to use different colors for different meanings
… it's difficult to move end users from colors, to categories
ivan: about colors: my question is what do we want to specify at standard level, and what do we want to leave to implementers?
<Zakim> tzviya, you wanted to color with meaning
ivan: I think we should split the information on how the information is displayed
tzviya: I think the GitHub approach is interesting: for labels we are colors + label (text)
wendyreid: I think it's more important to mention in the annotation exports that there are different types of annotations (e.g. different colors), more then focusing on colors
Hadrien: for interoperability I think we should have a set of values
… that the user agents can use for tagging annotations
… I think we need a default way for managing the interoperability
ivan: we can define types of annotations, but leaving that other applications can define other types
… in web annotations we have a similar field
laurent: moving to next slide, we want to check what is already available as standards
… W3C annotation data model, is mainly for web, but can work in EPUB, using CFIs
… Hypothes.is has their "standard"
… kindle, apple, google, kobo have their own system for exporting and syncing annotations
<tzviya> zotero is important
laurent: readwise.io has CSV/markdown, can import and export to/from many apps
… Zotero supports EPUBs and export annotations
… Readium has an profile of W3C annotations
ivan: W3C annotations is actually 3 specs
… the data model, the vocabulary, the protocol (for data platforms)
… in the WPUB annotation group note we've worked on annotations that may go across different documents in the spine
Hadrien: there are a number of things that are referenced from that specs, one is the text fragment
https://
Hadrien: my proposal is that what we decide to choose and selector, we should find something that works on web as well
<George> +1 to work on the web.
ivan: I think we have to decision on the life of the CFI
… do we want keep it alive, or to kill it?
ivan: we cannot avoid this discussion
… it may not work with plain HTML (not XHTML)
wendyreid: we did a lot of these discussions in the virtual locators TF
… we worked on "universal locators", interoperable across different reading systems
… and interoperable across different editions of the same book (e.g. Mobydick)
Hadrien: on the web text fragments are quite good
… the difficult part is creating a text fragment
… browsers are able to do that, but they do not expose APIs
ivan: is there any WG in the W3C working on text fragments?
wendyreid: Web Incubator Community Group (WICG)
laurent: I think we should find something, like a polyfill in JS
George: maybe the accessibility object model (accessibility tree) may help
laurent: now an overview about W3C annotation spec
… it's based on JSON-LD
… without complex structure, just a @context attribute
… it's very flexible and at the same type it's difficult to fully implement
… the structure is simple: id, type, motivation (bookmarking, commenting, ...), creator, created, modified
… a target (with id, type of sources and selector)
… the selector may have multiple types (including FragmentSelector)
… the body has an id, a type
laurent: in these last 10 minutes I would like to mention the mailing list address of the TF
… it's group-pm-ann@w3.org
… we have to define the frequency of the calls
… I would propose to start with a call every two weeks
… I would organize every call around one of the slide we discussed
… and find some consensus at the end of the call
some discussion about the best email list to use for task forces, not minuting :)
ivan: editorially how will we manage this spec?
will it be part of the main spec (or reading system spec) or will it be a separate specification?
… in any case the logical place for storing the document we'll be the EPUB GitHub repository
laurent: I would like to create GitHub pages about the consensus we had, the history behind some decisions
ivan: we may use the wiki
Evolution of Media Overlays
marisa: sharing screen, showing notes in obsidian...
<marisa> https://
marisa: WebVTT is a way to sync points to timed media. Let's see a demo.
<marisa> https://
marisa: WebVTT is a timing audio + associated data including selector. To use it in EPUB we need to list them in the manifest. We can overload the overlay (SMIL and VTT) and let the reading system use the one he handles.
marisa: using VTT alows to set up custom CSS highlight.
Hadrien: a general comment, we've seen media overlay only used in fixed layout. Aside we see specialised librares (Nota, MTM) willing to use them to replace Daisy files. For long time, MO was niche. If we want to change things to this format, we should make sure we really add features. I'm thinking about Accessible Comics, we could extend media overlay to images fragments.
LaurentLM: Agree, it's comllex to change now something that starts to be more used. We should remove the burden of IDs everywhere. That's seems to be the case with VTT. The works with selectors is also to consider as a piece to help enhance media overlays.
marisa: VTT brings greater range of selectors and allows to limit the number of needed IDs. This is a new serialisation format for media overlays. It is to be added, not to replace SMIL.
ivan: is this implemented in webviews? Because Reading systems often depend on Webviews.
marisa: I will be happy to help implementors.
wendyreid: we have to make sure we don't break backward compatibility, and think about authoring tools so it is feasible for publishers.
wendyreid: but on the spec side we tottally can do this addition.
Hadrien: on implementtaion, when audio is involved, we often prefer native audio APIs than webviews. It allows to support more sysem control like touch etc.
<marisa> https://
rdeltour: I really like the idea of looking at implementation and identifying pain points before going further is a good strategy. If we want to support both SMIL and VTT, how complex or easy it is to convert one into another. Another question is how can we make VTT support escapability and skipability ?
marisa: I experimented conversions successfully. the link in the chat is to let you test that.
marisa: implementtaion is much more easier than SMIL.
marisa: regarding escapibility and skipability, i don't think that the audio / SMIL is the best place. I would drive them from the text file.
delackner: what are the workflows in place to produce such files? Is there anything we know from the production side?
duga: playbook uses media overlay to interact. It's easy because we have the IDs, shall they reprduce the experience with VTTs?
marisa: yes, the selector replace the ID. We can discuss suitable selectors.
Hadrien: on production, when it is human voice, it is a struggle today. When it is TTS generated prerecorded voices it is easier.
gautierchomel: Similar to Hadrien, I've implemented an audio workflow when its generated, the system gives you back timestamps
… I can easily make this webVTT
… when I try to relink to HTML ids, that is when it is more challenging
… this could help a lot, this is the kind of filethat can be output from video for example
HTML Serialization
wendyreid: we're not switching over. It would be an addition. It would probably not break publishing workflows.
… distribution platforms and reading system would need to evolve.
… how do EPUB validate and open in reading systems?
… Wendy made an EPUB with different files & different approaches. a) just change file extension b) change doctype c) change media type.
… run through EPUBCheck.
… errors.
… tested on several reading systems. The doctype matters.
shiestyle: I had a survey in Japan with reading system vendors. It is not a heavy modification.
ivan: I heard that it is a small addition for rs vendors. We need to hear Romain about the checker. A W3C process trick here: we marked it at risk (related to the CR phase).
… we can only guess and wait for reactions.
duga: for rs it can be a pretty big deal. Not well formed XML will break systems in several places.
hadrien: if we don't start we will not know. It is probably the only possible move.
<Makoto> QTI3 continues to use the XML syntax for representing elements borrowed from XHTML. QTI3 is an XML-based markup language for repressenting assessments.
gpellegrino: as part of the LIA process we are relying on some HTML tools, I transform XHTML to HTML. The xml:lang attribute must be moved to a lang attribute. This is the only transform we do.
… At the industrial level, LIA will require XHTML at the start for certification, because some tools are XML only. The implementation period will be long.
<CharlesL> Benetech's GCA certification requires both xml:lang and lang attributes to be set the same.
mgarrish: a) epub:type is not solved. b) many publishers will not release EPUBs if they are not sure that every rs cannot read them.
<CharlesL> +1 to EPUB 4 change not a 3.x
LaurentLM: About old reading systems, not using web engines
… what do we do with them?
… if a publisher releases something HTML-based, old reading systems will blow up, how might we manage this?
… older eInk reading systems, RMSDK?
laurent: what about the old rs (eink readers) which will explode if facing HTML-based publications? I'm ok for breaking, but there will be some issues.
avneesh: we can write a W3C note, it will be a warning, give time to adapt to the publishing industry. In the next charter (2-3 years) we will move to it.
shiestyle: do we know when XHTML + CSS will break?
ivan: nobody knows. The package document is not the issue, the navigation document can be one. svg is in xml.
… I don't see a real difference btw publishing a note now or including the information in the draft now (released in two years).
… if there is no implementation we can remove it at last minute.
ivan: browsers will continue supporting current XHTML for the known future. But new APIs may not be supported.
wendyreid: we can postpone to EPUB 4, but we are in year 13 of EPUB 3 and we are making important evolutions. There is no will from the industry to move to a major evolution of EPUB. It we do that in EPUB 4 it will take 10 years to fly.
duga: many readers display content as HTML today.
charlesL: the driver should be a brand new thing, that we cannot do in XHTML.
wendyreid: it may not be a publisher who will want to do a new thing, maybe a rs developers will need it to do great stuff.
ivan: we should have a PR which shows the changes. and replaces epub:type (or is "epub:type" accepted in HTML5?)
gpellegrino: epub:type does not break the browser or validator. Querying for epub:type is a question.
george: K12 are putting publications in their LMS, they are moving to HTML.
LaurentLM: 2 comments, following George, we're seeing the same in Brazil, because they need HTML to do the applications they want, better relationship between web reading, and for a prototype, we'd need samples.
… So we can test on something
laurentLM: in Brazil, the national program is contemplating moving to Web Publication because HTML is accepted and it brings more coexistence with Web reading.
… and we need a good sample in the HTMLish varinant of EPUB.
PROPOSED: Create a PR for review that implements an HTML serialization for EPUB.
<Avneesh> +1
<shiestyle> +1
<ivan> +1
<CharlesL> +1
<gautierchomel_> +1
<George> +1
<wendyreid> +1
<LaurentLM> +1
<duga> +1
<marisa> +1
<Hadrien> +1
<toshiakikoike> 0
<MasakazuKitahara> +1
<gpellegrino> +1
RESOLUTION: Create a PR for review that implements an HTML serialization for EPUB.