Disallow manifest-level fallback for elements within HTML or SVG content documents

[GoogleCodeExporter]

See 
http://code.google.com/p/epub-revision/wiki/PublicationsFeedback2#6.2.3_Intrinsi
c_fallback

Original issue reported on code.google.com by eb2m...@gmail.com on 9 Apr 2011 at 1:57

[GoogleCodeExporter]

Proposed resolution:

No change to current draft. If an  references a image of type "image/x-foozle" 
the fallback chain should be followed, the alt text being viable if there is no 
such Package fallback. Changing this would be a substantive change from 2.0.1 
and would need discussion and consensus.  Also, in EPUB 3 manifest fallback for 
XHTML and SVG is also used in a *new* context: as a means providing fallbacks 
for scripted content.

Original comment by ga...@google.com on 12 Apr 2011 at 6:24

[GoogleCodeExporter]

I would like to know if browser-based implementations of EPUB (such as 
iBook) really support this manifest-level fallback for HTML elements 
such as img.  I agree to close this issue if and only if they do.

Original comment by eb2m...@gmail.com on 12 Apr 2011 at 10:23

[GoogleCodeExporter]

I'm pretty sure some RS's implement this correctly (RMSDK, right?).  I don't 
see why a lack of feature in a browser-based implementation should drive us 
toward a major backwards-compatibility-breaking change at this late stage of 
the game.

Markus, perhaps an agenda item for tomorrow?

Original comment by ga...@google.com on 12 Apr 2011 at 11:04

[GoogleCodeExporter]

RMSDK does not implement fallbacks correctly. I do not see why it could not be 
implemented, though, in web-based or standalone apps. (Everyone should realize, 
though, merely unzipping content and throwing an XHTML is the browser does not 
make a web-based EPUB implementation; you have to do much more than that).

Original comment by soroto...@gmail.com on 19 Apr 2011 at 7:24

[GoogleCodeExporter]

Later this week, the following will be sent to the working group as the "Chairs 
recommended resolution."

Deferred for EPUB 3. Too late for substantive, not backward compatible, 
un-chartered change.  Also, in EPUB 3 manifest fallbacks for XHTML and SVG are 
used in a new context: as a means providing fallbacks for scripted content.

Original comment by ga...@google.com on 19 Apr 2011 at 11:52

[GoogleCodeExporter]

My counter proposal is to replace the first paragraph of 6.2.2 Manifest fallback
by "Manifest-level fallback applies only when the reading systems obtains
a publication resource from an identifier and the manifest.".

I tried to make a list of all attributes that reference to publication 
resources.  I searched for all occurrences of xsd:anyURI in the schemas.
But I find xlink:href is sometimes used for referencing publication 
ersources (image/@xlink:href in SVG) and sometime used as a hypertext 
link to a supplementary resource.  I now think that it is extremely 
difficult to tell which elem/att in HTML, SVG, or MathML reference 
publication resources and thus subject to manifest-level fallback.

When browser-based implementations and Adobe RMSDK  do not support 
manifest-level fallback for elements within HTML or SVG content 
documents, why should we introduce such fallback in the EPUB spec?
At least such fallback should be deprecated and RSs should not be 
required to support it.

Original comment by eb2m...@gmail.com on 20 Apr 2011 at 4:55

[GoogleCodeExporter]

The WG has decided in favor of this proposal (see summary in 
http://code.google.com/p/epub-revision/wiki/Telcon20110427#manifest-level_fallba
cks). 

While tuning/prose improvements still remain to be incorporated, r2854 contains 
the basic edits needed to reflect this change.

Original comment by markus.g...@gmail.com on 30 Apr 2011 at 2:25

• Changed state: Done