Meeting minutes
EPUB HTML Survey - w3c/pm-wg#21
Wendy Reid: looking at the proposed text from Gauthier I mostly think we should focus on the question - we probably want to ask more than one question
Gregorio Pellegrino: in the google doc there were more questions - did we lose them?
Ivan Herman: you are right but we discussed previously that we should simplify the survey as much as possible
bduga: that was what my comment was - I thought we wanted a tell us what we think and maybe a follow up about why - the current question is maybe too specific and should be made broader
<Ivan Herman> present question in the PR: "**Question 1:** What challenges, if any, would your organization face in adding support for HTML syntax in your workflows? Please describe any technical, operational, or resource-related issues you foresee."
Wendy Reid: I agree with brady that there should be a follow up question - question one is what are the challenges and question two is do you think these are insurmountable
Susan Neuhaus: I think we're leading the witness if we only focus on problems and pain points - we'll get that feedback but we don't need to focus there
… : we should have a question about the general issues in the community
George Kerscher: I get the sense that most of us think it is important to get to html - why not state that we will add support and do you have a major objection to that
… : if there is a major objection then we should hear that because it will affect w3c process
Wendy Reid: that's probably one angle we can take but we want to send this out wider than w3c community so we should be careful not to focus too much on w3c lingo
… the person responding may not be in a position to object formally
… we need to consider the source, too - a single self publisher won't carry as much weight in objecting
… we need to weigh objections and understand why people are objecting
bduga: maybe we need to make it clear that this is a thing that has to happen eventually and we want focus on what happens if it appears tomorrow - not on objecting because this has to happen
<Ivan Herman> +1 to Brady Duga
Wendy Reid: and is there anything we can do in our implementation that makes this easier for you
Ivan Herman: I think the way we should formulate the question is not on whether we will do this but this is coming and what should we do to facilitate the transition
<Laurent Le Meur> +1 to Ivan Herman
Ivan Herman: we've had a lot of talk of versioning and profiling - we need more info on how to do it
<Susan Neuhaus> +1 to Ivan Herman
Wendy Reid: the way the question is currently framed fits that model but we should make it clear in the opening comments we're doing this
<Gregorio Pellegrino> we had that question in the previous version :)
Wendy Reid: we need a question about who is submitting - what is their role, are they a publisher, developer, etc.
Susan Neuhaus: So just to recap the question is about the impact on the work and where do you fit in the publishing ecosystem - do we also want a question on how we can support people?
Ivan Herman: I would favour a third question that asks how we can ease the pain - maybe we can add in parentheses some of the options like versioning, profiling, etc. but not go there as a choice
Susan Neuhaus: the purpose of the survey is to get the temperature of the community about this technical change but also to figure out where the pain points are for each area, is that right?
Ivan Herman: and also what we can do to ease it
Susan Neuhaus: if we're looking for other data we should rethink it otherwise I think we're good
Ivan Herman: if we are good then we have the practicalities - is Gauthier comfortable finishing it the way we discussed
Gautier Chomel: yes
Ivan Herman: it is possible to make it a w3c survey which is proven to be accessible - I am happy to set it up but we need to decide how to disseminate it
Wendy Reid: should we ask for help from daisy
Ivan Herman: and bisg
Wendy Reid: booknet canada
George Kerscher: read 2.0
Wendy Reid: I don't know if want to try translating it and distributing it in other languages, like japanese
Shinya Takami: how can we prepare a translated version?
Ivan Herman: to make it simpler I wonder if we should do one form with the main description in multiple languages and then the answers will come in different languages
… I am uneasy about sending out separate forms for each language
Ivan Herman: we will have to find someone to translate it to Chinese
Wendy Reid: there may be some people at W3C
Ivan Herman: we need both simplified and traditional
Shinya Takami: we used to have some people in Taiwan
Ivan Herman: the other practical question I have is we give it six weeks or a couple of months but how do we work on the results?
… we'll get answers in free form and it will be hard to synthesize if we have responses in multiple languages
Wendy Reid: google translate?
Ivan Herman: that's possible but I'm not sure I trust it
Gregorio Pellegrino: for the italian community we are already discussing this with publishers - it is fine to have the survey in English
Susan Neuhaus: about how to handle the data we can borrow techniques from the user community they use card sort and start finding common themes
Wendy Reid: we can try a few techniques like that - we can summarize, use card sort, tagging - let's get the results first
Wendy Reid: guathier when do you think you can have a draft ready?
Gautier Chomel: probably by tomorrow
Wendy Reid: once we have that we can send to a few people to get translations
Ivan Herman: I can find someone for Chinese, Shinya I assume you can do Japanese, do we need more translations, like French?
Wendy Reid: it would be good to have French - we can find someone
Wendy Reid: Gauthier can you translate?
Gautier Chomel: I think we can have a discussion with the French publishers and see if they need one but I can do it
Gregorio Pellegrino: I think we're overdoing it. Most people in the community should understand English if they are reading our specs? There are so many other language we could translate to
Susan Neuhaus: if we're doing these translations we should also consider Spanish and Portuguese - but I agree this may be overcomplicating things
<Gregorio Pellegrino> https://
Wendy Reid: I know we've had this issue in the past where it's harder to read for some languages, like Japanese and Chinese
… if people need assistance we can give a contact to help them
… we'll put aside broader translation than the language we've already identified
Dark Mode - w3c/epub-specs#2700
Wendy Reid: brady gave us a good overview about this at the face-to-face
… basically the challenge is that css and modern web browsers have introduced light and dark modes
… interfaces follow the switches in your operating system but the challenge is that reading systems have already had colour themese for some time and people are attached tot them
… most reading apps have at least four modes, too, sepia, white on black, high contrast, customizable themes
… the themes don't work for all books - but a book in dark mode and content would disappear because publisher styles would interfere
… users feel quite strongly about their preferences, however
… is there anything we can do about these interactions?
Hadrien Gardeur: I think talking about dark mode is the wrong thing - the general issue is that reflowable epub is whatever you want it to be - if you don't like settings you cna change the look
… if users change settings then content won't work perfectly
… what browsers do is not the issue - can we do something to ensure images are easy to view with any colour combinations - no
… we're going to go down a rabbit hole if we dig too deep into trying to solve this
Dale Rogers: I've always viewed the epub spec more as a structural guide on how to set up a document, not as a style guide. we're looking at appearance over structure here
… browsers can override css and it's always been a tug of war over the appearance - epub is the same way
… from my point of view we shouldn't try to standardize the appearance
Ivan Herman: I agree with Hadrien that it's more than just dark mode and the question I have is if you have an epub in your reading system who has the upper hand when the same thing is set by the reading system and the css in the document? is it specified if the reading system or author gets preference?
… does the reader's choice or the document get preference?
Hadrien Gardeur: most reading systems will let the user decide what they want - some use cascade to get the effect while others mess with the dom
… it's not so easy because authors abuse styles to get what they want and then reading systems have to undo it
Wendy Reid: it's been an historically significant problem where publishers were not sending good content with decent styling so css was injected to make them look better
… content creators have been improving the quality of their styling in the last ten years
… we would show our styling with a default to the publisher styling if the user wanted
… the problem is that while font styling has gotten better the colour is increasingly a challenge as publishers use more colour in their content
… the problem is that as users change the mode this colouring breaks because we don't know all the places it's used
… we probably need something but I'm not sure what - could be going to css and letting them know there is more than just light and dark
Ivan Herman: maybe we should invite someone from the css group to help us explain where they're going with it
… isn't it necessary to put in the reading system spec a general "should" statement about how to handle clashing css?
bduga: colour schemes are going to start appearing and we should tell content authors they should not use colour schemes - css does not define light and dark so you can do other things but short of standardizing modes we should discourage use
Gautier Chomel: I think we should move this to an incubation group
George Kerscher: going back decades the debate on who wins goes to the user - we shouldn't go anywhere where that precedent gets changed
Tzviya Siegman: I agree in principle what George says is true but in practice it doesn't always work out - we document what should happen instead of what will because of this
Ivan Herman: I don't remember anything being documented in the spec
Tzviya Siegman: no, it was never written that way
Ivan Herman: I think that should be done
Wendy Reid: we need some guidance even if it is not normative - this should go in the reading systems spec as it will affect them
<Wendy Reid> https://
Wendy Reid: I also think it's worth discussing this with the css group whether with them or having them come here
… they have custom values but also a lot of scary language around using them
<Susan Neuhaus> +1 to talking with CSS group
Dale Rogers: I was wondering if this is a bridge that css has already been over - how do reading systems respect or overwrite css
Ivan Herman: the reason why it will be different is that browsers don't give users choices - reading systems do more than they might realize
Wendy Reid: next steps are to draft some language of what brady suggested and to talk to the css group