W3C

Publishing Maintenance Working Group Telco

28 August 2025

Attendees

Present
Avneesh Singh, Charles LaPierre, Dale Rogers, Brady Duga, Elizabeth, Gautier Chomel, George Kerscher, Gregorio Pellegrino, Hadrien Gardeur, Ivan Herman, Masakazu Kitahara, Matt Garrish, Shinya Takami, Susan Neuhaus, Toshiaki Koike, Wendy Reid
Regrets
-
Chair
Susan Neuhaus, Wendy Reid
Scribe
Gautier Chomel, Brady Duga, Susan Neuhaus

Meeting minutes

Fallbacks

<Shinya Takami> w3c/epub-specs#2773

Gautier Chomel: The question from FL a11y guidance doc (a hybrid doc), on reviewing it the RS part has some stuff about supporting fallbacks. It says "in cases where it is supplied, RS should support"

Gautier Chomel: but we are missing a section on what can be done or not with them. The only guidance is in the main spec, which does not say what you cannot do
… there was some work done on auto-reflow on FL, with intent to use HTML fallback on an HTMLresource
… We realized it wasn't the right way, but if that was attempted then it means the spec isn't clear enough
… For example, can I have an html fallback for svg? Spec doesn't say no
… to me this is a question to address in the FL doc, since it is specific to reflow documents in FL docs

Gautier Chomel: but group decided not to address it there and do it here, though I disagree with that and think it should be in the FL doc

Brady Duga: why do you say html fallbacks of html aren't the right way to do it?
…did it break reading systems and not work in practice?

Gautier Chomel: the reading system already accepts fixed layout. I want you to use a fall back, we were asked to add a button to select the fall back. We can't do that.
… in thorium we will offer a fall back view, but we won't be allowed to switch between them

Brady Duga: I don't know what is right for your reader, when we created the fall back spec we decided it was legal to have a same type fallback ie html with an html fallback
… we didn't specify how a reading system can determine which file is the fall back
… I don't think we should limit the fallback and say you can't fall back to the same filetype

Matt Garrish: I agree that we could fall back to a different file type. This is an interesting case, because fallbacks weren't made with fixed layout in mind
… how do we indicate which html is fixed layout and which is reflowable?

Wendy Reid: the other thing making this complicated is that this use case is maybe out of step with the intention of fallbacks.
… "the reading system can't render the original" so it has a file it can render
… this particular usage is not that the reading system can't render the original, but that we want to give the user choices
… there should be a different mechanism for that. There could be other alternative cases

Gautier Chomel: we should not address the reading system giving a choice to the reader, that is up to the reading system
… some reading systems don't display anything when they encounter a fixed layout
… still we should know what we should and shouldn't do when an rs cannot display an fxl
… and does this go in the fxl document or the main document

Hadrien Gardeur: I have seen things like this before,
… Barnes and Noble wanted to keep the print like experience, but also offer a reflowable
… but there isn't a one to one mapping between the fxl and the reflowable assets
… B&N chose multiple renditions with a document that could map an area in fxl to the reflowable
… Hachette creates multiple rendition epubs without mapping
… fallback will not work well because of the mapping issue
… we probably need something more like an alternate
… there is a similar proposal in the comics task force
… it would be easier for some publishers to have an easy way to map the html to a resource

Gautier Chomel: let's separate the discussion about fallbacks and alternate renderings
… still the issue about what should I do in an fxl file that can't be rendered

Wendy Reid: the challenge is that an fxl file can't be shown or renders badly
… this is like the audio only readers, the problem isn't fixed layout, but that the file doesn't follow semantic html
… so the guidance we have in place would still solve the issue

Hadrien Gardeur: we are working on Thorium mobile, we already support the ability to listen to an fxl
… with a well structured fxl you can have a decent voice experience. But this isn't always the case
… we will try to process and find sentences and groups of words
… it won't work if there is no text or text is out of order

Wendy Reid: our emphasis should remain on well structured content
… but we should discuss alternatives

Ivan Herman: we took multiple rendition out of 3.3 because there was no implementation for this
… is that still true, or should we keep in the past

