Meeting minutes
Discussion: Digital Comic issues
shiestyle: We have some issues from Hadrien
Hadrien: yes, let go over them
… in the layout section, there are a lot of properties handling layout
… For the layout overrides we can say they are flowing or pre-paginated
… it is possible to override on a per-resource manner
… I am not sure if it is supported or if it is a good use case
<shiestyle> w3c/
Hadrien: it's one thing we added that doesn't make sense. And particularly with scrolled content it can be very confusing
… the only use case is very education focused uses, for example at Hachette
… it is very specialized, so I don't think we should allow it
… especially when we have scrolled
duga: I think it does actually have some use, but it isn't really supported so we may need to deprecate
<shiestyle> w3c/
Hadrien: It's been there for a long time, we need to adapt to reality
Hadrien: next issue, mix of scrolled and paged
… reflow really isn't about publsher control, it should be up to users
… I am worried about removing from the spine, due to the previous comics implementation from Japan
… I don't think publishers should control this, and most RSes don't support this
<shiestyle> w3c/
Hadrien: next one is for FL, and it is for orientation
… The content author shouldn't have a say here
… and it is even an a11y issue
… So it is problematic from an EAA perspective
… there seems to be a lot of support to deprecate
… it seems misguided and shouldn't be there
<shiestyle> w3c/
Hadrien: next, when should spreads be used or not. You can do it both at the spine and item levels
… it is usually misused.
… I think sometimes people left spread-none or spread-both, and the pub just left it there
… And it varies by device
… there was one comment about spread-none being correctly used, but spread placement is a good replacement for it
… You can't do that for the entire spine, but it can be put on every spine item
… and this is usually misused. And comics apps usually let you decide
… I think it should all be deprecated
… So even if we support just none, it will still have some bad impacts on titles
shiestyle: In Japan we use both none and center
Hadrien: Well you can use spread placement
<shiestyle> w3c/
Hadrien: so next it is using flow as metadata (not on spine items)
… flow as metadata we might want to deprecate everything except continuous at the top level
… just for the existing comics impl
… Otherwise I would say we should deprecate it all
shiestyle: We just really need scrolled-continuous
… at least for a while
Hadrien: And yes, I acknowledge that
… it all kind of depends on what deprecated means
<shiestyle> w3c/
Hadrien: and the last one I brought up at TPAC last year
… Everyone either includes spread placement all the time, or they never include it at all
… but the spec says you shouldn't use it unless it is meaningful (e.g. a true spread)
… there are two groups, one wants placement exactly where it should be, the other is following Apple Books (cover is center, then starts left-right alternation)
… true spread is a red herring, since you can't tell from the metadata
… we may need to realign with reality
shiestyle: We can't remove those, we can't really deprecate
Hadrien: This is about dropping the concept of true spread, and specifying how the first item is displayed
… so we shouldn't deprecate, we just need to clarify
… but this is clearly used and important
LaurentLM: So all the proposals for deprecation are all linked to allowing the publisher to have power, and we have discovered that the user has control
duga: A lot of these were hints, not meant to be required
Hadrien: The WG needs to discuss these, some may need to wait for TPAC
… and a lot will depend on what deprecation means
… overall these changes will make comics simpler
Discussion: Optional specs for scrolled comics
shiestyle: let's move on to the next topic
… scroll direction is one, but direction probably isn't needed for scrolled
… since it is just up and down
Hadrien: We plan to work on a PR for scrolled
… initial PR won't include optional items
… it will just have layout scrolled, and only at the spine level
… Once that is done we should decide if there is anything else we need
… for instance, support for multiple episodes
… In Japan it is largely a sold per episode, but outside it may be easier to sell content as bundles of episodes
… If we want multiple episodes in one comic, do we need a way to say this is the end of the current scroll, or the end of the current episode?
… I had proposed a way of specifying the end of scroll
… but you could also do it with ARIA that indicates episode
… and then reading systems could decide episode nav
… typically continuous scroll is inside an episode only, then there is UI to skip to the next one
shiestyle: It depends on the UI of reading systems how to advance, we should discuss with RS implementers
Hadrien: The more I think about it, the less I like rendering control and the more I prefer semantics to provide the RS useful information
… then the UI is up to the RS
shiestyle: As a next step, will you have an issue or PR to propose this?
Hadrien: I can open an issue, and I would like to add the concepts of season and chapter, and maybe volume
… sometimes you have multiple volumes with multiple issues
… so I would like to have these added to aria, and I can summarize in an issue
… this would also help with manga
Hadrien: I agree about directions. There are some experimental ones that go in different directions
… so if we are pragmatic we can assume up/down only
LaurentLM: I think it can wait, as you say it is experimental
Hadrien: I am happy to add the semantics
… if we get quick agreement on the semantics we could do a PR with semantics and scrolled
duga: I prefer more smaller PRs
Agenda for next time
Hadrien: We are done with the agenda for today, next time I would like to see images in spine as our next topic
… this would be very good for comics and make them easier to create
AOB
shiestyle: Next call in two weeks
Hadrien: do we continue during the holidays? Do we skip anything?
shiestyle: Let's discuss on the mailing list