Re: [Minutes] PMWG 2025-05-08

I see my role here to advocate for content creators; especially the next generation. As a web designer, i went to the W3C to understand how to prepare my documents.

No one is learning XHTML. It is a discontinued language. HTML is living and being expanded. It is becoming more accessible over time. EPUB should reflect that change. I know that browsers can handle both versions of markup. I’m hoping that EPUB reading systems will be able to stay current, and future proof, as well.


Warm Regards,

Dale Rogers, M.Ed., CIW, RScP
Author | Designer | Educator | Licensed Spiritual Coach

dale@dalerogers.me
http://dalerogers.me/
https://www.linkedin.com/in/dalerrogers/

From my iPhone. Pardon my thumbs.

________________________________
From: Ivan Herman <ivan@w3.org>
Sent: Sunday, May 11, 2025 2:34 AM
To: Matt Garrish <matt.garrish@gmail.com>
Cc: Laurent Le Meur <laurent.lemeur@edrlab.org>; W3C PM Working Group <public-pm-wg@w3.org>; Eric Hellman <eric@hellman.net>
Subject: Re: [Minutes] PMWG 2025-05-08



On 10 May 2025, at 13:23, matt.garrish@gmail.com wrote:

I’d argue that adding html is much more fundamental than the changes you’ve cited, which is why it may need special attention. There’s no graceful degradation for an html epub except to reproduce everything in html in xhtml, which defeats the purpose of using the other syntax. We don’t want epub to become the carnival show of content where you get to step right up and see if anything displays at all after giving away your money.

I would still argue that, to take one example, using heic as an image format is very close. There is no graceful degradation for that either, unless the author provides several image formats for the same image, which defeats the purpose, as you say. Yes, HTML is more "dramatic" as a change, but with the same set of arguments, we shouldn't have had accepted WebP format in EPUB 3.3… (I am not arguing for HEIC, just use it as an example).


It strikes me as a kind of reversal of previous discussions we’ve had about profiling reading systems so that users can figure out the capabilities. But that’s shifting a technical burden onto users that they don’t want to know or care about. The vast majority of users have no idea what an epub is under the hood and probably little more knowledge of what their reading system supports. Telling them they’re about to download an “EPUB 3+” will probably grab more attention, as Eric says, than listing what the publication needs for support when you go to purchase, or having to warn about all the features that probably won’t work before they can fully experience the book.

But I promised not to argue, and this is an issue we probably shouldn’t try to solve at this stage, and not by email. It would be good if we can get this logged in the issue tracker so it stays on the radar.

Yes. I will put a pointer to this thread to the issue on Github. Indeed, it would be better to continue the discussion there…

Ivan



Matt

From: Ivan Herman <ivan@w3.org>
Sent: May 10, 2025 2:49 AM
To: Matt Garrish <matt.garrish@gmail.com>
Cc: Laurent Le Meur <laurent.lemeur@edrlab.org>; W3C PM Working Group <public-pm-wg@w3.org>; Eric Hellman <eric@hellman.net>
Subject: Re: [Minutes] PMWG 2025-05-08

Looking at the thread, isn't it correct that the same set of arguments may be valid for any technical additions to EPUB 3.3? Say, if we reinforce the usage of WebVTT, add new features for Webtoons, or add heic as a valid image format? We are concentrating on HTML here, but it is not in a unique situation (though probably the most prominent). In other words, any technical addition to EPUB 3.3 might end up at the same place.

Ideally, we would communicate the changes with the official version number, but that we cannot. Calling this EPUB 4 might be disastrous as well, insofar as no publishers would even look at it (that was the discussion we had on the version numbering which led to the restriction in the charter). That is a dead end.

I jump on the idea of Matt about the usage of dc:format (or equivalent) in the package document, which I like. dc:format[1] is fairly open, in the sense that it can also be string. What if we define some sort of mini-syntax for that value, which lists some "features" with pre-defined names? Authors MAY list the extra features they use in a publication; reading systems may look at this, and they may warn the reader if the publication relies on a feature they do not implement. Such a property may also be useful for older, but less implemented features of EPUB 3.3 (e.g., whether javascript may be used in a publication or not).

Ivan


[1] https://www.dublincore.org/resources/userguide/publishing_metadata/#dc:format



On 10 May 2025, at 01:13, matt.garrish@gmail.com<mailto:matt.garrish@gmail.com> wrote:

> If not, I see no possible warning as long as we keep package/@version = a static "3.0".

For reading systems with no awareness of the changes and for users that have obtained the publication without it being identified as not your regular EPUB 3, sure. A new version is the only universal way that a reading system will know it can’t handle what it’s getting.

But we’re not necessarily out of options for flagging the content for distributors or reading systems simply because the version has to stay the same. Like I mentioned earlier, we could require dc:format with a designator for html-containing publications. Epubcheck would easily be able to check the media types and ensure the flag is set, for example.

We could also add a new attribute to the package element to flag these publications. That might be a bit more controversial approach, but it seems unlikely that a new attribute will cause any issue processing package documents (we had similar worries about adding the collection element and it went ignored by everyone with no use for it, which was kind of everyone in the end sadly).

Anyway, that’s just a couple of quick ideas that came to mind. There may be other ways of handling it, too, like in the container.xml file. But this is useful to consider more if we go ahead with the change.

