PR 2771 - w3c/epub-specs#2771

<ivan> w3c/epub-specs#2762

ivan: the reason this is started is because of me - there is a common thread in a number of issues e.g. in the dark mode thread
… this is about the relationship between the author and reading system - author spending time on css and rs invalidate what they do
… we use html5 and css so styling is better than epub2 had
… I opened a pull request to start to put in some hints for reading systems in both authoring and rs specs about the way they would/should/might handle author css
… the ship has sailed on changing reading systems - rses have taken the lead on rendering and control over things like margins, fonts, etc.
… the pull request is still open but in the authoring spec we have added some statements warning authors some of their styling will be overwritten
… and the hope is that at least some reading systems will publish their styling so that authors can find out what happens without experimentation
… the other aspect is to ask reading system devs to give the option to the user to have the author's styling dominate
… apple reader offers a choice for an original view but I haven't tested it too much
… I don't think we can do what I'd prefer to give whole power to the authors

mgarrish: I think that mostly covers where we are, the disagreement is on how the affordance works, is it specced out well enough
… it's somewhat implemented, but is it repeatable?
… that is as far as we've gotten now, is it realistic and how does it work

ivan: we looked at both the css sections in both specs and the text came from earlier versions of epub and the meaning is not really clear
… the pr fixes some of those ambiguities

LaurentLM: when reading systems add some css to the author it's because they have to normalize all the peculiarities
… it is difficult to remove the rs css - it will break the view if you take out too much
… most reading systems try to make a minimal changes as possible
… apple is not the only one to offer to go back to author styling
… thorium offers an option to get back to author css but still with the required optimizations done
… having a public reading system css would be good but I expect only open source ones will do so

Brady: +1000 to laurent - the css reading systems add is to take the book from looking like garbage - without margins text would be a complete mess
… you keep adding css until the content looks good on your system
… the author doesn't know the problems of a device because the rs makes it look legible
… if we give the author complete control then the content will not render as they expect
… I do see where it does make sense like on fonts although even then publishers don't care too much and users tend to not want fonts changed from their preference
… publisher intent for font size is not always clear so google, for example, will figure out an optimal 100% size based on the device
… play books has a true original mode where you can see the content down to the page breaks and no one uses it because it's unreadable on their phone
… people who have found this feature have called support because they can't figure out how to get out the rendering
… adding a flag to get rid of the effort to make the content readable is strange - but if we really feel it is important as an optional feature okay as it is vague enough

sueneu: I agree with brady about some aspects of author intent - author's don't always care about font
… margins and text size should be calculated to the device
… but sometimes authors want indented text, text to look like it's handwritten, especially in YA text
… sometimes they want a background to make it look like it was typed in a phone
… would it be possible to separate out the parts the reading system takes responsibility for and what authors can use css to customize

ivan: this looks and sounds like a cultural difference - everything that Brady says could have been said by browser vendors to justify changing web sites
… no browser does this, outside perhaps of reading mode
… pagination is special to epub and I understand that part
… but why such a huge difference from the web for everything else - could be cultural

ivan: how do fixed layouts get published if reading systems override their settings?

<LaurentLM> FXL is totallty different. The RS does not normalizes.

wendyreid: reading systems pay far more attention to FXL than reflow
… I agree with most of what Brady said but kobo respects much more of the original rendering
… one of the big challenges is making content work for so many devices
… because publishers convert from print they think about print pagination and don't think about phone displays, for example
… publishers aren't always considering every device their content will render on
… but there must be a balance we can strike between publisher and rs
… fonts is a case where sometimes it doesn't matter but sometimes it does and you need to see the differences
… but how do we sort through all the properties to determine what is important and what is not
… maybe this should be best practice styling recommendations that we know work well

