Clarify epub:type use with embedded SVG about epub-specs HOT 6 CLOSED

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.

from epub-specs.

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

@shiestyle @TzviyaSiegman @dauwhe @wareid

from epub-specs.

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.

from epub-specs.

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

from epub-specs.

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

from epub-specs.

I think I agree this means class 2 changes.

from epub-specs.