Repository navigation
Clarify epub:type use with embedded SVG #2555
Description
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.
Activity
iherman commentedon Jul 11, 2023
A valid erratum, I believe, and it should be marked as such. Clearly a class 2...
@shiestyle @TzviyaSiegman @dauwhe @wareid
mattgarrish commentedon 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
imgandobjecteven 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
svgelement in an XHTML file and that the same content restrictions apply to them.mattgarrish commentedon Jul 11, 2023
Or if it helps, when you embed an XHTML document via an
iframethat document doesn't become exempt from the xhtml content document rules, so there's no reason why referencing SVGs fromimgorobjectwould require a different definition of SVG.The only unique case is when an
svgelement 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., theprefixattribute should only be on the roothtmlelement, whileepub:typeis still allowed anywhere).iherman commentedon Jul 11, 2023
To be honest... for me, "embedded" meant the case when the
<svg>element is within the HTML markup. In other words,imgorobjectis 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 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 commentedon Jul 11, 2023
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:
iherman commentedon Jul 12, 2023
I think I agree this means class 2 changes.