13:03:06 <RRSAgent> RRSAgent has joined #pmwg
13:03:10 <RRSAgent> logging to https://www.w3.org/2026/01/22-pmwg-irc
13:03:10 <Zakim> RRSAgent, make logs Public
13:03:11 <Zakim> Meeting: Publishing Maintenance Working Group
13:03:33 <ivan> rrsagent, set log public
13:03:35 <ivan> ivan has changed the topic to: Meeting Details 2026-01-22: https://lists.w3.org/Archives/Public/public-pm-wg/2026Jan/0031.html
13:03:35 <ivan> Chair: wendy
13:03:35 <ivan> Meeting: Publishing Maintenance Working Group Telco
13:03:35 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-pm-wg/2026Jan/0031.html
13:56:31 <DaleRogers> DaleRogers has joined #pmwg
13:57:45 <wendyreid> wendyreid has joined #pmwg
13:57:51 <LaurentLM> LaurentLM has joined #pmwg
13:58:35 <ivan> present+
13:58:43 <ivan> present+ LaurentLM
13:58:46 <wendyreid> present+
13:58:55 <ivan> present+ brady
13:59:17 <toshiakikoike> toshiakikoike has joined #pmwg
13:59:25 <toshiakikoike> present+
13:59:26 <shiestyle> shiestyle has joined #pmwg
13:59:55 <ivan> present+ shiestyle
14:00:05 <ivan> present+ DaleRogers
14:00:14 <MasakazuKitahara> MasakazuKitahara has joined #pmwg
14:00:22 <MasakazuKitahara> present+
14:01:06 <ivan> present+ ajellinek
14:01:11 <duga> duga has joined #pmwg
14:01:15 <gman> gman has joined #pmwg
14:01:29 <mgarrish> mgarrish has joined #pmwg
14:02:03 <ivan> present+ sueneu
14:02:07 <duga> present+
14:02:14 <AvneeshSingh> AvneeshSingh has joined #pmwg
14:02:14 <ivan> present+ gman
14:02:21 <AvneeshSingh> present+
14:02:25 <gman> present+
14:02:30 <mgarrish> present+
14:03:00 <sueneu> sueneu has joined #pmwg
14:03:05 <sueneu> present+
14:03:17 <duga> scribe+
14:03:20 <ivan> present+ hadrien
14:03:20 <Hadrien> Hadrien has joined #pmwg
14:03:23 <Hadrien> present+
14:03:47 <sueneu> present+
14:03:48 <duga> wendyreid: Please associate github with w3c accounts
14:04:01 <ivan> present+ rdeltour
14:04:03 <duga> ... you can do it at github, so we can tag you
14:04:08 <rdeltour> rdeltour has joined #pmwg
14:04:16 <rdeltour> present+
14:04:49 <wendyreid> Topic: JXL in EPUB - https://github.com/w3c/epub-specs/issues/2896
14:04:53 <ivan> present+ gpellegrino
14:04:57 <gpellegrino> gpellegrino has joined #pmwg
14:05:05 <LaurentLM> present+
14:05:08 <gpellegrino> present+
14:05:12 <duga> wendyreid: JXL is a new JPEG thing
14:05:31 <duga> ivan: Yes, a new JPEG, it's more compact, etc. I am not an expert
14:05:55 <duga> ... It is an ISO standard, so we can refer to it
14:06:02 <CharlesL> CharlesL has joined #pmwg
14:06:02 <sueneu> q+
14:06:08 <CharlesL> present+
14:06:12 <duga> ... Chrome has it now behind a flag
14:06:19 <AvneeshSingh> q+
14:06:22 <sueneu> q-
14:06:27 <duga> ... firefox too. So it will be in major browsers soon
14:06:47 <duga> ... authoring tools should be able to support it within the year
14:07:13 <duga> ... so the question is, should we make it a core type?
14:07:40 <duga> ... this brings us to around 7 image formats
14:08:10 <duga> ... there was a long discussion around implementations
14:08:13 <duga> ... there are some
14:08:21 <wendyreid> q+
14:08:32 <duga> ... shiestyle brings up that reading systems must understand that media type
14:08:47 <duga> ... if true that may be a problem for some reading systems
14:09:08 <duga> ... but they also don't support webp which is also in the list
14:09:11 <Hadrien> q+
14:09:33 <wendyreid> ack AvneeshSingh
14:09:37 <mgarrish> q+
14:10:24 <duga> AvneeshSingh: Recalling opus, etc, the decision was to put it into the spec. If at the last minute we find there are no implementations we can pull it
14:10:49 <duga> ... this gives a warning that it is coming even if it isn't in the spec release
14:11:06 <duga> ivan: At this moment the tests pass at least 2 implementations
14:11:17 <duga> ... which is the required number
14:11:22 <wendyreid> ack wendyreid
14:11:27 <duga> AvneeshSingh: I was talking broader industry support
14:11:39 <duga> wendyreid: We haven't mentioned webkit/safari
14:11:51 <duga> ... Some ereaders user webkit
14:12:01 <duga> s/user/use/
14:12:10 <duga> ... we ran into this with webp
14:12:23 <duga> ... should we have the list of well supported media types
14:12:26 <sueneu> the can i use for fxl on the web https://caniuse.com/?search=jxl
14:12:51 <duga> ... should we have something like emerging media types? These would be flagged as not yet fully supported
14:13:04 <DaleRogers> q+
14:13:05 <LaurentLM> q+
14:13:10 <wendyreid> ack Hadrien
14:13:23 <duga> Hadrien: JXL has an interesting feature set for images
14:13:31 <duga> ... it makes sense to have it
14:14:03 <duga> ... there has been a battle over this, between avis (?) and jxl
14:14:29 <duga> ... we have core media for images, but not audio or video
14:14:30 <wendyreid> s/avis (?)/AVIF/
14:14:46 <duga> ... I am not really sure how whitelisting even helps
14:15:08 <wendyreid> ack mgarrish
14:15:16 <duga> ... the big question is should we keep track?
14:15:36 <duga> mgarrish: Core media type mainly means you don't need a fallback
14:15:48 <duga> ... so technically it is a new requirement to support it
14:16:06 <duga> ... to the other question, core media types made sense for 3.0
14:16:20 <duga> ... but once you start adding to it, it doesn't make sense
14:16:48 <duga> ... So you either have to pick between broad support and new features
14:17:35 <duga> ... so I think media types doesn't make a lot of sense for general resources, just for spine items
14:17:59 <wendyreid> ack DaleRogers
14:18:07 <duga> ... even if it is emerging, it will never be supported in old reading systems
14:18:35 <duga> DaleRogers: The issues seem to be around media types, core media types and support types
14:18:52 <duga> ... so if we are trying to align with the web it makes sense
14:19:02 <shiestyle> q+
14:19:12 <sueneu> q+
14:19:20 <wendyreid> ack LaurentLM
14:19:21 <duga> ... as an author if JXL has the features we want, shouldn't we just use it with a fallback?
14:19:23 <duga> q+
14:19:56 <duga> LaurentLM: we has this discussion with webp
14:20:26 <duga> ... people using webp and jxl don't want to add a fallback if they know it is supported
14:20:45 <ivan> q+
14:21:11 <duga> ... so we have core and extended core and it is a mess of our making
14:21:16 <ivan> q-
14:21:24 <Hadrien> q+ to discuss image fallbacks on the Web
14:21:37 <wendyreid> ack shiestyle
14:21:37 <ivan> +1 to LaurentLM
14:21:40 <duga> ... so maybe we have a note that these are added after 3.0, so if you are worried you should add  a fallback
14:21:55 <duga> shiestyle: if we can do a better solution, 2 lists
14:22:06 <duga> ... one is RS MUST support, no fallback needed
14:22:22 <duga> ... and one is RS SHOULD support and fallbacks SHOULD be used
14:22:42 <duga> ... webp is not broadly supported in Japan
14:23:04 <duga> ... jxl is still pretty new to add
14:23:09 <ivan> q+
14:23:13 <wendyreid> ack sueneu
14:23:22 <mgarrish> q+
14:23:28 <duga> sueneu: would we make jxl a foreign resource?
14:23:38 <duga> ... which requires a fallback
14:23:59 <wendyreid> ack duga
14:24:03 <wendyreid> scribe+
14:24:14 <wendyreid> duga: One point, the concept of core media types goes back to the start
14:24:39 <wendyreid> ... early days we had discussions on whether to use GIF or JPEG, even though browsers didn't support, but we got lucky and the world went that way
14:24:49 <wendyreid> ... it does feel a bit ridiculous to keep adding to this list
14:25:08 <sueneu> +1 duga
14:25:13 <wendyreid> ... this is guidance to authors, if we keep adding things that aren't fully supported, it's not helping authors
14:25:34 <wendyreid> ... webp was probably a mistake. We should be aiming for broad support
14:26:06 <wendyreid> ... the list of core media types was to give confidence, and if we want to allow people to use new media types without fallbacks, we could alternately just allow that
14:26:19 <wendyreid> ... people know they are using the wrong type of image, but they aren't forbidden
14:26:37 <wendyreid> ... putting a fallback in for webp or jxl is silly because the point is size
14:26:51 <wendyreid> ... we need a different solution that just adding to core media types
14:26:54 <wendyreid> +1 brady
14:26:58 <wendyreid> ack Hadrien
14:26:58 <Zakim> Hadrien, you wanted to discuss image fallbacks on the Web
14:27:09 <duga> Hadrien: I want to go back to how this works on the web
14:27:13 <ivan> q-
14:27:40 <duga> ... on the web you store the formats, and something else or generate it on the fly
14:27:47 <gman> q+
14:28:07 <duga> ... the tendency on the web is to go for the latest and greatest and provide the older format when needed
14:28:18 <duga> ... epub isn't like that, we can't generate it
14:28:38 <duga> ... but also we can't never advance because of old formats
14:28:59 <duga> ... I disagree with shiestyle - multiple reading systems support avif and webp
14:29:07 <wendyreid> q+
14:29:11 <duga> ... they just convert
14:29:52 <shiestyle> q+
14:30:04 <duga> ... manga with jpeg is much bigger than the newer formats
14:30:28 <wendyreid> ack mgarrish
14:31:15 <duga> mgarrish: in terms of authoring, a note makes more sense. Warnings are a problem for some authors and will require fallbacks anyway
14:31:28 <duga> ... how bad is it that old reading systems don't support this?
14:31:47 <ivan> +1 to mgarrish
14:31:49 <wendyreid> ack gman
14:32:43 <duga> gman: The usage is important. webp is good, but usage is only 12%
14:32:56 <duga> ... so despite this, people still prefer what they know
14:33:20 <Hadrien> +1 for having a note about support instead of core media + fallback
14:33:32 <DaleRogers> q+
14:33:32 <duga> ... we need to understand where this is used
14:33:45 <wendyreid> ack wendyreid
14:34:09 <duga> wendyreid: I agree that the current state is a problem
14:34:43 <duga> ... I understand the a reading systems can convert to another format, but that is more likely to work within an ecosystem
14:34:55 <duga> ... not when I just open a downloaded epub
14:35:12 <duga> ... And we still have to consider offline
14:35:46 <duga> ... we don't want to inundate people with warnings, but people look to us for a set of rules
14:36:10 <duga> ... so if we don't mention JXL people will assume you can't use it
14:36:21 <duga> ... I think we may have jumped the gun with webp
14:36:22 <ivan> q+
14:36:47 <duga> ... so we need to say there are other formats, but they might be under implemented
14:36:52 <mgarrish> q+
14:36:57 <wendyreid> ack shiestyle
14:37:07 <duga> ... so we need to say "here are the known to work" types, and here are some that might not be as well implemented
14:37:46 <duga> shiestyle: SOme stores in Japan use webp
14:38:05 <duga> ... it is very complicated in Japan
14:38:16 <wendyreid> ack DaleRogers
14:38:20 <ivan> present+ charles
14:38:24 <duga> ... having a format in core that publishers can't use isn't a good situation
14:38:56 <duga> DaleRogers: I am hearing some formats are more or less popular
14:39:03 <duga> ... as an author, I will use what works
14:39:12 <duga> ... but something has to move the spec forward
14:39:56 <duga> ... what eventually gets the publishers attention to support a particular format?
14:40:14 <duga> ... what gets the reading systems attention to decide to implement?
14:40:48 <wendyreid> ack ivan
14:41:03 <duga> wendyreid: We don't seem to be converging, so we need to move to the next one soon
14:41:31 <duga> ivan: if we do nothing, and they want the quality of JXL ,then they need fallbacks
14:41:42 <duga> ... if they use without fallbacks epubcheck complains
14:42:03 <duga> ... I would prefer to have it in the document
14:42:16 <duga> ... knowing that it may not work
14:42:47 <duga> ... my favorite option is to put in a note to say these formats are new and may not work everywhere
14:43:02 <duga> ... this is not a unique thing in the spec
14:43:21 <wendyreid> ack mgarrish
14:44:00 <duga> mgarrish: I agree, note is best. If we want to allow use without fallback we need to add to core
14:44:10 <duga> ... I don't want to confuse things by adding a new type
14:44:21 <duga> ... maybe also make foreign types not so scary
14:44:34 <sueneu> Topic: Selectors for Annotations - https://github.com/w3c/epub-specs/pull/2892
14:44:40 <ivan> chair+ sueneu
14:45:17 <duga> LaurentLM: [sharing screen]
14:45:32 <duga> ... in an annotation there is a target
14:45:46 <duga> ... the src references the epub
14:45:57 <duga> ... the file in the epub
14:46:20 <duga> ... the selector just deals with the exact points in the book that are part of the annotation
14:46:34 <duga> ... [walking through example]
14:47:47 <duga> ... in an annotation there can be multiple selectors, but they must point at the same place
14:48:16 <duga> ... our first selector is text fragment
14:48:22 <ivan> q+
14:48:32 <duga> ... this is from a community group, not a proper standard
14:49:17 <duga> ... we will need to make TextFragmentSelector, as it isn't in webannotations
14:49:19 <duga> q+
14:49:36 <duga> ... the format is easy for that selector, it can be made a little trickier
14:49:49 <Hadrien> q+ to talk about FragmentSelector
14:50:19 <duga> ... some notes in the annotation doc
14:50:42 <duga> ... 1. we don't need to percent encode since it isn't in a url
14:51:11 <duga> ... if there is a constrained on copied characters, you should use it with care
14:51:42 <duga> ... don't put too much text!
14:51:58 <duga> ... in the original model there was a text quote selector
14:52:20 <duga> ... we can consider this new one as a modernized version of that selector
14:52:56 <duga> ... one negative is there is no API currently in scripting, and no good polyfills
14:53:09 <duga> ... so you have to manually walk the DOM
14:54:31 <duga> ... also 1 question - should we add url fragment syntax? I didn't as I wanted to keep it short, and the static text doesn't seem necessary
14:54:40 <duga> ... so should we add the static text
14:55:05 <LaurentLM> q?
14:55:09 <sueneu> ack: ivan
14:55:19 <sueneu> q?
14:55:36 <duga> ivan: It is a CG document, but it is also the topic of active work in HTM:
14:55:44 <duga> s/HTM:/HTML/
14:56:04 <duga> ... I understand the argument with encoding
14:56:30 <duga> ... but isn't this hiding the underlying URL fragment?
14:56:46 <duga> ... since that is how it will be done in HTML
14:56:57 <duga> ... that avoids parallel specing
14:57:34 <Hadrien> +1 for what ivan just said, we should use FragmentSelector + conformsTo instead of creating TextFragmentSelector
14:57:42 <duga> ... and the last thing is, if I select a text, and some is in an html element, how is that handled
14:57:57 <duga> LaurentLM: You just keep the text and ignore the elemenrs
14:58:10 <sueneu> ack: duga
14:58:19 <shiestyle> q?
14:58:23 <shiestyle> ack ivan
14:58:25 <shiestyle> ack duga
14:58:34 <sueneu> duga: How well is the processing model for this group developed?
14:58:57 <sueneu> …is the detail about how to do this specified somewhere?
14:59:20 <sueneu> @ivan: it is being considered in the HTML group
14:59:52 <Hadrien> Old document about this: https://wicg.github.io/scroll-to-text-fragment/
15:00:22 <sueneu> duga: then it is scary to me to put this in our spec
15:00:57 <ivan> rrsagent, draft minutes