Hadrien Gardeur: there is implementation within propriety specialized reading systems
… not usually as an interoperable format
… does anyone know if B&N still uses this?

Ivan Herman: does vital source use it?
… if not, we should keep multiple rendition in the past

Susan Neuhaus: what is the next step? Should we make recommendations for creators?

Wendy Reid: This is for the fxl accessibility task force, I don't recommend using html fallbacks because it isn't proven.

George Kerscher: the user who doesn't want that experience may want an alternative
… can we create this?

Brady Duga: we don't have to solve the world's problems
… it sounds like the issue is we want to use fall backs
… we tried this but it doesn't work.
… for fixed layout books, we might have multiple documents point to a single html
… do we simply need to say that fall backs don't work in this case?

Gautier Chomel: one problem at a time. We just need to put a note in the fixl document
… maybe in fxl specs
… in the future we should let content creators know how to restyle this html
… in the future multiple rendition might come back

Hadrien Gardeur: what we want to do in Thorium is the style selection you can do in a browser
… and use no original styling
… I am doubtful that people will be excited about this and use it again

Hadrien Gardeur: what we want to do in thorium web is the equivalent of the reading mode in the browser, so there's no way to style this form a content creator perspective. Multiple rendition have not been used, we should not want to try again.
… I would be happy to point people to what already exists

Gautier Chomel: does anyone know of a specification on reading mode provided by a browser

Ivan Herman: I haven't seen that

ack: Charles LaPierre

Charles LaPierre: back in the day there was a reader who could show you a scan or a reflowable ocr rendering

Dale Rogers: I created an epub, fxl, a short comic, with a reflowable introduction and backmatter that was reflowable
… according to the spec I can do this, it worked in Apple Books
… Amazon wouldn't take it. I chatted with someone who looked at his epub
… they suggested uploading it as a comic book
… and not allow the front matter and back matter to be reflowable
… their creator tool requires loading in PDFS that can't be made accessible
… there are some platforms on which this will be accessible and some where it isn't
… even though the spec says I should be able to do this
… it takes me aback that I can't always use features listed in the spec

Shinya Takami: in japan, if we want to mix fxl and reflow, we generate a reflow with some resources fixed.

Susan Neuhaus: so two different discussion. One to go to the fxl group and the other to keep in mind for the future.

Brady Duga: my understanding is that we want to explicitly say what won't work.

<Brady Duga> +1 to Hadrien Gardeur

Hadrien Gardeur: probably, a problem is that many properties are spine based while they would give better benefit in the manifest

HTML Survey data visualization

Susan Neuhaus: we are reaching the end of the survey. I started to play with collected data to see how we can visualise it. I wonder if a binary pro vs con numbers would be of use.

Gautier Chomel: There is a grey zone between pro and con, I am afraid giving those numbers gives a false feeling
… It is more graduated than the numbers might suggest

Susan Neuhaus: showing data visualization on my screen. I broke pro and con by role. I agree there is a lot of grey area. We could have multiple people scoring reactions. The pain will fall at different point depending on roles.

Susan Neuhaus: the survey closes in two weeks.

Ivan Herman: yes, a lot of grey area, but we have to do a binary choice. I think we should make a report to adress those grey areas regardless of the final decision.

Ivan Herman: another problem, is that representation is not sufficiently distributed. We miss more reading system responses. That may invalidate the whole exercise. I hope we get more answers from apple, google, kobo.

Ivan Herman: maybe we should extend the survey period to reach that.

Gautier Chomel: We might want to extend, we are also preparing a response and will have it soon
… back to binary choice, I would like to see if there are blockers
… are there people for whom html will totally break things
… even if 90% say yes, if 10% have big blockers then we should not say yes

Brady Duga: about getting RS onboard, I can send some messages. I also think we can reach those organizations ACs.

Susan Neuhaus: about if there are blockers, I wonder how we want to display those answers. What we want to share with the community.

Ivan Herman: workflow developers said they would have impossibility to accept HTML

Wendy Reid: we're out of time, let's think more about this for next week.

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).