Meeting minutes
HTML in EPUB - w3c/epub-specs#2715
wendyreid: We were discussing adding HTML to EPUB online and via email, let's continue the discussion here
duga: I don't know about adding a flag about HTML in the file
… I'm not sure what this would do, it is something we've tried before
George: with Rick's suggestion about HTML vs XHTML, adding a flag in the OPF would avoid that
Charles: It would be nice from a consumer point of view — you'd like to know if a book would work on your reading system
wendyreid: it would be nice from a vendor perspective to differentiate books, like fxl vs reflowable,
… it might be hard to communicate to a consumer the difference between XHTML and HTML
… we could say something like "might not work on some reading systems"
duga: agree it might be difficult to exchange, and a flag would be redundant with the mime types in the manifest
… publishers may not be accurate about the flag, they haven't been accurate with similar things before
CharlesL: The cost of us adding the flag is negligable
… a reading system could then make a patch that could utilize it to tell users if a book would work on their system
<gluejar> "quick patch" = ~3 years, I think
CharlesL: plus a flag could be used to get data about how many publishers are using HTML
gautierchomel: Its not that the publisher will use this information,
… what about a file with mixed HTML and XHTML content?
wendyreid: publishing moves slow, if we release this change tomorrow, we won't see HTML epubs in the pipe line
… they will be some people who try it right away, some people are already doing this internally
… it will take time for us to see this, but that's good
… we will see people and platforms experiment with it
… what does HTML offer the XHTML doesn't?
… this change is more about longevity
mgarrish: We don't need to get into the solutions right now
… it is important to find out what the issues are across the board
… vendors who don't want HTML will simply not accept the content
… vendors will be the barrier, this will take a long time
… we have problems that already exist, I'd like to go back and fix those
… it may take time, 10 + years, before the tools and all people adapt for HTML
eric_hellman: I've maintain the software that turns html files into epubs at project guttenberg
… we regenerate our files every month
… we are able to do this for a lot of files without much intervention
… we have changed our preferred format from XHTML to HTML5
… my software deprecates that to EPUB3 and EPUB2
… we give our books away for free and have no control over the platforms
… there is a demand for EPUB2 it works better
… the difficulty is, we have millions of users and thousands of different reading devices
… we are conservative about what we allow
… we don't want HTML5 in the EPUBs because we will get problem reports
… we have no staff to deal with this, so we strip out new things when we make the EPUB files
… we control the distribution and production, but no control over the reading platforms
… things that should work across devices but don't, are a source of problems
… for instance ADE doesn't respect CSS pagebreak in EPUB 3, but did for EPUB2
… we have to watch out for any potential problems
… if people are getting errors with files using HTML in the EPUB, we will stop using it
… I would love to be able to put HTML5 in an EPUB
… my concern is the rate at which reading systems will be able to render the HTML files
… a lot of people experienced with the XHTML files made mistakes producing HTML5 files
… I fear that a lot of y'all may underestimate the failures that occur when you try to render HTML5 with something used to seeing HTML4
… I was surprised with the failure modes we found looking over our 75k+ flies and all that the reading systems do
… this group should think about how to promote adoption of new features
… especially features that could ruin the experience for the reader
… just having a flag will not be enough
… I'd like to see an HTML5 only format that could be the bright new thing
… with appropriate branding
… and some level of javascript, sound rendering
… a new brand could be promoted by the reading systems, "we can now do this"
… not doing the branding has lead to slow adoption of the features in EPUB3
… if you really want to have new features adopted, you need to give them some gold stars they can use to sell their reading systems
wendyreid: This is incredibly valuable information, we've been talking about EPUB3 adoption
… what we've found is that EPUB3 is well adopted
… but we don't have any examples except ADE
… because ADE is no long being developed
… you have lots of information that would be really helpful for us
… can that be shared? It would answer questions for us
CharlesL: Thinking down the line 10 years, now reading systems only support HTML, they can use a flag to identify XHTML files that won't work anymore
DaleRogers: If I'm creating an Ebook, and I want it to be in KDP, I need to go to their docs to find our what they support
… as a content creator I always have to start with the output and design my files to be compatible with the outpt
… as part of this group I put on a different hat
… I hear what people are saying about some reading systems being up to speed and some not
… do we always have to check what standard a reading system supports?
ivan: CSS features update almost once a week, we expect reading systems to follow this
… some do and some don't, and then the rendering can go wrong
… particularly a problem for accessibility
… HTML5 is a similar problem
… in EPUB3.3 we worked on a testing suite for the purpose of the W3C process
… this suite was used to test reading systems
… the results are publicly available
… if we put more care into this testing suite it could become useful beyond the W3C process
… rendering systems may or may not choose to share the results of the testing suite
shiestyle: As a publisher we do not provide HTML based EPUB
… since we have to provide encrypted epubs to some vendors we can control versions
… it might be safer for us to expand EPUB generation to HTML for our complicated Japanese titles
duga: I develop reading systems, I would think it was bullsh*t to have to go through every line of code
… where I made decisions about whether a file is renderable
… and I'll be right where I started rendering Ebooks after all that work
… we let other people determine our formats
… and they don't care about XHTML
… at some point, someone will delete the XHTML syntax
… and we will be left with a lot of content built on XHTML
wendyreid: a special challenge with EPUB is that we are reliant on standards built with a different industry than ours
… that industry moves a lot faster than ours
… there is an argument we could make that we need to fence off a version that addresses our specific needs
… we are trapped, when tools and browsers evolve, we won't be able to respond
… lots of platforms are on the web or use browser engines
… it is possible that XHTML spec can be deleted and EPUBS will break
… this is a scary change, but important for the long term usability of the format
… testing is a good thing to raise
… I have a test book with HTML files, I will upload it so reading systems can use it
… we also have the survey and we can use that to find challenges we aren't seeing
<wendyreid> See: survey text proposal.
GeorgeL: it is clear to me from surveys that people who are complaining are using EPUB2,
… it is time for people to update their systems to EPUB3
… and get them to use something better than ADE which is bad for accessiblitiy
AveneeshSingh: EPUB is a business format
… release 3.4 with traditional tech, and 3.4+ with HTML and see how it is adopted
… the browser people aren't listening to us, we need to take a step and allow the world to evolve
wendyreid: we could talk about this forever, we don't have the information we need
… we don't know what the challenges and the issues will be
<wendyreid> https://
wendyreid: we can't move forward until we know more
… everyone should read over the survey and get feedback from the industry
… until we have that information we will keep circling on the topic