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.

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

Clarify epub:type use with embedded SVG #2555

Closed
mattgarrish opened this issue Apr 24, 2023 · 6 comments · Fixed by #2574
Closed

Clarify epub:type use with embedded SVG #2555

mattgarrish opened this issue Apr 24, 2023 · 6 comments · Fixed by #2574
Assignees
Labels
Change-Class-3 Requested changes are of class 3 (per process) Editorial For classifying errata only. Use Type-Editorial for issues EPUB33 Issues addressed in the EPUB 3.3 revision Errata Item accepted as an official errata for one or several specs Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation Topic-ContentDocs The issue affects EPUB content documents

Comments

@mattgarrish
Copy link
Member

As reported in w3c/epubcheck#1497 (comment), the specification is not clear that the restriction on where epub:type can be used with svg content documents also applies to embedded svg. The restriction should either be in the referenced restrictions section or there should be a separate section for semantics that embedded svg definition can reference.

@mattgarrish mattgarrish added Topic-ContentDocs The issue affects EPUB content documents Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation labels Apr 24, 2023
@iherman iherman added the ErratumRaised Raise an erratum, not yet accepted by the maintainers. label Apr 24, 2023
@iherman
Copy link
Member

iherman commented Jul 11, 2023

A valid erratum, I believe, and it should be marked as such. Clearly a class 2...

@shiestyle @TzviyaSiegman @dauwhe @wareid

@mattgarrish
Copy link
Member Author

mattgarrish commented Jul 11, 2023

I'm starting to think the embedded SVG definition is muddled in other ways than this issue has gotten into.

For one, the XHTML content document definition already allows the use of epub:type and the vocabulary association mechanisms. Since embedded SVG are part of the XHTML grammar, wouldn't it be redundant to say that the same is true for them?

But why are SVG files referenced by img and object even considered embedded? If you use those elements, you're referencing SVG documents (i.e., standalone SVGs in a separate file). That requires them to be valid SVG core media types which in turn means they have to meet the definition of an SVG content document.

I was going to say this is a class 3 change, since we'd be allowing epub:type and the vocabulary mechanisms where they technically weren't before, but I don't think anything normative needs changing. We probably just need to make clear that embedded SVG refers to the svg element in an XHTML file and that the same content restrictions apply to them.

@mattgarrish
Copy link
Member Author

Or if it helps, when you embed an XHTML document via an iframe that document doesn't become exempt from the xhtml content document rules, so there's no reason why referencing SVGs from img or object would require a different definition of SVG.

The only unique case is when an svg element is directly embedded in the HTML. The restrictions need to be the same as standalone SVGs, but the vocabulary stuff is already handled by the HTML requirements (e.g., the prefix attribute should only be on the root html element, while epub:type is still allowed anywhere).

@iherman
Copy link
Member

iherman commented Jul 11, 2023

I'm starting to think the embedded SVG definition is muddled in other ways than this issue has gotten into.
[…]

But why are SVG files referenced by img and object even considered embedded? If you use those elements, you're referencing SVG documents (i.e., standalone SVGs in a separate file). That requires them to be valid SVG core media types which in turn means they have to meet the definition of an SVG content document.

To be honest... for me, "embedded" meant the case when the <svg> element is within the HTML markup. In other words, img or object is not really "embedded", at least to me. However... if one looks at the HTML standard, then the <img> element specification is part of a section entitled… "4.8 Embedded content". (The same terminology is used on MDN, b.t.w.)

I.e., if we want to keep to the official terminology then yes, these are "embedded" content (in spite of my expectations...)

I was going to say this is a class 3 change, since we'd be allowing epub:type and the vocabulary mechanisms where they technically weren't before, but I don't think anything normative needs changing. We probably just need to make clear that embedded SVG refers to the svg element in an XHTML file and that the same content restrictions apply to them.

I am fine with the underlying technical intention, but then the word "embedded" should be changed. Not sure whether this becomes an editorial nightmare, though...

@mattgarrish
Copy link
Member Author

mattgarrish commented Jul 11, 2023

if one looks at the HTML standard, then the <img> element specification is part of a section entitled… "4.8 Embedded content"

Right, this is why the section makes the distinction between embedded by reference and by direct inclusion, but then we lump both together and say that the svg content restrictions apply to both without clarifying any of the other details.

I'd like to see the section changed along these lines:

XHTML content documents support the embedding of SVG by reference (embedding via reference, for example, from an img or object element) and by inclusion (embedding via direct inclusion of the svg element in the XHTML content document).

SVGs embedded by reference are SVG core media types so their requirements are already defined in 6.2 SVG content documents.

SVGs embedded by inclusion MUST meet the content conformance constraints for SVG content documents in 6.2.3 Restrictions on SVG. Although the epub:type attribute is allowed on [HTML] embedded content, its use is restricted in the same way as for SVG content documents.

NOTE:
The prefix attribute is only allowed on the root html element for SVG embedded by inclusion.

@iherman
Copy link
Member

iherman commented Jul 12, 2023

I think I agree this means class 2 changes.

@iherman iherman added the Change-Class-2 Requested changes are of class 2 (per process) label Jul 18, 2023
@iherman iherman added Errata Item accepted as an official errata for one or several specs and removed ErratumRaised Raise an erratum, not yet accepted by the maintainers. labels Aug 4, 2023
@mattgarrish mattgarrish added Type-Editorial The issue does not affect conformance Editorial For classifying errata only. Use Type-Editorial for issues EPUB33 Issues addressed in the EPUB 3.3 revision and removed Editorial For classifying errata only. Use Type-Editorial for issues Type-Editorial The issue does not affect conformance labels Aug 9, 2023
@mattgarrish mattgarrish added Change-Class-3 Requested changes are of class 3 (per process) and removed Change-Class-2 Requested changes are of class 2 (per process) labels Sep 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Change-Class-3 Requested changes are of class 3 (per process) Editorial For classifying errata only. Use Type-Editorial for issues EPUB33 Issues addressed in the EPUB 3.3 revision Errata Item accepted as an official errata for one or several specs Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation Topic-ContentDocs The issue affects EPUB content documents
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants