Most readers probably don't follow the MUST about the requiredExtensions attribute for SVG

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.

@rkwright

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?

@rkwright

@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...

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".

So what happens here? Note that browsers don't have interop on this—Chrome 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

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 (#1087 (comment)) 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

all browsers ignore requiredExtensions="http://www.idpf.org/2007/ops".
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.

remove requirement to support SVG requiredExtensions attribute per w3…

Merge pull request #1662 from dauwhe/issue-1087

Closed via #1662

feat: do not check conformance of SVG content

Navigation Menu

Repository navigation

Most readers probably don't follow the MUST about the requiredExtensions attribute for SVG #1087

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Most readers probably don't follow the MUST about the requiredExtensions attribute for SVG #1087

Description

Activity

mattgarrish commented on Aug 6, 2018

iherman commented on Aug 7, 2018

murata2makoto commented on Aug 9, 2018

dauwhe commented on Sep 25, 2018

iherman commented on Oct 29, 2020

dauwhe commented on Nov 18, 2020

dauwhe commented on May 4, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions