Normative restrictions on scripting: is it necessary?

[iherman]

I was wondering about this paragraph in the EPUB spec:

EPUB Content Documents that include spine-level scripting MUST utilize the progressive enhancement technique, which for the purposes of this specification has the following definition: when the document is rendered by a Reading System without scripting support or with scripting support disabled, the Top-level Content Document MUST retain its integrity, remaining consumable by the user without any information loss or other significant deterioration.

I indeed ran into the following Web page:

https://ciechanow.ski/cameras-and-lenses/

this is a (in my view) superbly done page on photography basics, their physics, etc, which has tons of interactive graphics examples that are essential for understanding the subject. Looking at the source all the graphics are done via scripts; as far as I could see via a canvas of some sort and using GL (I must admit I did not go into the details). It is all 'local', in the sense of there is no external reference to major frameworks: it is all a bunch of clever scripts and CSS. I.e., this content could be turned into EPUB 3.3 and it would be a nice example of what an educational EPUB would look like.

Except that... it violates the normative restriction above. In this very case, I just do not see how the author could fulfill the requirement above. This page, and the text, is inherently bound to the interactive possibilities in the graphics; the text is simply not understandable without it. As a consequence, and in spite of what was said in the previous paragraph, it does not seem to be possible to turn this into a compliant EPUB 3.3.

Is it necessary to keep the MUST here? Would it be enough to use a SHOULD?

[mattgarrish]

Is it necessary to keep the MUST here? Would it be enough to use a SHOULD?

Since this can't be checked either way by machine, this is really more a philosophical requirement. It's also one primarily tied to retail ebooks.

When these kinds of requirements are weakened, EPUB can no longer claim to be inherently a more reliable reading experience than the web. I'm not saying it's the wrong direction -- this is arguably a best practice wrapped up as a normative requirement -- but that's the divergence from the original motivations.

On the web you can always use a browser that supports scripting, too. You generally don't have the same luxury with EPUBs (at least retail ones), so you can end up with angry customers who discover they paid for nothing. (But that's no more or less true today, or in the future however this might change.)

From an accessibility standpoint, I don't see that this statement matters a lot in its current context in the core specification. The potential lack of usability affects everyone equally in cases like this, and we don't require every publication be accessible. When accessibility is required, progressive enhancement is one possible technique, but those details are better left for WCAG, ARIA, etc.

Long story short, it sort of begs to be a note, or to be hived off with core media types into a separate document on how to author epubs for maximum usability.

[llemeurfr]

On the web you can always use a browser that supports scripting, too. You generally don't have the same luxury with EPUBs (at least retail ones), so you can end up with angry customers who discover they paid for nothing. (But that's no more or less true today, or in the future however this might change.)

I don't really agree with that part: either the EPUB file is distributed in a closed environment, and in this case it is up to the solution provider to check that the content plays well with the reading app it imposes; or it is in an open environment and the user can choose a reading app which supports the content he gets, whatever complex it is.

The real issue is habits and marketing: habits because people using an "EPUB compliant" e-reader believe that it should be able to read ANY possible EPUB 3; marketing because EPUB promoters never consider creating a segmentation of EPUB complexity levels and compliant tools, making impossible for users to change their belief.

[iherman]

Since this can't be checked either way by machine, this is really more a philosophical requirement.

And that is a problem: if a feature cannot be checked in some way or other then it should not be normative.

Long story short, it sort of begs to be a note, or to be hived off with core media types into a separate document on how to author epubs for maximum usability.

I think it is important to have this somehow close to the core text on scripting, so I would be in favour of keeping this in the text but as a note.

[Doktorchen]

I contributed arleady to a wikibook about photography, therefore I know, it is not difficult to realise this without scirpted decorations.

The mentioned article has text, if this text explains everything understandle about the theme, it might be no problem, if an alternative access to the issue is provided per decoration (styling, scripting). On pages unkown for me I have script interpretation switched off by default, therefore I see the styled content of that pages - mainly the large gaps beween some paragraphs look surprising, this would be a hint to me, that the author has problems with styling methods ('and punctuation :'?), not more, but this happens quite often in the current web, therefore more an indication, that many authors in the web seem not to understand how to use (X)HTML and CSS probperly. ;o)

Interactivity, animation should be possible in SVG in EPUB 3.3 as well, there is no need for none declarative methods to provide such an alternative approach for the theme photography.

This requirement to provide accessible content within EPUB is pretty useful for some authors to think about how to provide alternative views to a theme beyond text, not instead, if they want to provide alternative approaches to the information at all.

[mattgarrish]

in this case it is up to the solution provider to check that the content plays well with the reading app it imposes

The vendor can't realistically check every incoming title to ensure that the content hasn't degraded because some or all of the scripting functionality isn't available, though. That would require manually checking all the incoming titles.

The publisher shouldn't distribute content that is brittle, but even there it can be a challenge since they probably aren't the ones doing the distribution to all channels.

EPUB promoters never consider creating a segmentation of EPUB complexity levels and compliant tools

As long as scripting support remains underdefined, I don't think it's even realistic we could categorize support.

[dauwhe]

either the EPUB file is distributed in a closed environment, and in this case it is up to the solution provider to check that the content plays well with the reading app it imposes

I think history shows that solution providers ignore this responsibility.

[murata2makoto]

I think that "a best practice wrapped up as a normative requirement" is a bad idea since it makes other normative requirements doubtful. Best practices should be worded as notes.