Matt

From: Laurent Le Meur <laurent.lemeur@edrlab.org<mailto:laurent.lemeur@edrlab.org>>
Sent: May 9, 2025 1:44 PM
To: W3C PM Working Group <public-pm-wg@w3.org<mailto:public-pm-wg@w3.org>>
Cc: matt.garrish@gmail.com<mailto:matt.garrish@gmail.com>; Eric Hellman <eric@hellman.net<mailto:eric@hellman.net>>
Subject: Re: [Minutes] PMWG 2025-05-08

HI,

I understand what Eric means. Without a strong flag in the "pure HTML" EPUBs (especially if not well-formed), some (many?) reading systems will open such a publication but will display it badly.

A good question is: Do EPUB reading systems in the wild test the OPF package/manifest/item/@media-type before accepting a publication? If yes, the presence of "application/html" will be a strong warning that there is something special here. If not, I see no possible warning as long as we keep package/@version = a static "3.0".

Laurent




Le 9 mai 2025 à 19:28, Eric Hellman <eric@hellman.net<mailto:eric@hellman.net>> a écrit :

More the former rather than the latter, but mostly I'm arguing for a new label. Sometimes an author comes up with a great title first, and the story then just writes itself.




On May 9, 2025, at 1:16 PM, <matt.garrish@gmail.com<mailto:matt.garrish@gmail.com>> <matt.garrish@gmail.com<mailto:matt.garrish@gmail.com>> wrote:

Sure, that’s a fair point. I’d prefer to hear everyone’s opinions on this so I don’t think it’s productive to argue for or against any of the feedback we get. I was just curious from that comment if there was a technical solution within EPUB 3 that you envisaged so that users could be alerted to the type of EPUB 3 publication that they were getting or if you are arguing for a brand new format of EPUB.

Matt

From: Eric Hellman <eric@hellman.net<mailto:eric@hellman.net>>
Sent: May 9, 2025 11:58 AM
To: matt.garrish@gmail.com<mailto:matt.garrish@gmail.com>
Cc: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>; W3C PM Working Group <public-pm-wg@w3.org<mailto:public-pm-wg@w3.org>>
Subject: Re: [Minutes] PMWG 2025-05-08

I'm asking for more consideration of end users who would have no way of knowing whether EPUB3 files will work on the reading systems they use. These are not people who do not know what XML syntax is!

I would love that have an EPUBish format that packaged HTML files. but dont give it a label that creates angry end users!


On May 9, 2025, at 10:35 AM, <matt.garrish@gmail.com<mailto:matt.garrish@gmail.com>> <matt.garrish@gmail.com<mailto:matt.garrish@gmail.com>> wrote:

Hi Eric,

> By contrast, a distinguishing label like  "EPUB+" for even this technically modest change would encourage adoption by reading systems developers, and by their customers.

Could you clarify what you mean by this? EPUB 3 is a continuous line with all files being identified by version=”3.0” in the package document. There would be no reliable way to differentiate an “EPUB 3.3” file from an “EPUB 3.4” if they both use the XML syntax.

Are you asking for a version number change to make an “EPUB+”, which would put this out of scope for this revision, or are you just wanting us to find a way to differentiate EPUB 3 files with the HTML syntax from EPUB 3 files with the XML syntax without changing the version? (I think the latter could be done, for example, using a dc:format tag with a required identifier.)

Matt

From: Eric Hellman <eric@hellman.net<mailto:eric@hellman.net>>
Sent: May 9, 2025 10:08 AM
To: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Cc: W3C PM Working Group <public-pm-wg@w3.org<mailto:public-pm-wg@w3.org>>
Subject: Re: [Minutes] PMWG 2025-05-08

I'd like to comment on allowing html syntax in EPUB 3.4.

While I understand the technical reasons behind the change, and agree with them for the most part, allowing html syntax in EPUB 3.* would be a terrible marketing decision. Because of this, Project Gutenberg would not implement 3.4 and I would counsel other organizations I advise not to implement any support for it. We have touted our implementation of EPUB3 for over 75,000 titles despite its inconsitent implementation in reading systems. When something doesn't work it causes support issues for us. We continue to produce EPUB2 files because certain strongly desired functionalities don't work in systems that claim to support EPUB3. (I'm looking at you, ADE.) It's clear that there will be reading systems that just won't work with HTML syntax, and users of those systems will have no way to know if the files they acquire will work with the systems they use. Even if we were to produce EPUB 3.4 files with XML syntax, we would struggle to communicate that to a user who has experienced failures with other EPUB3 files. Those failures would be black marks against the EPUB label or "brand".

Has anyone articulated a benefit to end users for this change?

By contrast, a distinguishing label like  "EPUB+" for even this technically modest change would encourage adoption by reading systems developers, and by their customers. For distributors like us, it would allow us to easily communicate a modernization step without a lot of work on the backend.


Eric Hellman
President, Free Ebook Foundation
http://ebookfoundation.org<http://ebookfoundation.org/>
https://bsky.app/profile/gluejar.com







On May 8, 2025, at 10:20 AM, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>> wrote:

Minutes are here:

  https://w3c.github.io/pm-wg/minutes/2025-05-08.html

Ivan

----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43


----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43


----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43