Epub-specs: Most readers probably don't follow the MUST about the requiredExtensions attribute for SVG

Created on 5 Aug 2018  路  6Comments  路  Source: w3c/epub-specs

SVG Reading System conformance

It MUST recognize the value "http://www.idpf.org/2007/ops" of the requiredExtensions attribute as representing the occurrence of XHTML Content Document fragments (e.g., when the attribute is included on the foreignObject element or children of the switch element).

Presumably there was a good historical reason for this that's lost on me, but I doubt most EPUB readers do anything with this MUST.

Spec-ContentDocs Status-NeedsImplementorFeedback
Source
picture BCWalters

Most helpful comment

  1. all browsers ignore requiredExtensions="http://www.idpf.org/2007/ops".
  2. Chrome ignores requiredExtensions="http://www.w3.org/1999/xhtml", but Firefox and Safari support it.

I think we absolutely need to remove this from the spec.

picture dauwhe on 18 Nov 2020
👍2

All 6 comments

OPS 2.0.1 has this to say about it:

Since OPS is, by definition, supported in EPUB Reading Systems, the requiredExtension attribute on SVG elements with the value http://www.idpf.org/2007/ops must always evaluate to true.

But since we've deprecated out almost all epub-created extensions, I'm not sure if this is still necessary.

@rkwright @iherman @murata2makoto any thoughts?

mattgarrish picture mattgarrish on 7 Aug 2018

@rkwright should know infinitely more about this than me, but I chime in anyway...

  • If I look at the text purely from standard perspective then something like this URL is needed for the <switch> element to work to signal whether the SVG implementation does implement <foreignObject>. Strangely enough (@rkwright ?) there is no mention in the text on some form of a registry or whatever for what extensions means; I must admit I did not really understood from the SVG text how this thing should work.

  • In practice, however, it seems that the traditional example of combining switch and foreign object (with HTML) simply works in browser engines (I tried it in Safari, Chrome and Firefox; I do not have Edge on my mac but I would expect that to work, too). In other words, @BCWalters is right in the sense that the attribute is probably simply ignored by implementations, ie, a MUST in our standard sounds indeed superfluous...

iherman picture iherman on 7 Aug 2018

I do not know if non-EPUB SVG often uses the svg:switch and svg:foreignObject elements as representing the occurrence of XHTML Content Document fragments. If this is the case, I think that we can lift the requirement that requiredExtensions shall be "http://www.idpf.org/2007/ops".

murata2makoto picture murata2makoto on 9 Aug 2018

So what happens here? Note that browsers don't have interop on this鈥擟hrome shows "baz" and Firefox/Safari show "bar". 

<svg width="400px" height="300px" viewBox="0 0 400 300"
     xmlns="http://www.w3.org/2000/svg">
<switch>
     <foreignObject width="100" height="50"
                   requiredExtensions="http://www.idpf.org/2007/ops">
      <body xmlns="http://www.w3.org/1999/xhtml">
        <p>Foo</p>
      </body>
    </foreignObject>
    <foreignObject width="100" height="50"
                   requiredExtensions="http://www.w3.org/1999/xhtml">
      <body xmlns="http://www.w3.org/1999/xhtml">
        <p>bar</p>
      </body>
    </foreignObject>
    <text font-size="10" font-family="Verdana">
      <tspan x="10" y="10">baz</tspan>
    </text>
</switch>
</svg>

The goal seems to be to embed XHTML Content Document Fragments. But those exist in the XHTML namespace, not the OPS namespace (mostly). I'm struggling to find a reason we need this.

dauwhe picture dauwhe on 25 Sep 2018

I have run into the statement in the spec earlier today.

Here is a test case I have (used as part of a cover image):

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"  version="1.1" viewBox="0 0 595 842">
    <foreignObject y="200" width="100%" height="100%" requiredExtensions="http://www.idpf.org/2007/ops">
        <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: center; justify-content: center">
            <div style="display: inline-block; font-size: 40px; font-family: sans-serif; color: #005A9C; line-height: 1.2; font-weight: bold; font-style: italic; white-space: nowrap; text-align: center">
                EPUB 3 Overview
            </div>
        </div>
    </foreignObject>
    <foreignObject  y="400" width="100%" height="100%" >
        <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: center; justify-content: center">
            <div style="display: inline-block; font-size: 20px; text-align: center; ">
                W3C Editor's Draft<br/>26 October 2020
            </div>
        </div>
    </foreignObject>
</svg>

Ran it on three browsers (Safari, Chromium based Edge, and Firefox) as well as part of an EPUB on Thorium (on my Mac). The behaviour of all four was identical:

  • as it stands, the foreign object with the required extensions set was not displayed, the second one was as planned
  • removing the required extensions attribute means both foreign object displays properly.

2 years have passed since since the test of @dauwhe (https://github.com/w3c/epub-specs/issues/1087#issuecomment-424375061) and we do have interop now on browsers. I could not test it on Apple Books because it does not seem to use a cover page set as an SVG file :-(

As everybody on this thread, it seems, I do not see any reason why this statement is in the spec; it may have a historical reason. With 3.3 on its way, I would think this statement should be deprecated from the spec (and possibly add a note advising _not_ to use this because there may be issues displaying the content).

cc @mattgarrish @wareid @shiestyle

iherman picture iherman on 29 Oct 2020
👍1
  1. all browsers ignore requiredExtensions="http://www.idpf.org/2007/ops".
  2. Chrome ignores requiredExtensions="http://www.w3.org/1999/xhtml", but Firefox and Safari support it.

I think we absolutely need to remove this from the spec.

dauwhe picture dauwhe on 18 Nov 2020
👍2
Was this page helpful?
0 / 5 - 0 ratings

Related issues

mattgarrish picture mattgarrish  路  6Comments
dauwhe picture dauwhe  路  3Comments
iherman picture iherman  路  13Comments
mattgarrish picture mattgarrish  路  7Comments
murata2makoto picture murata2makoto  路  12Comments