Epub-specs: Should epub:switch be restored to EPUB?

[RachelComerford]

@dauwhe HTML and CSS are clear about how unknown elements should be handled. If a browser sees epub:switch, it doesn't crash, it just follows the rules.
I like the idea of an appendix (graveyard?) of features that should not be used anymore. I don't think a new spec should define epub:switch, but epubcheck should not generate an error for some things.

For this entire exercise, we must be very clear on how authors, reading systems, and validation tools should handle each feature. We might need to be more granular than the rather confusing current system of deprecation, superseding, and superseding and marked for removal.

[murata2makoto]

We should also consider whether trigger should be restored. iOS iBooks and Microsoft Edge support it.

[GarthConboy]

Note language from original proposal on this topic:

"• Reintroduce but strongly discourage the <switch> element. Allow EPUB 3.0.2 Reading Systems to not support it.
• Reintroduce but strongly discourage the <trigger> element. Allow EPUB 3.0.2 Reading Systems to not support it."

It seems that approach is desired to maintain the goal of refactoring 3.1 into a 3.0.2 that is backward compatible with 3.0.1 – the proposed handling threads that needle.

[TzviyaSiegman]

I would hesitate to reintroduce any of the removed (or deprecated or superseded) elements in 3.1. The EPUB WG did not make decisions on a whim. Please refer to documents such as the survey about package metadata.
EPUB 3.1 released a full year ago. We cannot assume that no one has starting tooling up for it. I have begun using it internally, and I have heard of others that have begun to shift as well. We cannot just throw away the work that was done with the full support of the Working Group. I understand the impact on ISO standardization, and we must find a way to work with that, but we also should not throw away the valuable contributions made by 3.1.

[GarthConboy]

I disagree here. In order to keep the version at "3.0" -- we're gonna need to allow (but discourage) those elements. But, I'd see no issue in epubcheck starting to complain more vociferously about them.

I don't really see these cases as that important (either way) as usage of both is near-zero. If we were to leave 'em removed, we'd be retroactively removing them from 3.0.1 too, but perhaps that's okay. Though, deprecate is likely the correct path.

[TzviyaSiegman]

@GarthConboy I think what you're saying is that, definitionally, anything with a "3.0" value in the version attribute has certain properties. If that's the case, then what is the point of this exercise?

[GarthConboy]

Well, we need to remove with care... add being a different story. The rationale and proposed changes for "3 .0 .2" pretty well laid out in the original proposal and Dave's initial PR.

I believe we can deprecate these two elements in "3 .0 .2" which would be substantial progress and still retain requisite compatibility.

[laudrain]

Almost sure there are no EPUB 3.1 in any "external" supply chain : first clue is the lack of support in epubcheck.
How much internal use?

[BillKasdorf]

I should point out that my +1 to Tzviya and the comment that 3.1 may be used in places we’re not aware of (like hers) is based on features that _are_ used. So I am currently agnostic as to whether it would be prudent to retain things like epub:switch and deprecate them, just so we can call the spec 3.0.x (if indeed that’s what we decide to do), which wouldn’t be a problem for anybody who has implemented 3.1—they just wouldn’t have used those deprecated features. (Though I have a distaste for a murky spec with things in it that we really don’t want anybody to be using and for which we have no evidence that anybody is using them.)

In principle, my main concern is that whatever we do we should be careful not to throw out good things that were done in the 3.1 work.

--Bill K

