Meeting minutes
wendyreid: Welcome
… today is mostly annotations, ISO, digital comics, plus extra time at the end
… tomorrow we start with BG meeting (no conflict with PMWG), then we take over. Japanese publishing guidelines, html in epub, pub manifest, bugs, buffer for run over
… [see calendar for times]
… This year is a little different, there are breakouts at the end of meetings and before some
… please follow the code of conduct, etc, etc
Update on Annotations
<wendyreid> See presentation slides
LaurentLM: [sharing some slides]
… starting with testimony about annotations requesting import/export
… So there are people actually asking for this
… so far there are a limited number of interested parties
… [see slides for list]
… where we are - use cases and requirements are done
… we are actively working on what goes in an annotation
… coming up we will look at selectors, JSON, etc
… Then we have to decide what to do about sync/API
… then it is on to implementations
Github Document: EPUB Annotations Use Cases and Requirements
Laurent: [Looking over the doc at github] We now have a shortlist of requirements. Not all requirements will make this version, and perhaps never will. [reviewing the list of requirements]
… This list includes a list of selectors. It also covers import/export and embedding, as well as version resilience. Questions?
George: Do we have creator info?
Laurent: yes. And also what software created it
Wendy: We also need to consider privacy and security
Laurent: More questions? If not, here is the spec I just wrote up: https://
… also some things that don’t exist in the data model. So we can go over what the subset is. We start with the annotation object, with a target and body. W3C has 0 or more, but we only need at
… most one, so we will have 0 or 1 instead. And we only support embedded, not linked. We still need to look at audio/video, it may not be embeddable. Target must have a source URL and selector.
… W3C also has multiple motivations, we will have only 1. They also have multiple creators, we will have only 1, more on that later. We will also restrict the additional properties and their
… values. The document in github covers this in more detail.
George: So an annotation will have 2 states, private and local, and one that is sharable, right?
Laurent: Sharing is a user action. I don’t think we would restrict that. Why would we want to do that?
George: I may only want to share a subset of annotations
Laurent: so perhaps filtering would help?
George: Well I want to set the sharable state when I create the annotation
Laurent: so the user is always in charge
George: If I want to make some annotation for a class, some private, some public. I don’t want to tag each one at time of export. So you set that when you create the annotation
Laurent: There may be conflicts with the sync of the device
Hadrien: I feel we are confusing the data with the protocol. Privacy is only at the protocol level. Since we are undecided on that I think it is too early to work on this. Scope is already
… ambitious, I think we need to restrain ourselves to the non-protocol level
???: we have a section on sharing and comments, so does that imply that requirement should be tied to the protocol?
Laurent: Yes, and we need to keep manual sync separate from auto sync. [Now reviewing properties from w3c model, with a list of what we will keep] [shows clean and small json with this data].
… Target has a meta property that doesn’t exist in w3c model. We can annotate any item, it doesn’t need to be in the spine. For body we are limiting to textual, but may need to revisit. [shows
… body example] So if we can agree on target and body we are basically half way. On to annotation set - we are adding a few things. I propose adding DC properties to the About object, which can
… be used to identify the book. It is really all we have to work with.
Hadrien: We have discussed this before. Even before CFI we had epub linking. It was hard and we never managed to do it. EPUB identifiers are just sad. This is only really useful if you don’t
… have the book. I have zero trust that this will find the right book. I think we should focus on making the annotation useful without the book. I think that is the direction we should go -
… this is context to make the annotation useful by itself. We should keep this list short, but focus on the useful parts
George: I heard citations would be supported. This DC info would help with that. We talk about books, but journals are heavily annotated. Need to keep those in mind.
Marisa: I saw there was a highlight property. Will that be compatible with CSS highlights?
Laurent: I don’t think these values work with CSS highlights
Marisa: CSS highlights are still pretty restricted, but you can do a lot
Laurent: But if we have a device not based on CSS, or perhaps on audio, etc, I still want this to work
Marisa: So the non web based reader would probably only support a few things, a non-display device might discard it. [lists the things supported by CSS highlights] I was just curious if this had come up
Laurent: For example, color could support every color, but in fact reading systems only really support a handful. We have limited them to a set of specific named colors (see spec). And then leave it to RS to decide which color to use
Wendy: Yes, even in a reader the specific color may change based on theme
Hadrien: I have looked at a bunch of readers [gives breakdown by reader] Most have just 4 or maybe 5. Only yellow seems to be universally used.
Wendy: On styles, I have never seen strikethrough. But it brings up the use for copyediting, lie work substitution
Laurent: I am sure it will be used by publishers, maybe at last round of review. So not for pro copy editors, but I don’t think we need to go to far
George: I have heard the term red line used, does that have specific meaning?
Wendy: Yeah, especially in legal documents. Used to amend contracts, etc
… then it is on to implementations
<LaurentLM> https://
wendyreid: we still have some time, do we want to dive into nitty gritty details?
LaurentLM: There is a section we didn't discuss
magnus: We have a reading system used for students, they used colors for hightlight. Is there anything in the spec to correlate color and meaning?
wendyreid: I think keyword may come in here. maybe tags is better? Color is a way people annotate, but with only 4 colors maybe tags would allow for more customization
… I wonder if we should think about tags and keywords together
Laurent: We went back and forth on the name. They are related
Hadrien: But this is different, we Magnus is asking for a color means a specific thing, vs color and tags can be combined
magnus: So colors have specific meanings for the students
laurent: this is more like a config setting in the RS, connecting a color and a tag
… so we have to decide if thus is in the model or just up to RS
Seth: So we need to make it easy to connect these things, but the data would just know the color
wendyreid: A lot of this will come down to what the RS wants to do and allow for
… I can imagine in a group context, I may use colors and tags, I can share with other people so they understand what the notes are about.
… So we should break visual display and meaning apart
magnus: You may also want to filter by type
wendyreid: any other thoughts?
laurent: I have some sections on filtering, as well as multiple selectors
… selectors should include a precise one, but also one that will survive mutation
… We also looked at extensions
… Also discussed putting this file in METAINF (for embedded annotations)
… This has implications for signing EPUBs, but no one does that
… There is also a section on the order of importing. Basically a recommendation to not bother with automatic detection
… And also a recommendation on what to do if the RS does not support a color
… It would be could to have people review these
… Questions?
George_: Media is supported, can audio and video be annotated?
laurent: it is in the requirements, but I think v1 should start with text.
… We might allow full image in v1, but segments of images, videos, etc, most RSes won't be able to do that. So we should push that to v2
… The evolution there will be with selectors. That is all that needs to change to support that
… the issue isn't how to specify, but support for it
wendyreid: Currently we just have textual, not audio and image?
laurent: yes, the big issue is how to embed
wendyreid: A lot of annotation is currently done via images, anything with a stylus does that
… so we probably need a way to embed this in annotations
… it may be hand drawn text, images, etc
laurent: there are two issues, one is export file format, and how do we put that in an epub
duga: Question about the stylus drawing, we never quite knew how to attach to the text in a way that was meaningful. If the content split or was adjusted, it was lost
… attachment was a challenge
wendyreid: We would drop a selector in that position. If you drew a circle, we couldn't show the annotation, but just drop an icon to show the original image
… so still selector based to the first point
… so the problem isn't really solved
hadrien: it is very device dependent
… It is more like a bookmark, it is not as specific as textual. But this is now growing
… So worth investigating
laurent: Also commenting in other languages is important. We can support plan text and markdown. Do we need html to support ruby for annotations in Japanese? I have heard that this is uncommon in comments
… which would be great since not everyone supports html in comments
… and markdown works for basic styling
makoto: if you want to publish annotations, then ruby would be required
… so this is out of scope at the moment?
laurent: there was a case of an author wanting to publish a book with their annotations
makoto: sometimes the annotations are more important
wendyreid: In terms of publishing with annotations, wouldn't these be embedded in the content? This is part of the book
seth: So if a famous author is editing their own book, annotates it, then send it on to the publisher the natural way is annotations in the epub
… so are we creating a world where there is a separate system to make these annotations?
shiestyle: Actually image based characters are more important than ruby
… but I am not sure about the publishing the annotations case
George_: Annotations point in to the book, footnotes point out. Second if we are not using html and someone inserts an image, is it just a jpeg with no alt text, etc?
laurent: So for image annotations? For body we could easily add alt text as plain text in the json
… with the body as an object, we can add any property
wendyreid: Thank you for the update
ISO and Liaising with ISO/IEC JTC1/SC34
wendyreid: Two things to discuss, first is ISO port of epub 3.3 to ISO
… By which I mean the full family of specs
… we agree it should be done, but timing has been an issue, due to some EU complications
… we now have some info about that. There remain some unknowns, the short description is the EU a11y act caused a letter to go out about publishing standards, specifically EPUB.
… This is all good, and it means the EU will adopt EPUB.
… the problem is kicking off ISO process may cause problems with that adoption. We have some questions - what exactly is the problem? Just starting it? voting? etc
… And does this apply to everything or just a11y spec?
… we are still trying to figure out who is talking to each other at ISO and w3c
cristina: This all sounds accurate
… The committee needs to wait if there is an ISO spec in process
… Second, the commission will accept the w3c standard
… So I am glad the commission has contacted w3c so we can better understand the timeline
makoto: We also have Yong-Sang from JTC7 SC34
… Perhaps he can comment
Yong-sang: I have only heard about this from you (makoto)
makoto: Can you give our position?
Yong-sang: EPUB a11y is important to ISO, as members can adopt 3.3 as a national standard
… This is why we really want these in ISO, so we can adopt these important specs
<ivan> See presentation slides
makoto: I have been a member of SC34 and w3c and epub for decades
… I will be chair of SC34 shortly
… I have a new company working on bringing LCP to Japan
… LCP is not w3c rec, it was created by IDPF and Readium. It is now part of SC34
… There are a lot of committees, including one on AI. ISO is the right place to discuss things that matter to a number of countries.
… We are currently looking at scrolling comics, EPUB, LCP
… there are a number of groups under SC 34
… [see presentation for list]
… we have some specs on EPUB3 preservation
… AHG1 is for scrollable comics, but it does not make specs
… it could create terms of reference that could make a spec, but it is hard (multiple countries have to agree and nominate 5 experts)
… This is recreated yearly (it is an ad hoc group, so not permanent)
… Currently there is no proper relationship between this group and SC34. I would like to present documents from AHG1
… I am looking into filing documents for this now
… The current specs at ISO are very old
… I have not been able to update these
… we also have epub 3.0.1, these are also very old, but are listed as current
… same applies to epub a11y
… Now to summarize normal vs. fast track process
… Normal has lots of specific rules that have to be followed (e.g. May is not really used)
… PAS or fast track is used for moving things standardized elsewhere
<cristina> it is worth to highlight that the EAA has a global impact as all international organizations willing to sell in Europe should comply with the EAA requirements and standards
wendyreid: Question - does this mean we don't have to do editorial work to change language?
makoto: correct. I don't know where that idea came from. There is a cover page that will be handled by ISO, other minor things
laurent: So pagination since it is PDF there will be some changes, that is ok?
makoto: Proposal - SC34 should withdraw the old specs
… This is really bad, these should not be the current version
… I strongly advise that EPUB 3.3 and a11y 1.1 be submitted with NO changes
… Since I will be chair, I hope we can establish a better relationship
wendyreid: Thank you, this is good to hear. We were worried about making the changes, so that makes this a lot easier
… the existing relationship was with publishing @ w3c, so I would like to understand if that still includes us since we are under that
… I am very interested in the scrolled comics work
AvneeshSingh: we are aware of the ISO process and the requirements
… We are currently wrapped up in the political issues. Not everyone is in the same loop
… There are discussions with EU, and with ISO, and with w3c and ISO and these are all different conversations
… I am concerned that we are having all these discussions without a proper strategy in place
… I am tired of the adhoc relationship, we need a proper strategy
makoto: In the context of wcag I have had a lot of problems with the EU.
… Many japanese changes have been rejected
… my opinion is that a special relationship with w3c and EU is a problem
cristina: This is really a national issue, but it is also a business issue. There is a BG that needs to be involved
wendyreid: One challenge has been that we don't have all the information
… I did know not that the commission and w3c had been talking
… and that the commission and w3c have been talking
… this is a big deal, but we really need to know who has been talking
… and it is very odd that people are talking and not including the chairs
… so I think we can move ahead with liaison with sc34 for now
… and try to figure out the rest
mgarrish: We really need to get to a place where these can be kept in sync
… I was editing the metadata for conservation document, and I had to keep saying what was different between these specs
… the current space is simply not sustainable
cristina: When we presented to the commission it was as w3c
… we have had a problem with people contacting w3c and not getting a response
… this is an opportunity we don't want to miss
wendyreid: Pedantic question - we have epub 3.3. and a11y 1.1, but we are working on 3.4 and 1.2. If we publish one version, can we leave 3.3 with the EU? Or can we not publish anything?
makoto: The fast track process is quick
laurent: How many countries have to say yes?
makoto: I don't know. But many will just say yes, because they lose voting writes if they fail to vote
ivan: Makoto, as far as I know, we have to go through an editorial process, right?
… that process means going between the two formats is a lot of work
makoto: I strongly believe that is incorrect
ivan: WCAG had to go through this painful process, why are we different?
makoto: I reviewed the wcag ISO with w3c and the only difference is the cover sheet and index
Yong-sang: JWG7 would like to take the responsibility for the editorial changes. We would like to pursue with just adding the cover page, but if there is a different position, then JWG7 would like to take the entire conversion effort
… Just format work
… Without changing the requirements from the original spec
ivan: Thank you, it will be an enormous help
… I don't know who to contact for a once and for all final statement on what we need to do
… we keep hearing different things
… who at ISO has the official role to make such an official statement?
… if it is just the cover page, then this radically changes the situation
… Then the 3.4 question becomes more interesting
… but where should we go for a proper answer?
makoto: Since I will be chair I should set up a meeting with ISO Geneva and this group
… how does that sound
Yong-sang: we have 2 very strong options - [talk to the technical program manager and also makoto can talk o the editorial team at Geneva
cristina: The EU will not publish an official standard, they will adopt the W3C version
ivan: The message I have from the EU is don't publish an ISO standard. So my question is can we work in parallel? Can we leave the w3c spec alone, and start working on ISO, but not publish until the EU is ready?
… if we do this with 3.4 since it is a good 1.5 years out
cristina: we should organize a meeting with the commission to answer that
cristina: I think it is important understanding if the spec is alignment with the commission
AvneeshSingh: Fast-track will start after 3.4 after it is done. I don't understand how we could start it now?
… it has to be rec track first
<ivan> avneesh: epub 3.4 /a11 1.2 are rec-track
AvneeshSingh: I would like to get to an arrangement where EU isn't lagging behind
makoto: I have a fundamental concern that giving EU special status is unfair to other countries
… I respect the work done, but it doesn't mean the EU can decline what other countries do
ivan: I am not sure what is a problem, re AvneeshSingh
shiestyle: How long does it take
makoto: 8 months plus bit, so say 1 year
… if we want to delay we can request that
shiestyle: Can we stop publishing?
makoto: you can always withdraw at any time before publishing, even if all countries have voted yes
shiestyle: so it is canceled?
wendyreid: Yes, but we could restart
cristina: I don't think EU will stop. The question is an international one, so we can sell everywhere
… I am not so sure that everyone in Japan agrees. This needs to be a business decision
wendyreid: let us drop the international issue. This is about logistics. We don't have all the info yet, so we need to figure that out first
yong-sang: I am curious about the EU standard you are referring to? What standard do you mean?
cristina: There is not standard for ebooks, they will adopt a technical spec
yong-sang: Usually the ISO standard is auto (maybe) adopted by EU
… We should make epub a living standard
George_: I love that, it sounds great. I want to move things forward in parallel and avoid the sequential nature
… I don't like having to get it locked down, then sent to ISO, then having issues that can't be resolved
… getting things to move forward smoothly would be grat
makoto: when epub 3 was submitted there were a lot of requests for changes that I resisted
AvneeshSingh: We need a proper relationship with ISO, figuring that out will solve these issues
… To ivan it was about 3.4 going to ISO
ivan: I misunderstood
wendyreid: I have reached out to see who I should talk to, apparently it is Rigo. We need to figure out the parameters on all 3 sides. Would be great to have all 3 in a room
… we do not want to favor one group over another
makoto: Do you feel comfortable with an official relationship between us and SC34?
wendyreid: No problem, sounds good
George_: I hope the ISO publication is something that is not in PDF would be important to me
ivan: Two things. One is I hope we are talking about the 3 rec track docs, and not unbundling
… second, to broaden what George_ said, my understanding is that what is published in w3c and iso the two texts should be identical
… I know it is hard to get ISO docs into the public as html. I don't hold my breath though. W3C will still publish as html and make it available, so I don't really care
wendyreid: What do we have to do to get the relationship done?
makoto: We just have to file a form. We just need to find someone to sign it
Daihei: What are the next steps on the international relations side?
wendyreid: Next step is to find out who is talking to who. Then maybe schedule a meeting where we can all meet
… For instance, understanding timelines would be very helpful
Daihei: From the global publishing side, the reason we need to take into account EU is the eaa has already been enacted
… those a11y requirements affect the entire global community
… The global system is interconnected, we have to give due consideration to all members, including the EU
… The reason we must take into account the situation regarding EU accessibility is that the EAA has already been enacted
as a binding regulation, and its accessibility requirements affect not only Europe but the global publishing industry as
a whole. Similarly, in the United States, the ADA is in effect, and Japan and other countries each have their own local
accessibility laws. Since the international eBook ecosystem is interconnected, we cannot disregard the specific
circumstances of each region. In my view, it is both natural and necessary to give due consideration to the established
EU context, as it cannot be ignored
wendyreid: That is what has made this so difficult
… we understand the importance of all sides here.
duga: Love having this conversation over and over again, I want to have this joint meeting, I would like to see that the EU has been saying "don't go to ISO until..." we need to know the "until"
… it doesn't have to be an exact date, but we need to know a date
George_: The tricky thing is getting someone to speak with any authority
<seth2> Regarding the discussion around whether we are required to apply the editorial grammar rules when using PAS:
<seth2> In ISO/IEC Directives, Part 1 – Consolidated JTC 1 Supplement 2023
<seth2> https://
<seth2> "F.3.4.2 PAS Submission”
<seth2> Paragraph 5:
<seth2> The format and content of the submitted specification are not required to comply with the
<seth2> ISO/IEC Directives Part 2.
seth2: I have no context for a lot of this, but I did some research on fast track process
… [see link]
… basically contents does not have to be updated
ivan: The problem is, that used to be the case for sure. The info I got 2 years ago is that ISO changed this
… so we have to check that that is still the official statement
makoto: Lots of things happened to normal process, but not to fast track
Update on Digital Comics
shiestyle: We'll start the afternoon session, update on digital comics, Hadrien has a presentation
Hadrien: Tried to summarize where we are right now, afternoon sessions will be related to comics
… not necessarily have the discussions now, but set the table for those later discussions
Hadrien: if I had to summarize why we're doing this at all, EPUB is also for comics, not great for comics
… it shapes a lot of the current work
… when we look at adoption of EPUB for comics, it varies by country
… in Japan, it's an interchange format, you get what you need and discard the rest
… in Europe and the US, it's different, ebookstores use EPUB as is for comics
… not just interchange, but also display
… what we've also seen, many of those stores also accept PDF
… specialized stores, ones that specialize in comics, many don't use EPUB at all, some may ingest it
… in South Korea, they pushed for a TTA standard (local), for continuously scrolled comics, they consciously chose not to use EPUB
… EPUB is not the default standard for comics
… it's used, but there is no single place where it's the standard, it always lives alongside other formats
… example of new comics store, SweetShop, they sell PDF
… other one, Panels, more EU, they'll be using CBZ/PDF
… speciality stores not using EPUB
… and why are people not using EPUB?
… it's a number of things, in some cases, people think PDF is good enough
… it has native support
… there has been a community standard, CBZ, which has been out for a long time
… good enough for people for a long time
… those have played a role in EPUB adoption
… EPUB makes it hard to work with images, we can talk about this in the afternoon
… we don't provide clear industry guidelines
… different places have different ways to use EPUB, EBPAJ, more like a template
… no guideline to "properly" do comics in EPUB
… this seems more necessary for comics vs other publications
… neither PDF or CBZ can support continuously scrolled comics
… places where EPUB is better, other formats don't have spread control
… spreads are under and over specified
… last area we are better, metadata and semantics
… we have useful, specialized metadata
… even EPUB basic metadata, but we don't have the full metadata for comics yet
… we have semantics from DPUB ARIA, etc.
… need more added for comics
… where we are now with EPUB 3.4
… images in spine, contentious topic, but ask questions for our discussion later
… we have AVIF and WEBP support, modern image format support
… moving in the right direction
… we agreed on "roll" as a layout value
… we haven't agreed on how to deal with those documents, what is in the spine
… we have open issues on spreads, there are a few things that need to be addressed
… comics specific metadata
… semantics, need more discussion
… some progress, lots to discuss
… let's talk about images in spine, primary need is to identify an image for a specific page
… what we need is an ability to say "where is the image"
… might be less contentious than images in spine
… images in spine currently possible with fallback
… usage today, we know in Japan do images in spine without fallback, there are also publishers using images in spine with fallback
… it's not new, people use it today
… questions we need to ask, should we allow them
Hadrien: Can we allow them? Do we do it for roll documents, pre-paginated, if we do it, how far
… if we don't allow them, how can we make things easier?
… we need to test things out in several different ways, if it was clearer where to find the images, maybe that would be better
… we know there is usage of fallbacks, it is in use in Japan, EU
… there are many that use it right now
… we might need to use a new property, or lean into what people are doing
… roll documents, we're blocked a bit by images in spine, we either say we do images in spine, or fallback
… everything else would be a missed opportunity
… if we force HTML in the spine, it's complicated for the sake of being complicated
… expectation gap between what producers are doing and EPUB
… expectation on the market that first page is displayed on its own, regardless of spread info
… but we don't say anything about it in the spec, we should align with expectations
… what does it mean when we have page-spread-*, the spec says it is meaningful, production differs
… some people always include it
… it means they want control, but there is a mismatch
… I don't think it is a bigthing to solve but should be
… how much control do we want to give over spreads?
… values are overused or problematic
… for semantics, we inherit many values from AHL WG, mostly to describe contents of a page, but not used much outside
… there is a need for panel by panel, Amazon asked content producers to provide, but they need to use specialized software, there is interest in panel by panel
… shame people don't use EPUB
… we also have the ability to indicate volume and chapter
… in Japan chapters are sold, but elsewhere it's volumes containing chapters, but we can leverage that
… we need new things for continuous scrolled comics, we have seasons, episodes, issues
… it could be relevant in a variety of markets
… metadata, we need additional metadata, similar to document divisions
… to say an EPUB is a volume of multiple chapters
… question of EPUB or ONIX
… we've had people ask for this, need series, story arc
… just wanted to set the table for other discussions
ivan: General question, before we dive into the technical discussion, lets say we solve all these issues, has the boat sailed on adoption?
… would we change the picture you painted at the beginning, whereby most people don't use EPUB
Hadrien: Good question, for paginated comics, we may have missed the boat, but for continuous scrolled comics, things are behind closed doors, there's no cross-platform standard
… I could be wrong about paginated comics, but things can changed
ivan: To be more specific, we have the W3C process, if we do all the changes in some way or other, will we even have enough meaningful implementations to pass CR transition?
Hadrien: Images in spine, we probably would, many of those reading systems don't consume EPUB
ivan: If I wanted to be a purist, it would be irrelevant to transition
Hadrien: I'd need to look into it, it's supported in some reading systems, two might be possible
… for roll, that's new, we'd need new implementations
… for spreads, its aligning with what people already do
… semantics, what do we expect RSs to do with this?
… seasons or episodes may offer breaks in the scroll, but its an unknown
… metadata, depends on our expectations for RSs
ivan: What we used in 3.3 for metadata, there would be at least 2 systems that make a valid use of the metadata, how they use or display the content is not in our control, but if its useful to have it
Hadrien: The state of EPUB metadata is complex, there's cases where ONIX is preferred, the main use is sideloading, if we target that, we could have implementations, but it would be doable
<Zakim> fantasai, you wanted to ask about slides
shiestyle: If they are optional features, they don't need to meet the criteria?
duga: I want to disagree with Ivan about implementations, a reading system is more than a device, if a reading system can accept features and eventually display them, that's an implementation
ivan: I don't think we disagree
duga: My question then, some of these things, finding the images in the HTML, these feel like heuristics
… I don't know if these belong in the spec, or a separate document, if you want to do this optimized image thing, look here
… does this need to be in the main spec
Hadrien: I think that's a good question, we may need a best practice document for comics, I agree, some of this is heuristics
… I agree that not everything should end up in the spec
… it could be in a complementary documents, recommended semantics and metadata
… less fragmentation
… even in single markets we have fragmentation
toshiakikoike: Question, implementation for images in spine, if Voyager's and Kadokawa's reading systems implemented, would it satisfy W3C's standard?
Hadrien: These are already implemented?
shiestyle: I think they are, if both of us have these features
ivan: I don't know the internals, if they are independently developed, they meet the requirements
Hadrien: And it works in Thorium as well
wendyreid: Had this discussion with EPUB 3.3
wendyreid: There's the W3C implementation bar: 2 independent impl of a standard
wendyreid: We also have discussion with 3.3, we agreed that, 2 was not quite enough for publishing.
wendyreid: Because of the huge diversity of reading systems and reading platforms
wendyreid: It's great to have 2, but 2 is not enough to reflect that feature being well-supported
wendyreid: If we have 2-3, it means we cleared W3C bar, but on the way to our own declaration of well-supported
wendyreid: I think us meeting the W3C standard is relatively simple
wendyreid: it's more whether publishing industry supports that we need to worry about
Hadrien: I might be wrong, I think we'll have more than 2 for AVIF, it's more than that for images in spine, quite a bit more, spreads and so on
… there's always a risk when we introduce new things what the support is
shiestyle: Any questions before we get deeper into this?
Images in spine
<shiestyle> https://
shiestyle: The first topic is images in spine
Hadrien: I think this has been contentious, we've discussed for a long time, it came up when we first discussed FXL
… we know that images in spine are used, we also know that people have issues with them, mainly for accessibility, I kind of feel that we're stuck in the same discussion loop
… we have the same arguments for or against
… we never manage to move forward
… we're stuck as a result with the status quo, my questions I hope can move us towards a solution for this
… we have some options within the spec, other options might require changes to the spec
… we should avoid the status quo, I don't think it's good to have a difference between the spec and the industry
duga: So you often point out that there aren't really accessible comics, or they are hard to do
… I agree for comics, it doesn't make sense for XHTML, but for FXL we do have accessible content
… in that perspective, it is an accessibility issue for FXL, this subset of content is huge, comics is a big industry
… for children's books, it's good that that content is accessible today
… people are making use of these features
… it's not fair to disregard the accessibility aspect
… but if we do something for comics, that is weird, but we have rolled content, not sure if we should forget about HTML in this respect either
… the other question, you listed two options, image in spine or image in spine with fallback HTML
… would HTML in spine be illegal for roll comics?
Hadrien: Not saying it should be illegal, it would be disappointing to those producing that content
… we shouldn't force people to put images in spine, but shouldn't force HTML either
… would negatively impact adoption
LaurentLM: In every specification, certain things are triggered by certain metadata, roll comics are triggered by specific metadata
… we could say accessibility of scrolled comics is different, if we say we want to do the same for paginated comics, or do something different
… we could extend the time of solving the accessibility problem
… we don't have that content on the market, we don't know what an accessible comic needs to look like
… more research needs to be done
Hadrien: There is a difference between partially accessible comics vs fully accessible comics, we don't know what makes a fully accessible comic
LaurentLM: Just adding HTML to comics doesn't make it accessible
rdeltour: I have a simple question, does it have to be EPUB
… images in spine, it creates hurdles in interoperability, could it be a separate standard, a profile, something that is different?
… another question about CBZ, basically a list of images in a zip, could be we somehow have a hybrid CBZepub?
… could an epub be a CBZ or vice versa
Hadrien: First question is good, we see some places saying EPUB is not the solution. But one option to discuss, do we do something more like web publications, SK is doing JSON with metadata and some controls
… it goes to Ivan's question, has the boat sailed
… but for some markets, EPUB is huge, like Japan, we can't pretend people don't use it
… for CBZ, the order of images matter, the .epub may not be recognized by CBZ readers
… you could name images in a way that works for CBZ
… you could make something that works for both
… or a packaged web publication that could also be an EPUB at the same time
… maybe a little too creative there
wendyreid: I think I share Romain's question, does this have to be EPUB?
wendyreid: One of the underlying parts of this discussion is, philosophically, what we think EPUB is?
wendyreid: Do we think that, as the group that maintains EPUB, who do we serve and who do we follow?
wendyreid: We try to strike balance between what industry wants and what readers need
wendyreid: And lately also government regulations
wendyreid: On the surface, about images in spine, questions what do we want EPUB to be
wendyreid: Many of us fought for EPUB to be the accessible standard, accessible by default.
wendyreid: Images in spine is where we need to make decision, in order of priority, where do we put things?
wendyreid: Does accessibility trump everything?
wendyreid: Disappointing that some markets didn't choose EPUB as the standard, for variety of reasons
wendyreid: But companies releasing apps with PDF or CBZ are not thinking about accessibility
wendyreid: in their application or business model
wendyreid: That's a choice that they made in their business
wendyreid: But do we want to make that choice for EPUB
wendyreid: We know there are many inaccessible EPUBs out there, because businesses made that decision. But for EPUB, you have to make a *choice* to make inaccessible. We give all the tools, they choose not use.
wendyreid: But here we would give them a tool to make inaccessible content.
wendyreid: Make that possible.
fantasai: What are the implementation challenges with having images in spine vs in HTML
Hadrien: Apps that implement this, they don't use webviews, they use platform APIs, with HTML they need to find ways to render those images, if its SVG they need to rasterize the images
… not saying they should do that, but that is what they do
fantasai: Is there or has their been an effort to create a profile for HTML that prioritizes images?
Hadrien: Japan has it, it's not used by everyone even in Japan, it's something you know if you're in industry, but it has no official status
… the closest would be the EBPAJ profile
fantasai: Would it make sense to standardize on that?
Hadrien: Possibly, it falls on the line of having an alternate profile or best practices document
fantasai: The HTML file would need to conform in a spec, it would validate, for reading systems would know to parse as an image, but we have the additional structure, the framework for creating accessible content is still there
Hadrien: The reality would be it might be fragmented, but would move people in the right direction possibly
ivan: To put things in perspective, the approach Romain suggested is how we published the audiobook standard
… it follows the rules of Publication Manifest, it's an analogy
… a very different point, at some point in your slides, image in the spine fallback to HTML as a solution, there were two other approaches discussed, one was suggested by Matt
… referring to the fact you could put the alt into the package, it's legal in the spec,
… other possibility was to include the accessibility info in the image itself through metadata
Hadrien: The first is to use meta:refines, refine the image using it's id to provide description
… one way to do it
… those have been discussed before
gpellegrino: We can have images in spine with fallbacks, I suggest we leave the spec as is, we advise on how to make comics
rdeltour: For the sake of completeness, in one of the slides you mention was the objective was to link a page to an image, maybe it's also possible to use the nav doc, may also be used to link the pages to the document
… not sure if that works, maybe worth looking into
seth: I have missed some of the previous meetings, we've heard a lot from reading systems people, I never hear from publishers
… I want to know what the issues are with tooling to add the necessary accessibility info to documents
… it can't just be there's no interest
… there must be challenges
… is there a gap in the EPUB production process that blocks this being possible
Hadrien: A page in a comic can have a lot of information, you'd need to describe each panel, and even within panels
… comics are visual by nature, for screen readers, you'd need to produce text in the right order
… almost a transformation of the content, like a novelization
… there's a huge complexity in how to produce the thing
… do you need to get the author involved, are you following the author's intent?
… lots of open questions and cost associated
… if the resulting text is just a huge block of text, it's not functional either, it would need to be a full HTML document with everything you'd need
Hadrien: Some of it is cost, some of it is technical, there's needs beyond just screenreader users
… one panel at a time plus text to speech, not only do you need equivalent text for a given fragment, then we have tactile images
… we can do some of that today, we can't do what say EAA expects
ivan: I want to come back to what Gregorio said, and the spec of today allows what you need as allowing an HTML file as fallback, I may have misunderstood the second part, this may only be valid for roll comics
… I would be uneasy to add something to the spec for just one type of content
<fantasai> +1 ivan
ivan: it relates to what Hadrien said, falling back to an HTML file, seems to be only a rudimentary way to handle accessibility for an image
… not sure we can handle it today
<rdeltour> +1
gpellegrino: Ivan, my proposal was not to allow this way only for roll content, since it's already allowed for any content in the spine
… my proposal was to have guidelines for producing comics
<ivan> +1
fantasai: I wanted to scope the question down to sighted users who need accessibility support?
… to make that work, you need to have a format to support that additional content, you need a reader to support that, and you need tools to produce that content
… does any of that exist?
Laurent: No
fantasai: If we want EPUB to be able to do this, is images in spine getting us closer or further to that?
Hadrien: We're years away from being able to do what you describe, its too early to say, I don't think it would be a step in the wrong direction to add images in spine
… if we really want to achieve comics accessibility we can say its someone else's problem, or we can work towards it
wendyreid: Discussed in fixed layout accessibility task force about that. How do we make this possible?
wendyreid: We have some proposals, to solve what Elika described
wendyreid: Discussing side-by-side content
wendyreid: parallel content that's related to each other
wendyreid: I don't think we're as far away from this as we think we are
wendyreid: There are reading systems already that do side-by-side content (forgot name)
wendyreid: One that allows fixed layout and relayout together
wendyreid: A lot of it, unfortunately, it's about tooling.
wendyreid: Lack of will to make this happen
wendyreid: Especially nowadays, with AI, offers us a lot of ways to automate this that previously would have been fully manual
wendyreid: Only a few years ago, alt text for comics would have been fully manual, now can automate much of it
wendyreid: Image detection of panels
wendyreid: Etc.
wendyreid: I'm reluctant to say that it's not possible. It's increasingly possible.
wendyreid: Alternate format providers are already doing this work, just mainstream publishers are not
wendyreid: So I'm reluctant to give in on this.
wendyreid: We have the technology. Some of the tools already exist.
wendyreid: A lot more publishers can do in content development that they're not doing.
wendyreid: And more on reading system side that could make it possible
wendyreid: I've seen scrolled fixed layout content in EPUB readers. It's not impossible.
wendyreid: Doesn't mean we should make provisions in the spec to sacrifice our principles
shiestyle: We have 10 minutes left, we want to conclude this topic in TPAC, maybe gpellegrino's proposal, using the spec as is
… we will not make consensus to make images in spine without fallbacks
… should we vote on this?
Hadrien: I think some people don't like image in spine with HTML fallback but its the current spec, having a best practice document that describes how to do this, that is doable
… it solves what I was mentioning, that helps to drive things toward clearer guidance
[Seth asks question about tooling and alternate text in Japanese]
seth: Can someone from the Japanese publishing community share why they don't produce accessible content, is it tooling or something else?
toshiakikoike: When preparing alt text for manga, just the speech bubble text is not sufficient, but people make prepare the description of the story, we can't prepare that content without the author
… it's difficult to prepare that content
ここには日本の出版社の人がいると思うので、聞きたい。漫画はなぜアクセシビリティをサポートしないのか。どういう理由があるのか？
Ito-san: Japanese publishers don't have the right to produce that type of content, only authors can
shiestyle: I'll explain this a bit more tomorrow, manga content is generally out of scope
漫画のアクセシビリティというのは、何を情報として含めるのかが難しい。ただセリフをテキストに変えさえすれば、漫画のコマに含まれている情報を正確に伝えることができたというのかというと、そうではないとも思っていまる。
Hadrien: Just wanted to reply to Wendy's comment, and it leads into the next discussion
… there's a number of documents that can't be made fully accessible, we have children's books, textbooks, comics, the solutions for all those can be slightly different
… there's options for magazines, newspapers, there's content out there where you can view articles
… we don't have a way to support those in EPUB
… I've talked to many people, but they are missing the format, they don't know how to distribute it
… I don't think comics fall into that, comics is a lot about storytelling, comics have more in comics with media overlays or SMIL than textbooks or newspapers
… there's AI solutions out there, but they haven't been tested, and they don't have a way to represent that
… there's prototypes, but it's still early
… we don't have an easy way out of the hole we've dug ourselves into, is it now or in the future? Up to us
ivan: The way I read the standard now, for each image you'd have an HTML fallback, ideally one HTML with the alt text, making the publisher's lives easier, but you can't refer to a fragment in a fallback
… if this is our solution, we force the author to produce one HTML per image
Tomikura-san: What accessibility features do people want?
Hadrien: We hear from people that there is interest, people want access to what their friends are reading
… also with EAA, in theory, most books on the market will be natively accessible, orgs will re-orient to focus on different types of content, usually education or comics
… orgs want to produce the content
… maybe publishers won't do it, but alternate format providers will
… with Marrakesh treaty, people can do this, we might be in a world where speciality providers can do this work
… it doesn't put burden on publishers, but it does create challenges for the providers
Process Discussion
Brent: I'm from the AB and I'm here to help!
Brent: Feel free to contact me outside this meeting also.
Brent: Scope of what we're looking for feedback on.
Brent: Chartering a group - how did that go? Was it straightforward?
Brent: What about publishing?
Brent: What problems block you from moving along REC track?
Brent: Are there things in Process to make easier?
Brent: Have you ever dealt with formal objection? Suggestions for improvement?
ivan: My experience as Team Contact, most complicated for each group is handling horizontal reviews.
ivan: It's very difficult to know when to start a horizontal review, and how.
ivan: When you start, you get avalanche of questions which are not always relevant to the WG you're in
ivan: Each WG has different requirements. EPUB vs Verifiable Credentials, for example.
ivan: So faced with HUGE questionnaires, requires a lot of work to say whether relevant or not.
ivan: Tendency of requiring a lot of work up front is becoming worse and worse.
ivan: TAG asks more things than it used to, etc. keeps getting complicated.
ivan: I consider horizontal review to be essential, but this process needs review.
ivan: So far glad I didn't have to handle formal objections or IPR issues
wendyreid: I think we're an awkward group to ask, as Ivan has spared us from difficulties because he is able to answer the questions
wendyreid: Also lucky not to face FOs etc.
wendyreid: Most of the truly thorny things we've dealt with in the Process have been things related to publication, knowing that we're doing right steps at right times
wendyreid: Candidate Amendments for RECs etc.
wendyreid: The thing we were trying to do was very simple, just needed to make some corrections.
wendyreid: We spent weeks just figuring out exactly what we're supposed to do.
wendyreid: Once we did it, it was fine, but ... debating level 2 vs level 3 change, etc.
wendyreid: We debated a lot of it, and it took longer than it should have for some necessary corrections.
wendyreid: Clarify to spec.
wendyreid: Falling into process quicksand where a lot of pathways, hard to tell when criteria apply and when they don't, to what degree, etc.
Brent: Good feedback. Even knowing that ability to navigate helped by having a good Team Contact.
fantasai: I've been on the other side of formal objections, one of the challenges is finding information on it, the council page is not the easiest to find or navigate
… we should have a website with the information, easy to find
… probably true of many things, where the process is not an issue but finding the necessary information is challenging
… for most cases people shouldn't need to read the process doc, there are some exceptions, the amendment process is complicated and needs to be made more easy to understand
… it's not supposed to be that complicated, even if it has complications to it
Brent: We found it easier to do an 1.1 vs an amendment
fantasai: The amendment was more for corrections
ivan: Brent said what I wanted to say, the amendments process was difficult, and a tooling issue, so it was easier to go through the rec process
… it's difficult to markup the changes, it was challenging, in other cases tooling like ReSpec is helpful
Brent: Would also like to hear from editors.
LaurentLM: The burden is to use ReSpec, but it's a good tool, so no real burden.
fantasai: I'm in a Bikeshed group, and same, it's easy.
ivan: We have had, still have, problems with Invited Expert restrictions. We've had people whom we couldn't get ans an IE, or only with an enormous fight, because person happened to work for company which recently left W3C.
… that created a lot of problems for us, because that person was indispensable to the WG. Similar case now also.
… So issues around IE position, which is related to the whole Membership discussion at W3C that regularly comes up.
… It's a problem for WGs in general. Maybe Wgs lack enough people, and any obstacle that makes it difficult to get people who do the work is a problem.
… This WG is in the same position.
fantasai: There are two reasons the restrictions exist, one is business reasons, the other is IPR, trying to solve this problem would require considering both
Brent: will have breakout on Wednesday to discuss this, and AB-led Member Meeting which everyone is welcome to join.
… We want to hear from you, so don't hesitate to reach out.
Image in Spine (cont.)
<shiestyle> https://
fantasai: Did we conclude on the images-in-spine issue? Should there be a resolution?
ivan: Agree that having a resolution is what we need
… but I wonder whether we can make the formal references to fallbacks a bit more flexible than they are today, to make it easier to collect all the hypertext into one file instead of one per image for 200 images
… Might require adjusting how fallback is identified in the package document
… Maybe an additional entry which would allow referencing a fragment in the fallback file
… Because right now we don't have that
Hadrien: So, saying you'd have a single HTML with all the text, and you'd have the fallback point to a fragmentID
ivan: Yes
Hadrien: If we do that, that opens a lot of other questions
duga: That fundamentally changes fallbacks and the spine and how this works.
… Maybe a great change, but much bigger change.
… Fallback in the spine is meant to be, this is the content document you can use instead of this other document.
… You can just swap the files out
… But we don't have fragments of documents in the spine. In fact we have specific restriction on re-using a document in the spine.
… Avoids complications with navigation and paging etc.
… So this is a giant can of worms.
… If we do fallbacks, we should do fallbacks as we do now
ivan: Ok, but we have a problem.
… image in the spine with HTML fallback is technically true, but very impractical
Hadrien: Yes, it is impractical
wendyreid: I would agree it was impractical if 1) it wasn't already how things happen and 2) if person who is making epub had to hand-write every HTML document
… but this is automated. It's not difficult to produce the files.
… The tooling is already there to do it, workflow is there to do it.
… If there was a size concern here (and the size here comes from the images, realistically speaking), maybe
… It does seem a bit silly to have 100 HTML files that aren't used, but in terms of effort it's not a big deal.
Hadrien: My suggestion comes from pragmatic viewpoint which is what's out there
… I see 2 things
… Images in spine with HTML fallback, and HTML with image fallback.
… We should recognize these as valid ways to deal with this problem.
… not have it be word-of-mouth
… So we need to acknowledge what's out there.
… Secondly, one of those two should be how we recommend authoring content.
… "this is the way you should do it"
… Not necessarily in the spec, but that could cover other comic-related issues
… We can also recommend other things like metadata, semantics etc
… With that approach, we won't break anything, won't ask anything new, would just say "this is what is used, and this is what should be used"
rdeltour: If we knew how well fallbacks are supported in reading systems
… we do have some tests for manifest fallbacks
… but those are about one single document having a fallback
… but I wonder if someone has tested when all the documents have fallbacks, how does that work, how to transition from one document to another
… whether this is sufficiently tested to be a viable solution
gpellegrino: I think the time is not right for thinking about solutions for comics etc. So opening the possibility to just images in spine maybe problematic. So suggest we continue as we have now, postponing the discussion, and we can open a task force thinking about a11y and comics
gpellegrino: Maybe inside the a11y task force we already have
gpellegrino: but I wouldn't take it up right now
ivan: I agree
ivan: Laurent, is it possible for you to take a typical example which has fallbacks with HTML and has a relatively large number of images, and turn it into a test case for our test suite?
LaurentLM: Yes
ivan: It would be a valuable addition to our test suite. Romain is right, we have a basic test, but we don't have a good stress test.
ivan: With that, I think repeating what Elika said, I think we should have a vote and have a resolution on what we put for advice for this type of documents
LaurentLM: I totally agree, and disagree with Gregorio
LaurentLM: We don't validate 3.4 today. So we have time to make a pre-recommendation, and ask reading systems to support what's in the spec
<gpellegrino> +1 to Laurent
LaurentLM: We can easily make the evolution to support fallbacks if we know this is the right direction.
LaurentLM: So let's make a pre-recommendation that is a resolution of this
LaurentLM: And then when we make 3.4 we will be ready, and reading systems will be ready
ACTION: LaurentLM to add a images-with-fallbacks stress test to test suite
wendyreid: Something to consider is images with XHTML fallbacks, those happen to have alt text which is great, how do I signal to reading system that I want the fallback instead of the images?
… Most reading systems don't open the OPF file to see what's there.
… Maybe we now need to make fallbacks more obvious to users?
LaurentLM: There's a simple way. If there is a version of a comic with some accessibility description, then the publisher should put it as the first choice. Image as a fallback.
LaurentLM: Favorite of the publisher should be first.
Hadrien: That doesn't work. Many have put HTML first and images as fallback because it works in more systems, e.g. Apple Books can't work with images in spine.
… So I don't think HTML in spine signals an intent from the producer
… It has more to do with the state of the industry than anything else
… There's no easy way to signal this preference.
… We have a problem in general with fallback. We use spine to convey information instead of using manifest.
… If we go in that direction, we're uncover a number of problems with how we do information in spine
duga: Would go a step farther and say, if you have an accessible HTML document, you've made an accessible comic, don't put an image in the spine
… Might not work in some crummy reader, they should update.
<Hadrien> +1 for what brady just said
duga: You spent a lot of effort making that.
… So should only do this for comics that are otherwise inaccessible.
… If there is useful HTML accessibility info, put it in the spine, don't put images there.
… Similarly, for childrens books. Put the HTML in the spine. And that can be covered in the note.
wendyreid: So maybe better resolution is, we're keeping the spec as-is, but we are in agreement that comics deserves better guidance, so we want to write that guidance.
Hadrien: And want to acknowledge what has been done for last 10 years, in millions of files.
fantasai: Brady covered what I wanted to say, if we are writing best practices, if you do it clearly enough, but if its clear enough readers that use images can extract them, enabling that functionality
… while making the content more accessible for readers with better capabilities
PROPOSED: Write a best practices document for comics content as a separate working group note. No change to the specification for images in spine.
<fantasai> +1
<Hadrien> +1
<duga> +1
<shiestyle> +1
<ivan> +1
<wendyreid> +1
<rdeltour> +1
<ikkwong> +1
<toshiakikoike> +1
<gpellegrino> +1
<MasakazuKitahara> +1
<LaurentLM> +1
RESOLUTION: Write a best practices document for comics content as a separate working group note. No change to the specification for images in spine.
ivan: Should I close the issue? discussion?
Hadrien: Connected to this resolution is roll documents.
… I was blocked for this PR because unsure about direction
… But we need to decide more wrt roll documents
… We had some remaining complexity with how to describe them in the specification, that is resolved with this, we can have an example with image with HTML fallback
… We can get rid of many complexities.
ivan: I will mark the issue as needing to be closed, and chairs can figure it out
[discussion of what to discuss]
FXL Changes and Digital Comics
First page
<rdeltour> w3c/
Hadrien: What we see in the market, you have 2 types of fixed layout
… One that indicates position for each resource
… and one that doesn't indicate for anything
… partial info is quite rare
… Authors typically assume that if no positions are given, the first will be on its own, and the rest is two by two
… It is an unwritten expectation that almost everyone creating FXL documents has, but we don't say anything in the spec
fantasai: So you're proposing to specify that.
Hadrien: Yes, let's add this concept into our spec
wendyreid: That would be in reading systems, not core?
Hadrien: Core has quite a bit of language about that
wendyreid: But expectation would be in reading system
Hadrien: We'd have to change language in core. Because currently implied that if you don't put any information, then it means spread is not relevant, which is not what market is expecting.
… some language in Core is confusing, so we have to change language there and also add more to reading system
gpellegrino: Considering e.g. PDFs and ??, agree that the first page should be displayed as a single page if no other info.
… But are we allowing user to change it?
… Sometimes it's wrong e.g. for PDFs, there's an option for users to change the default.
Hadrien: I think it's a good idea for reading system to decide to use spreads or not.
… depending on orientation of device, often switch whether spread or not. E.g. portrait mode have no spreads, landscape mode use spreads.
… possible user might want no spreads in either, some reading systems allow some don't
… different from having option for first page on its own
… I don't think we need an option for an offset, but good thing to have whether you want spreads or not, but is that something our spec covers?
LaurentLM: no it's a reading system choice
gpellegrino: I agree, maybe something to suggest somewhere. But two options. One is whether spreads preferred or not. Other option is whether ifrst page is cover or not.
Hadrien: Linear no, wouldn't necessarily see it
fantasai: Not familiar with this format, each resource would say if its on the left or right?
Hadrien: Yes, the spec says if you say nothing, it doesn't matter, and if you say, there is a spread, both are not true
… what we see if people not declaring it, or always declaring it
PROPOSED: Adapt spec language in Core and Reading Systems to say that if no information about placement in spreads, the first resource should be a page on its own.
Hadrien: We're talking about the spine override in this case.
<fantasai> +1
<duga> +1
<seth2> +1
<ivan> +1
<wendyreid> +1
<shiestyle> +1
<jroque> +1
<ikkwong> +1
<LaurentLM> +1
<Hadrien> +1
<MasakazuKitahara> 0
<rdeltour> +1
<toshiakikoike> +1
<gpellegrino> +1
RESOLUTION: Adapt spec language in Core and Reading Systems to say that if no information about placement in spreads, the first resource should be a page on its own.
ivan: Who will adapt the spec language?
ACTION: Hadrien to create PR to adapt the spec language for making first page on its own in spreads
Hadrien: Also want to remove language that says that, if there is spread placement information, it means that there should be spreads
Hadrien: [quotes spec]
Hadrien: Says presence of page spread info means it's a "true spread"
LaurentLM: Says it should not be should without a spread layout -- and this is false.
https://
duga: When I joined my last team, that is how they implemented their reader, and everyone hated it and they gots a lot of complaints.
… They were following the spec, and we had to tell them to ignore the spec.
PROPOSED: Remove text saying that presence of spread information implies that the pages SHOULD be laid out as a spread, making either presentation equally acceptable.
PROPOSED: Remove text saying that presence of spread information implies that the pages SHOULD be laid out as a spread, making either presentation equally acceptable. See https://
<fantasai> +1
<duga> +1
<wendyreid> +1
<ivan> +1
<gpellegrino> 0
<shiestyle> +1
<toshiakikoike> +1
<MasakazuKitahara> +1
<rdeltour> 0
RESOLUTION: Remove text saying that presence of spread information implies that the pages SHOULD be laid out as a spread, clarify that either presentation equally acceptable. https://
<LaurentLM> 0 (ok for the direction, but the paragraph needs a bit more modifications)
ivan: Laurent, for the PR that you will do, can you add a test for the test suite?
wendyreid: We can modify existing spread tests
ivan: Anyway think about the test suite.
Hadrien: I'll ping you when I make the PR.
Orientation - w3c/epub-specs#2751
Hadrien: Seems like a lot of people oppose this property, and not many support it.
ivan: So remove or deprecate?
Hadrien: Probably deprecate
ivan: I have seen one book that used it, a French book on Egyptian temple which has photos and videos and probably handcrafted.
gpellegrino: This is a WCAG violation, blocking re-orientation of the content.
… but also some authoring tools like Pub?? which use this value a lot because they tend to add their content at full-screen on the device
… and to have it full-screen on the device you have to block the orientation
Hadrien: FXL you always contain both dimensions in the viewport. So if you want to use the full extent of the screen, force landscape, but only true for some screens and some documents
duga: and only if you have control over spreads, which we just decided you don't
duga: If the user decides they want to have two spreads in landscape, then all of a sudden you've lost the control.
Hadrien: Still the spread property where you can say both.
… what we voted on is that if you put one resource on left one o right, it's not forcing spread. But you could use spread:both, or on a spine override, to do this
… Because you can still do both, you're not blocking anything else.
Hadrien: I would be in favor of deprecating this and changing the reading system behavior, because this is actively harmful for a lot of people. Not just a11y.
Are we proposing: Deprecate rendition-orientation in Core, and also update Reading Systems to ignore it.
<Hadrien> https://
PROPOSED: Deprecate rendition-orientation in Core, and also update Reading Systems to ignore it.
duga: Should we deprecate rendition-orientation or just the non-auto value?
fantasai: If auto is the only non-deprecated value, then that's equivalent to deprecating the whole thing, so just deprecate the whole thing.
duga: Want to be clear what reading systems need to do.
wendyreid: We just say treat them all like auto.
PROPOSED: Deprecate rendition-orientation in Core, and also update Reading Systems to ignore it.
<fantasai> +1
<ivan> +1
<Hadrien> +1
<wendyreid> +1
<shiestyle> 0
<toshiakikoike> +1
<gpellegrino> +1
<LaurentLM> +1
<rdeltour> +1
<MasakazuKitahara> +1
0
RESOLUTION: Deprecate rendition-orientation in Core, and also update Reading Systems to ignore it.
<ivan> Move to https://
ivan: Deprecation means that we have to move that property into the unsupported section.
… but yeah, let's leave it to Matt to figure out the editing.
shiestyle: How about epub-check?
LaurentLM: epub-check checks the structure
Hadrien: Shouldn't affect epub-check.
fantasai: You can issue a warning.
ivan: Might need to raise an issue to the epub-check repo.
<rdeltour> +1 on creating an issue please
Hadrien: Have to be careful about warnings, some people treat them as not warnings.
ACTION: Ivan to create issue against epub-check wrt removing rendition-orientation
ivan: Don't forget to update the changelog
Deprecating flow as metadata - w3c/epub-specs#2754
Hadrien: I also opened similar issues wrt `flow` which is really under-used, and another about layout overrides and spreads.
… These are more contentious.
… Flow much less interest in it
… aside from shiestyle
… I'm not sure what you are using it for is a problem?
… But when we go back to this, flow would probably be my next target. Because I don't really understand why an author should say whether content is paginated or scrolled.
… Goes against principle of EPUB.
wendyreid: Wrt flow, was a way to declare scrolled comics in the before times. So when we add roll, we can say this thing does that better.
Hadrien: Yeah, we should do those together. But I think it's harmful otherwise.
shiestyle: But for now we need to keep scrolled-continuous, because we use this feature for contents.
Hadrien: So we would acknowledge its previous usage, and treat is as equivalent of 'layout: roll'
shiestyle: Ok, we're out of time, so let's wrap up.
closing
wendyreid reviews the agenda for tomorrow