Meeting minutes
EPUB HTML Survey - w3c/pm-wg#21
wendyreid: 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
gpellegrino: in the google doc there were more questions - did we lose them?
ivan: 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> 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."
wendyreid: 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
SueNeu: 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: 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
wendyreid: 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> +1 to brady
wendyreid: and is there anything we can do in our implementation that makes this easier for you
ivan: 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
<LaurentLM> +1 to ivan
ivan: we've had a lot of talk of versioning and profiling - we need more info on how to do it
<SueNeu> +1 to ivan
wendyreid: the way the question is currently framed fits that model but we should make it clear in the opening comments we're doing this
<gpellegrino> we had that question in the previous version :)
wendyreid: we need a question about who is submitting - what is their role, are they a publisher, developer, etc.
SueNeu: 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: 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
SueNeu: 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: and also what we can do to ease it
SueNeu: if we're looking for other data we should rethink it otherwise I think we're good
ivan: if we are good then we have the practicalities - is Gauthier comfortable finishing it the way we discussed
gautierchomel: yes
ivan: 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
wendyreid: should we ask for help from daisy
ivan: and bisg
wendyreid: booknet canada
George: read 2.0
wendyreid: I don't know if want to try translating it and distributing it in other languages, like japanese
shiestyle: how can we prepare a translated version?
ivan: 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: we will have to find someone to translate it to Chinese
wendyreid: there may be some people at W3C
ivan: we need both simplified and traditional
shiestyle: we used to have some people in Taiwan
ivan: 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
wendyreid: google translate?
ivan: that's possible but I'm not sure I trust it
gpellegrino: for the italian community we are already discussing this with publishers - it is fine to have the survey in English
SueNeu: about how to handle the data we can borrow techniques from the user community they use card sort and start finding common themes
wendyreid: we can try a few techniques like that - we can summarize, use card sort, tagging - let's get the results first
wendyreid: guathier when do you think you can have a draft ready?
gautierchomel: probably by tomorrow
wendyreid: once we have that we can send to a few people to get translations
ivan: I can find someone for Chinese, Shinya I assume you can do Japanese, do we need more translations, like French?
wendyreid: it would be good to have French - we can find someone
wendyreid: Gauthier can you translate?
gautierchomel: I think we can have a discussion with the French publishers and see if they need one but I can do it
gpellegrino: 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
SueNeu: if we're doing these translations we should also consider Spanish and Portuguese - but I agree this may be overcomplicating things
<gpellegrino> https://
wendyreid: 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
wendyreid: 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: 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: 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: 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: 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
wendyreid: 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: 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
gautierchomel: I think we should move this to an incubation group
George: going back decades the debate on who wins goes to the user - we shouldn't go anywhere where that precedent gets changed
<Zakim> tzviya, you wanted to respond to George
tzviya: 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: I don't remember anything being documented in the spec
tzviya: no, it was never written that way
ivan: I think that should be done
wendyreid: we need some guidance even if it is not normative - this should go in the reading systems spec as it will affect them
<wendyreid> https://
wendyreid: 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
<SueNeu> +1 to talking with CSS group
Dale: I was wondering if this is a bridge that css has already been over - how do reading systems respect or overwrite css
ivan: the reason why it will be different is that browsers don't give users choices - reading systems do more than they might realize
wendyreid: next steps are to draft some language of what brady suggested and to talk to the css group