From: GarthConboy [mailto:[email protected]]
Sent: Tuesday, January 02, 2018 12:34 PM
To: w3c/publ-epub-revision
Cc: Subscribed
Subject: Re: [w3c/publ-epub-revision] Should epub:switch be restored to EPUB? (#988)

I disagree here. In order to keep the version at "3.0" -- we're gonna need to allow (but discourage) those elements. But, I'd see no issue in epubcheck starting to complain more vociferously about them.

I don't really see these cases as that important (either way) as usage of both is near-zero. If we were to leave 'em removed, we'd be retroactively removing them from 3.0.1 too, but perhaps that's okay. Though, deprecate is likely the correct path.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/w3c/publ-epub-revision/issues/988#issuecomment-354824183, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIYxNecloNn0L1PNzb2y7B2lXpwFVUqeks5tGmiDgaJpZM4RNvG6.

[GarthConboy]

Indeed "we should be careful not to throw out good things that were done in the 3.1" -- that's what the proposal is striving toward.

[BillKasdorf]

[Replacing a comment I mistakenly made via email, which I have deleted. This was sent before my comment above, and in response to Tzviya]
+1, including the fact that there are likely more implementations of 3.1, or aspects of 3.1, than we are aware of. Tzviya’s example—her use of it internally at Wiley—is an example of an implementation that uses the latest and best spec but is not “visible” to the outside world in the way a major RS is. I think if we could look under the hood in contexts like publishers’ infrastructures, platforms, service providers, etc., we’d find more use of it. It’s really not correct to say “nobody’s using 3.1.” We may not be seeing ebooks delivered as EPUB 3.1 but that doesn’t mean the spec isn’t used.

[murata2makoto]

The survey @TzviyaSiegman mentioned does not cover trigger or switch.

Microsoft shipped the support of EPUB in Edge. They implemented trigger. I heard that iBooks on iOs supports trigger also.

Although I would like to reintroduce (and deprecate) trigger and switch to EPUB 3.0.2, I can probably be persuaded if some survey shows that they are not used in EPUB 3.(0.1).

[mattgarrish]

Should we perhaps start by asking the question again whether it matters if these features cause validation warnings/errors?

What we do with them would seem to flow from that:

• if we're okay with existing content that uses them having to lose the features to be re-released, then let's return and deprecate them.
• if existing content should always be valid no matter how epub changes, then the features have to come back and cannot be formally deprecated. This is where a strict profile would be a useful counter-balance, as discouraging content is ineffective and shifts the problems we're creating onto the validator to work around (i.e., come up with something like strict validation but without spec blessing).

I'm not comfortable with dropping features entirely without a package version number change, as at the very least any 3.0-compatible reading system has to be aware that content was once developed using the features. You shouldn't have to comb through old specifications to find this information.

[GarthConboy]

In these cases I'm comfortable with the first bullet above.

[mattgarrish]

The survey @TzviyaSiegman mentioned does not cover trigger or switch.

Yes, that was the summary of the metadata survey.

The summary of the "deprecatables" survey is here: https://docs.google.com/document/d/1jMyGnuSS1iZBCfVFQc0b0IR0hvNMq_VQLXZcPSEaemA/edit#heading=h.41oa0jp9hbwi

[laudrain]

Should we perhaps start by asking the question again whether it matters if these features cause validation warnings/errors?

IMO, we should be careful not to add too much dev on epubcheck (non-existing) team...

"3.0.1 full compatibility" being our motto here, I agree with Matt in:

I'm not comfortable with dropping features entirely without a package version number change, as at the very least any 3.0-compatible reading system has to be aware that content was once developed using the features.

[llemeurfr]

Some thoughts:

• backward compatibility (#984) requires that switch is defined in the spec. A deprecation / strong warning against using it is the only way to signal that it's virtually not implemented.
• if a switch is present in a publication, epubcheck must check it (for testing 3.0.1 epubs at least).
• a reading system implements, or does not implement, a given feature (switch, trigger ...). Readium does not implement switch (*), period; for a RS, having switch defined in the next spec or not doesn't change much.

(*) Daniel told me it used to be supported in the original Chrome extension, but some of this code was dropped in what became ReadiumJS (particularly: shared-js)

[llemeurfr]

And I didn't understand @mattgarrish 's statement about deprecation -> "[bullet 1] existing content that uses them having to lose the features to be re-released, then let's return and deprecate them."
because, as per http://www.idpf.org/epub/31/spec/epub-spec.html#deprecated => a re-release may retain the feature.

[mattgarrish]

And I didn't understand @mattgarrish 's statement about deprecation

The point made during 3.1 is that vendors don't accept content with errors or warning, so if we put the features back as deprecated then publishers are forced to change the content in order for it to be re-ingested. That's part of why we changed the version number - so existing content wouldn't fall into this trap.

You can, of course, continue to use the features if you're not going through a supply chain, or one that isn't strict about valid content, but my question of whether errors/warning matter was aimed at this problem of ingestion.

Hope that helps clarify.

[llemeurfr]

@mattgarrish " if we put the features back as deprecated then publishers are forced to change the content in order for it to be re-ingested": this is where I don't follow you. Deprecated does not mean that epubcheck should raise an error if the feature is present in an ebook. The EPUB 3.1 definition of deprecated contains "Validation tools must alert Authors that inclusion of the feature is deprecated when encountered in an EPUB Publication. It is recommended that the alert be lower in severity than an error or warning."

Therefore an information message would be ok, wouldn't it? A matter of good communication in epubcheck.

[mattgarrish]

And that was a hope that epubcheck might come up with some kind of a message that would somehow be visible to publishers but that would slip past vendors (an "alert"). It's a nice idea, but it was also noted that this new level of message is just as likely to be put on the banned list as vendors want clean reports.

Epubcheck doesn't emit info messages by default, so dropping them in there is about as useful as discouraging the features.

[dauwhe]

I like Matt's idea of a strict mode for EPUBCheck. Deprecated features would result in a warning in strict mode, and an info message in "regular" mode (thereby becoming invisible, as Matt says above).

Additionally,

1. Authors SHOULD NOT use deprecated features in new content.

2. EPUB 3.2 Reading Systems MUST NOT support deprecated features when their replacement exists (i.e. must not use ncx instead of nav, must not use guide instead of landmarks, etc.). This may have to be defined feature-by-feature).

3. EPUB 3.2 Reading Systems MAY ignore deprecated features in general (if I'm building an EPUB Reading System from scratch I don't have to support bindings).

4. EPUB 3.0 Reading Systems MAY refuse to support remote resources, foreign resources without fallbacks, and new opf:* attributes.

5. Deprecated features WILL NOT be supported in EPUB 4.

This gives us a clear set of behaviors for everyone involved, allows existing content to remain valid, and provides a clearer path to the future.

[JayPanoz]

Microsoft shipped the support of EPUB in Edge. They implemented trigger. I heard that iBooks on iOs supports trigger also.

You can add Kobo to this list. It’s not mentioned in their guidelines but they at least have a partial implementation of epub:trigger since I know of an instance where they pushed for it aggressively in order to fix an audio-related bug they didn't know how to solve.

[murata2makoto]

Since the audible support is increasing, trigger night be widely used in the near future. I think that neither trigger nor switch should be dropped. Rather than playing with "deprecated", "superseded", "may", "must", and so forth, I would like to simply state that they do not come from HTML5 and stop there.

[dauwhe]

Rather than playing with "deprecated", "superseded", "may", "must", and so forth, I would like to simply state that they do not come from HTML5 and stop there.

I don't think that provides any guidance for authors, validators, or reading system developers.

[llemeurfr]

@murata2makoto it seems that audio player can be create with HTML5/CSS/JS without real issue, and that many RS don't implement the feature (Readium is one on them). So even if a 3.x must be backward compatible with 3.0.1, a mention that refrains authors using it would be welcome. It should IMO mention that content which includes trigger cannot expect to be readable a) globally b) durably (it is too much specific, not webby enough).

The current issue is about switch: my position is the same, as MathML is a first call citizen of EPUB 3, the need for content level fallback has faded.

[GarthConboy]

I agree. We've had poor success with stuff we've dreamed up from whole cloth. I'd prefer deprecated for both, or at least "marked for deprecation" (to get some complaint out of epubcheck, eventually). But, as these both clearly won't make EPUB4, I'd go with deprecate. [but, like with version number, won't hold my breath and turn blue]

[murata2makoto]

@dauwhe Unlike me, you are not pessimistic. My experiences in the past (including XML, OOXML, and ODF among others) make me pessimistic. Detailed requirements on document processing applications are not very enforceable and tend to disallow some useful implementations. They will have little impacts on the real world. It is better to keep them simple. Of course, epubcheck will matter.

[dauwhe]

I've been trying to research the feature removal thresholds for the major browsers. Looks like Blink's is around 0.03%.

If one in a million EPUBs use epub:switch, we should remove it. If it's one in a hundred, we shouldn't. Where can we get the necessary information, and what should our threshold be?

[murata2makoto]

@llemeurfr and @GarthConboy Allowing switch and trigger while d**ing them is fine to me.

[kevinhendricks]

Whatever you decide to do, please do NOT promote their use in epubs as they require a reading system based on a browser engine and some javascript to rewrite the DOM on the fly before display. Normal browser engines without pre-processing the DOM do not support the epub:switch element.

In general, sticking with things a normal (webkit) based browser engine can support without add-ons and nonsense will improve adoption.

[mattgarrish]

Closing this issue as its meandered through several issues that have now been reposted individually from the 3.2 google doc.