W3C

Publishing Maintenance Working Group Telco

08 January 2026

Attendees

Present
Abe Jellinek, charles, Charles LaPierre, Dale Rogers, Brady Duga, Gautier Chomel, GeorgeK, Grigorily Manucharian, Gregorio Pellegrino, Hadrien Gardeur, Ivan Herman, Daniel Kimberg, Laurent Le Meur, Matt Garrish, Romain Deltour, Shinya Takami, Susan Neuhaus, Toshiaki Koike, Wendy Reid
Regrets
Avneesh Singh
Chair
Wendy Reid
Scribe
Brady Duga

Meeting minutes

Republishing EPUB 3.3

Wendy Reid: First topic is republishing 3.3
… some of the examples for fixed layout were wrong, so those have been updated
… this is just in Core

Ivan Herman: And it is just a diagram, nothing on the text
… not even the a11y text, just the image

<Wendy Reid> PROPOSED: Republish EPUB 3.3 Core for an update to the fixed layout examples.

<Brady Duga> +1

<Ivan Herman> +1

<Hadrien Gardeur> +1

<Matt Garrish> +1

<Wendy Reid> +1

<Charles LaPierre> +1

<Shinya Takami> +1

<Susan Neuhaus> +1

<Gautier Chomel> +1

<Dale Rogers> +1

<Romain Deltour> +1

<Daniel Kimberg> +1

<Gregorio Pellegrino> +1

RESOLUTION: Republish EPUB 3.3 Core for an update to the fixed layout examples.

<GeorgeK> +1

Matt Garrish: When I went to prepare that, I got an error about Dave not being a member so he can't be listed as editor
… so I moved him to previous authors, is that ok with everyone?

Wendy Reid: But he was the editor, do we need to change it?

Ivan Herman: There is a very strict rule that when you publish the editor must be a member
… we would have to request an exception

Wendy Reid: This must have come up before, people have edited old docs before

Matt Garrish: Yeah, but was the editor still in the group in those cases? That is what I have seen

Ivan Herman: Let's be fair to the system, we are publishing a new version with new dates
… so Dave isn't the editor of the 2026 version

Susan Neuhaus: Will Dave care? We don't want to be dismissive of his work

Wendy Reid: I would prefer to ask first

Dale Rogers: Is there a former editor field?

Wendy Reid: yes, that is where he will go

Matt Garrish: So his name will still be at the top, but under former editor

Wendy Reid: We should just go ahead

Charles LaPierre: But we should reach out to Dave and let him know

Wendy Reid: Yeah, I will do that

Horizontal Reviews

Wendy Reid: These are on the horizon
… we need these so these can go to CR
… i18n, security, privacy, a11y, and architecture (TAG)
… Avneesh has offered the a11y TF for a11y, but we still need the others
… we need this for core, rs, a11y, and annotations
… chairs will reach out the horizontal review groups on how they want us to proceed with the reviews
… as some of those specs have very little change
… annotations will need review, even though it is based on an existing rec

Ivan Herman: All the normative changes are documented in the changes section, correct?

Matt Garrish: yes

Ivan Herman: So when we reach out, we can pull the interesting entries from the changes,
… maybe just a 3 or 4 item list

Matt Garrish: Yeah, not every change log needs review
… I just did something similar for epubcheck

Annotations

Wendy Reid: LaurentLM do you want to start with an overview?

<Gautier Chomel> https://w3c.github.io/epub-specs/epub34/annotations/

<Gautier Chomel> https://w3c.github.io/epub-specs/wg-notes/annotations-ucr/index.html

Laurent Le Meur: Currently stable are use cases, requirements
… body and target are final
… and everything you need for ??? are stabilized
… ivan has a paper we need to review
… and we have buy in from several reading systems on what we have done so far
… ivan suggests we merge annotations into this group, and to publish soon as WD

Ivan Herman: If we publish FPWD, it puts a stake in the ground to get early comments
… and horizontal review can start
… to get them earlier rather than later
… So I think it is a good thing, and having seen FPWD before, this one is very mature
… so when we get to a good point we should publish. As a draft we can update it whenever

Wendy Reid: the benefit to FPWD is nothing has to really be decided

Laurent Le Meur: I would like to have at least one selector before FPWD

Wendy Reid: I wonder if we should start with CFI since people know it

Laurent Le Meur: I will go back to implementors and see what they would like as first and best

Ivan Herman: One difference between when we made open annotations and now is new selector to specify ranges in text
… It is now on the way to being part of the HTML standard, and is broadly implemented

<Wendy Reid> https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment/Text_fragments

Laurent Le Meur: With some caveats

Laurent Le Meur: But that would be good as first selector

Hadrien Gardeur: I am in favor text fragments, but browser just scrolls to the text and selects it
… but we need an API which doesn't exist
… so we don't have JS APIs to get a reference to that place in the document
… so it has to be completely implemented by the RS, so if there is no library for it

Laurent Le Meur: There is an old buggy JS library from Google, the browsers don't have an API, it is a mess

Ivan Herman: Is what we define in the spec a format to exchange annotations? So we don't define the implementation

Laurent Le Meur: Well, we need to define an interchangeable selector

Ivan Herman: But the selector is clearly define in htm
… l

