Clarify epub:type use and restrictions on svgs#2574
Conversation
clarify fragments are for inclusion
|
I was looking at the rest of the spec and found a couple of places where we referred to "embedded SVGs" generally when we meant included SVGs. I also noticed that the svg content documents section requires standalone svg file conformance, so that conflicted with the embedding section referring to svg document fragments for both embedding types. I moved the fragment reference into the inclusion definition. |
|
+1 on the content change. Process question to @plehegar. This is a class-2 change. My understanding is that such change can be made on the document without further ado (publishing the result through the webmaster, that is). However, if this version is combined with another, class-3 change (#2575 in this case), does my remark in #2575 (comment) concern the class-2 changes as well, i.e., they should also be marked via ins/del elements, or is it o.k. to do direct change on the document for these? |
rdeltour
left a comment
There was a problem hiding this comment.
The change looks OK to me.
About the specific issue of how the epub:type is defined for included SVG, I still find the reading a little mazy:
- the "by inclusion" bullet says content conformance constraints are defined by 6.2.3… but not only, wait for the next paragraph.
- we need to make a special case for
epub:type, by pointing to a bullet in the restrictions for SVG content documents.
What about moving instead the epub:type SVG restrictions from the bullet in "6.2.2 SVG Requirements" to a new paragraph in "6.2.3 Restrictions on SVG"?
To summarize, what I'm suggesting is:
- in 6.2.2:
replace
MAY include the
epub:typeattribute for expressing structural semantics. When specified, the attribute MUST only be included on structural, shape, or text elements [svg].
by
MAY include the
epub:typeattribute for expressing structural semantics. When specified, the attribute MUST conform to constraints expressed in 6.2.3 Restrictions on SVG
- in 6.2.3, add a new bullet in the restrictions list:
the
epub:typeattribute MUST only be included on structural, shape, or text elements [svg].
- in 6.1.4.2, the paragraph "Although the XHTML content (…) in the same way as for SVG content documents." can now be removed.
|
Maybe we can do without mentioning epub:type in 6.2.2. I hate splitting the allowed and restricted parts of the attribute. It's sort of like if we had separate sections in the HTML extensions and constraint subsections to define each part of how you can use epub:type. SVG already allows foreign namespaced attributes and elements, so we're not actually allowing anything in 6.2.2 that the SVG spec doesn't already allow. The two "MAY" bullets could be expressed as a note without changing anything normative. I'm going to play around with this a bit more. |
rdeltour
left a comment
There was a problem hiding this comment.
Looks cleaner and more readable to me! 👍
|
@iherman I'm wondering if we should merge this with #2575? I'm not sure it qualifies as a class 3 change, as we're only taking a couple of unnecessary MAY statements and turning them into a note, but it's going to make a merge conflict because the bullet that 2575 is changing is now in a different section. It might be simpler to make all these epub:type in svg changes together. |
|
I've updated this pull request to incorporate the changes that were in #2575. |
This largely implements the text in #2555 (comment) but I tried to further clean up the section to make it more readable.
The big difference is I split the embedding definitions out into a list and included the requirements for each in the bullets. The definitions were hard to read in a single paragraph and having the requirements follow them made the section sound jumpy.
It also makes the fix in issue #2555 to allow the
epub:typeattribute on renderable elements.Fixes #2555
Fixes #2556
Preview | Diff