Brady: I think font is one of the more important ones that get changed and why reading systems differ from browsers
… it is problematic to overwrite math fonts or handwritten fonts but we don't want to use fonts like roboto
… what play books does is parses all the font rules and inserts a better font before a generic one
… you can't do that with the css cascade so you have to edit the css to do that
… a browser is a user agent but a reading system has a user agent - if you don't intercept you can't make the fix
… I have read books with different fonts and indents but we spent a lot of time making the outer margins work so the inner ones look good
… in terms of fixed layout we don't do anything - we don't let you change fonts or alter the styling
… we have an entire task force on fxl accessibility and it's still hard to read even for sighted people
… our culture is different because we have to show books created twenty years ago and make them look like they were created today
… you also don't go to the chrome store and buy a web site and be okay with it looking like crap

<sueneu> +1 Brady on business model differences between the web and the RS

Brady: if your competitor's product looks better than you lose business

DaleRogers: I know content creators might create epubs with pages or indesign and never get under the hood to see the css
… so I understand what brady is saying about having to deal with content that was created by these programs from years ago
… the validator will tell me if it's conforming but I don't know all of what it checks
… but how does the author know what is the best practice for different reading systems - we follow the spec and hope for the best
… is there a css validator that checks if it will be problematic with different reading systems?
… I wonder if it would be helpful if we knew ahead of time how reading systems work and what css will work - is that a possibility?

gautierchomel: ebooks are not updated as often as web sites - it is easier to update a web site
… as a publisher I want my css to be as simple as possible
… on the web designers have media queries to target different displays
… not sure I want to have to do that for reading systems
… I have not heard any complaints about this topic from french publishers but I will ask them
… we need more industry voices in this group to understand whether this is an individual or industry issue

sueneu: I'm interested in whether this is an industry issue - reading systems seem to have taken the issue in stride - more voices would be better

LaurentLM: we should have some authoring recommendations like choosing fonts wisely

<sueneu> +1 Laurent

LaurentLM: authors also don't follow some rules to make epubs - make we need more rules in the spec or a supplemental document

<gautierchomel> https://readium.org/css/docs/

gautierchomel: adding a link to the readium css
… ten years ago it was more problematic but now if I don't do strange things the display is good
… I don't even update books yearly - I want my content to display well for years to come

Brady: it's great that readium publishes this but how many authors go through the css?
… if we find problems we typically go back to the publisher and request that they fix it
… the problem is they often come back and say it works on ibooks and then we have to recreate someone else's display to make the author content look right
… if I still worked at play books it would have fallen on me to publish the css but would anyone have looked or cared?
… the response will likely remain it works elsewhere to make it work - but I might be pessimistic

wendyreid: I've had the same experience as brady - but as gautier said things have gotten better
… books made twenty years ago were really poor quality but today they are quite good
… if we tell people what to do now they may already have figured these things out
… it would be great if authoring tools could warn users about display choices that are really going to make a mess
… but we're not quite there and that may be where best practices come in

sueneu: agree with directing tool makers to the reading system css than authors
… flightdeck is an online tool you subscribe to monthly and they will tell you if a book will work

<sueneu> https://ebookflightdeck.com/

sueneu: they have a supplier-compliant matrix for checking

LaurentLM: some publishers do test with thorium css and not just ibooks

DaleRogers: I'm wondering if authors did not include css and did everything in markup would that show up fine or do reading systems expect some css?

wendyreid: we generally expect at least some css but reading systems will handle a book without any - some things like asides will need styling to differentiate

<Zakim> ivan, you wanted to where we go from here?

Brady: if you look back at books from 20 years ago they didn't have much css and they display fine

ivan: so where do we go from here?
… I think matt and I are at the last round of discussion with the PR
… I don't think we should merge it as-is but get more people to look at it
… it is much better than it used to be but in light of the discussion today we should get more review
… to respond to gauitier I was wondering if media queries would cover all the cases we are concerned about
… maybe we should discuss with the css people in Kobe whether there are media queries that are reading system specific

Brady: the biggest thing missing is the knowledge of a page and from media queries is page size
… it's probably not solvable from the css side because they have pages but no one uses them

wendyreid: when I asked about colour issues they directed me to their issue tracker - maybe we could ask about this as they have more pull with browsers
… in terms of next steps the PR is not the direction we want to take
… the text improvements are okay but not recommendations

ivan: there are no new normative requirements in the text

w3c/epub-specs#2762

wendyreid: people can use the issue to discuss further