Meeting minutes
Wendy Reid: Please associate github with w3c accounts
… you can do it at github, so we can tag you
JXL in EPUB - w3c/epub-specs#2896
Wendy Reid: JXL is a new JPEG thing
Ivan Herman: Yes, a new JPEG, it's more compact, etc. I am not an expert
… It is an ISO standard, so we can refer to it
… Chrome has it now behind a flag
… firefox too. So it will be in major browsers soon
… authoring tools should be able to support it within the year
… so the question is, should we make it a core type?
… this brings us to around 7 image formats
… there was a long discussion around implementations
… there are some
… Shinya Takami brings up that reading systems must understand that media type
… if true that may be a problem for some reading systems
… but they also don't support webp which is also in the list
Avneesh Singh: 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
… this gives a warning that it is coming even if it isn't in the spec release
Ivan Herman: At this moment the tests pass at least 2 implementations
… which is the required number
Avneesh Singh: I was talking broader industry support
Wendy Reid: We haven't mentioned webkit/safari
… Some ereaders use webkit
… we ran into this with webp
… should we have the list of well supported media types
<Susan Neuhaus> the can i use for fxl on the web https://
Wendy Reid: should we have something like emerging media types? These would be flagged as not yet fully supported
Hadrien Gardeur: JXL has an interesting feature set for images
… it makes sense to have it
… there has been a battle over this, between AVIF and jxl
… we have core media for images, but not audio or video
… I am not really sure how whitelisting even helps
… the big question is should we keep track?
Matt Garrish: Core media type mainly means you don't need a fallback
… so technically it is a new requirement to support it
… to the other question, core media types made sense for 3.0
… but once you start adding to it, it doesn't make sense
… So you either have to pick between broad support and new features
… so I think media types doesn't make a lot of sense for general resources, just for spine items
… even if it is emerging, it will never be supported in old reading systems
Dale Rogers: The issues seem to be around media types, core media types and support types
… so if we are trying to align with the web it makes sense
… as an author if JXL has the features we want, shouldn't we just use it with a fallback?
Laurent Le Meur: we has this discussion with webp
… people using webp and jxl don't want to add a fallback if they know it is supported
… so we have core and extended core and it is a mess of our making
<Ivan Herman> +1 to Laurent Le Meur
Laurent Le Meur: so maybe we have a note that these are added after 3.0, so if you are worried you should add a fallback
Shinya Takami: if we can do a better solution, 2 lists
… one is RS MUST support, no fallback needed
… and one is RS SHOULD support and fallbacks SHOULD be used
… webp is not broadly supported in Japan
… jxl is still pretty new to add
Susan Neuhaus: would we make jxl a foreign resource?
… which requires a fallback
Brady Duga: One point, the concept of core media types goes back to the start
… 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
… it does feel a bit ridiculous to keep adding to this list
<Susan Neuhaus> +1 Brady Duga
Brady Duga: this is guidance to authors, if we keep adding things that aren't fully supported, it's not helping authors
… webp was probably a mistake. We should be aiming for broad support
… 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
… people know they are using the wrong type of image, but they aren't forbidden
… putting a fallback in for webp or jxl is silly because the point is size
… we need a different solution that just adding to core media types
<Wendy Reid> +1 brady
Hadrien Gardeur: I want to go back to how this works on the web
… on the web you store the formats, and something else or generate it on the fly
… the tendency on the web is to go for the latest and greatest and provide the older format when needed
… epub isn't like that, we can't generate it
… but also we can't never advance because of old formats
… I disagree with Shinya Takami - multiple reading systems support avif and webp
… they just convert
… manga with jpeg is much bigger than the newer formats
Matt Garrish: in terms of authoring, a note makes more sense. Warnings are a problem for some authors and will require fallbacks anyway
… how bad is it that old reading systems don't support this?
<Ivan Herman> +1 to Matt Garrish
Grigorily Manucharian: The usage is important. webp is good, but usage is only 12%
… so despite this, people still prefer what they know
<Hadrien Gardeur> +1 for having a note about support instead of core media + fallback
Grigorily Manucharian: we need to understand where this is used
Wendy Reid: I agree that the current state is a problem
… I understand the a reading systems can convert to another format, but that is more likely to work within an ecosystem
… not when I just open a downloaded epub
… And we still have to consider offline
… we don't want to inundate people with warnings, but people look to us for a set of rules
… so if we don't mention JXL people will assume you can't use it
… I think we may have jumped the gun with webp
… so we need to say there are other formats, but they might be under implemented
… so we need to say "here are the known to work" types, and here are some that might not be as well implemented
Shinya Takami: SOme stores in Japan use webp
… it is very complicated in Japan
… having a format in core that publishers can't use isn't a good situation
Dale Rogers: I am hearing some formats are more or less popular
… as an author, I will use what works
… but something has to move the spec forward
… what eventually gets the publishers attention to support a particular format?
… what gets the reading systems attention to decide to implement?
Wendy Reid: We don't seem to be converging, so we need to move to the next one soon
Ivan Herman: if we do nothing, and they want the quality of JXL ,then they need fallbacks
… if they use without fallbacks epubcheck complains
… I would prefer to have it in the document
… knowing that it may not work
… my favorite option is to put in a note to say these formats are new and may not work everywhere
… this is not a unique thing in the spec
Matt Garrish: I agree, note is best. If we want to allow use without fallback we need to add to core
… I don't want to confuse things by adding a new type
… maybe also make foreign types not so scary
Selectors for Annotations - w3c/epub-specs#2892
Laurent Le Meur: [sharing screen]
… in an annotation there is a target
… the src references the epub
… the file in the epub
… the selector just deals with the exact points in the book that are part of the annotation
… [walking through example]
… in an annotation there can be multiple selectors, but they must point at the same place
… our first selector is text fragment
… this is from a community group, not a proper standard
… we will need to make TextFragmentSelector, as it isn't in webannotations
… the format is easy for that selector, it can be made a little trickier
… some notes in the annotation doc
… 1. we don't need to percent encode since it isn't in a url
… if there is a constrained on copied characters, you should use it with care
… don't put too much text!
… in the original model there was a text quote selector
… we can consider this new one as a modernized version of that selector
… one negative is there is no API currently in scripting, and no good polyfills
… so you have to manually walk the DOM
… 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
… so should we add the static text
<Susan Neuhaus> ack: Ivan Herman
Ivan Herman: It is a CG document, but it is also the topic of active work in HTML
… I understand the argument with encoding
… but isn't this hiding the underlying URL fragment?
… since that is how it will be done in HTML
… that avoids parallel specing
<Hadrien Gardeur> +1 for what Ivan Herman just said, we should use FragmentSelector + conformsTo instead of creating TextFragmentSelector
Ivan Herman: and the last thing is, if I select a text, and some is in an html element, how is that handled
Laurent Le Meur: You just keep the text and ignore the elemenrs
<Susan Neuhaus> ack: Brady Duga
<Susan Neuhaus> Brady Duga: How well is the processing model for this group developed?
<Susan Neuhaus> …is the detail about how to do this specified somewhere?
<Susan Neuhaus> @Ivan Herman: it is being considered in the HTML group
<Hadrien Gardeur> Old document about this: https://
<Susan Neuhaus> Brady Duga: then it is scary to me to put this in our spec