Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
BCWalters opened this issue Aug 5, 2018 · 7 comments
Closed

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

BCWalters opened this issue Aug 5, 2018 · 7 comments
Labels
EPUB33 Issues addressed in the EPUB 3.3 revision Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation Status-NeedsImplementorFeedback The working group requires more information from implementers before being able to decide on Topic-ContentDocs The issue affects EPUB content documents

Comments

@BCWalters
Copy link

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.
@mattgarrish mattgarrish added this to the EPUB 3.2 milestone Aug 6, 2018
@mattgarrish mattgarrish added the Topic-ContentDocs The issue affects EPUB content documents label Aug 6, 2018
@mattgarrish
Copy link
Member

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?

@iherman
Copy link
Member

iherman commented Aug 7, 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...

@murata2makoto
Copy link
Contributor

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

@mattgarrish mattgarrish added the EPUB32 Issues from 3.0.1 resolved in the EPUB 3.2 specification label Aug 14, 2018
@dauwhe dauwhe added the Agenda+ Issues that should be discussed during the next working group call. label Aug 15, 2018
@dauwhe dauwhe added Status-NeedsImplementorFeedback The working group requires more information from implementers before being able to decide on and removed Agenda+ Issues that should be discussed during the next working group call. labels Aug 22, 2018
@dauwhe
Copy link
Contributor

dauwhe commented Sep 25, 2018

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 dauwhe added Agenda+ Issues that should be discussed during the next working group call. Status-Deferred The issue has been deferred to another revision and removed Agenda+ Issues that should be discussed during the next working group call. EPUB32 Issues from 3.0.1 resolved in the EPUB 3.2 specification labels Sep 25, 2018
@dauwhe dauwhe removed this from the EPUB 3.2 milestone Apr 17, 2019
@iherman
Copy link
Member

iherman commented Oct 29, 2020

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

@dauwhe dauwhe removed the Status-Deferred The issue has been deferred to another revision label Nov 18, 2020
@dauwhe
Copy link
Contributor

dauwhe commented Nov 18, 2020

  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 added a commit to dauwhe/epub-specs that referenced this issue May 4, 2021
@dauwhe
remove requirement to support SVG requiredExtensions attribute per w3…
871951e 
…c#1087
@iherman iherman mentioned this issue May 4, 2021
Merged
dauwhe added a commit that referenced this issue May 4, 2021
@dauwhe
Merge pull request #1662 from dauwhe/issue-1087
faa7866 
remove requirement to support SVG requiredExtensions attribute per #1087
@dauwhe
Copy link
Contributor

dauwhe commented May 4, 2021

Closed via #1662

@dauwhe dauwhe closed this as completed May 4, 2021
@mattgarrish mattgarrish added the EPUB33 Issues addressed in the EPUB 3.3 revision label May 11, 2021
rdeltour added a commit to w3c/epubcheck that referenced this issue Jul 8, 2022
@rdeltour
feat: do not check conformance of SVG content
ba48aaa 
EPUB 3.3 no longer requires that SVG content conforms to SVG content model requirements,
only that they are well-formed, that ID are uniques, and that they respect some additional
EPUB-specific requirements.

This commit:
  * introduces a new permissive RelaxNG schema for SVG, checking only the EPUB-specific
    requirements on the `title` and `foreignObject` content model
    see w3c/epub-specs#1323
  * removes checks on the value of the `requiredExtensions` attribute of `foreignObject`
    see w3c/epub-specs#1087
  * adapts the main XHTML to SVG schema driver to the new permissive SVG schema
  * adds various tests for EPUB-specific requirements
rdeltour added a commit to w3c/epubcheck that referenced this issue Aug 18, 2022
@rdeltour
feat: do not check conformance of SVG content
edc8b3b 
EPUB 3.3 no longer requires that SVG content conforms to SVG content model requirements,
only that they are well-formed, that ID are uniques, and that they respect some additional
EPUB-specific requirements.

This commit:
  * introduces a new permissive RelaxNG schema for SVG, checking only the EPUB-specific
    requirements on the `title` and `foreignObject` content model
    see w3c/epub-specs#1323
  * removes checks on the value of the `requiredExtensions` attribute of `foreignObject`
    see w3c/epub-specs#1087
  * adapts the main XHTML to SVG schema driver to the new permissive SVG schema
  * adds various tests for EPUB-specific requirements
@mattgarrish mattgarrish added the Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation label Sep 14, 2022
@rdeltour rdeltour mentioned this issue Dec 1, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
EPUB33 Issues addressed in the EPUB 3.3 revision Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation Status-NeedsImplementorFeedback The working group requires more information from implementers before being able to decide on Topic-ContentDocs The issue affects EPUB content documents
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@iherman @mattgarrish @murata2makoto @dauwhe @BCWalters