Laurent Le Meur: Yes, but if devs don't have interoperable tools ...

Ivan Herman: What do you mean by interoperable?

Laurent Le Meur: So if I have some text we need to be able to find it
… so if there is no JS library for this or API, then we can't do anything with that selector

Ivan Herman: Ah, I see. Then we do have a problem

Susan Neuhaus: LLM search does a good job of extracting and linking to text
… maybe there is something the LLMs are using

Laurent Le Meur: Those let the browser do the work

Ivan Herman: I am worried that we would define such an API

Hadrien Gardeur: I mentioned webview, but it is also true of a web app in a browser
… sometimes the API is browser only, but in this case, it is in neither
… I agree we shouldn't define an API, but we should figure out where this would be done
… as an API will have a huge impact on our work

Wendy Reid: I am concerned that we can't define the API for this
… and there is no guarantee it would be implemented
… we can go to the various groups and see if we can get support for it
… so we can at least get a yes or no on it
… Maybe we can get a shell of an API, and we can provide that to all implementors
… we really want to avoid different syntaxes

Laurent Le Meur: We can take the w3c syntax
… so the primary selector should be one we know everyone can implement

Ivan Herman: we have to reach out to the TAG for review
… then we can get the TAG on our side

Laurent Le Meur: We can say we only keep this if browsers provide an API as leverage

Hadrien Gardeur: reading progress is the "easy" part of the discussion, and it isn't that easy

<Grigorily Manucharian> google search has the capacity to highlight and lead to a given website's segment in the search results; the code is #:~:text=start_text,end_text from what i remember

Charles LaPierre: this needs to work on the web

Hadrien Gardeur: text fragment can work on the web, but we need to know the URL on the web
… in epub we have a path
… so the issue between the web and epub is more the path, not the fragment

Ivan Herman: I think in epub3.3 we discussed how URLs worked in EPUB
… and we got to reasonable clarity
… so we clearly defined the root, etc

Hadrien Gardeur: many people have had this discussion, and it depends if the root is OPF or top level

Ivan Herman: in 3.3 we discussed this

Charles LaPierre: I thought we had brought in the TAG to this discussion, maybe we should revisit those minutes?

Wendy Reid: When it comes to the URL with the selector for the annotation - does it really matter?
… there are basically two parts, the bit before the fragment, then the fragment
… if the fragment tells us the chapter, then does it matter what comes before?
… if we say everything after some point must be the same, and everything before can be whatever, then does it matter what comes first?

Romain Deltour: I just want to clarify what we did in 3.3, which was how to resolve relative URLs
… for this discussion, the container root is implementation dependent
… so we know how to process relative URLs against the root URL, but what that URL is depends on the implementation

Laurent Le Meur: Inside epub it isn't really a problem
… which can be relative
… the only issue is translating to the web
… this is not epub dependent, it is just how do we move an epub annotation to a web publish, which isn't an epub problem

Hadrien Gardeur: I disagree. We need to know what the root is, we have seen disagreement on this
… say we have a web reader (not publication) and the server has access to the ZIP
… this is also a problem for epub, not just web pubs

Charles LaPierre: When you create the application you have all the info (current chapter, opf, etc)

<Laurent Le Meur> THe spec relative to the annotation Target element is https://w3c.github.io/epub-specs/epub34/annotations/#1-3-1-source

Charles LaPierre: so it is up to the reading system to figure out how to find the annotation
… is that what we are trying to define here?

Hadrien Gardeur: We have a path, but we don't know how to calculate it

Laurent Le Meur: can we extract from 3.3 or 3.4 how the src is to be defined? I will check

Romain Deltour: Could Hadrien clarify what he meant by what is not currently clear? From my understanding the spec is very clear
… we clarified this in 3.3
… whether it is the root or the opf is speciffied
… what we don't have is how to expand a URL into an epub
… but that isn't needed as part of epub. Is that what you meant?

Hadrien Gardeur: I was talking about annotation, we need to know how to build a URL?
… how do we calculate that, are we at the top of the container? Or somewhere else?

<Romain Deltour> then my suggestion is to refer to "URLs in the OCF abstract container" https://www.w3.org/TR/epub-34/#sec-container-iri

Hadrien Gardeur: I am not talking about using a URL to point at an epub
… we tried that before and it didn't go well
… and we don't need to be able reference everything as a URL

Grigorily Manucharian: Hadrien you mentioned different roots, can you give pros and cons for those?

Hadrien Gardeur: not today, but maybe I can write something up

Ivan Herman: This is an epub annotation spec, so we should use the epub way

Hadrien Gardeur: In the spec we have files. If we assume the annotation has a well known location we are fine, but if we don't then the path has to be constructed
… so we can't just point at the epub spec

Wendy Reid: We should probably have an idea of what selectors will look like for FPWD

Ivan Herman: Are we moving annotation meetings here?

Wendy Reid: Seems like we should

<Charles LaPierre> +1 to move into this call :)

<Grigorily Manucharian> +1 too

<Hadrien Gardeur> +1

<Ivan Herman> +1

<Romain Deltour> +1

<Susan Neuhaus> +1

<Shinya Takami> +1

<Dale Rogers> +1

Summary of resolutions

  1. Republish EPUB 3.3 Core for an update to the fixed layout examples.
Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).