Clarify epub:type use and restrictions on svgs

[mattgarrish]

This largely implements the text in https://github.com/w3c/epub-specs/issues/2555#issuecomment-1630989881 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:type attribute on renderable elements.

Fixes #2555 Fixes #2556

---

Preview | Diff

[mattgarrish]

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.

[iherman]

+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 https://github.com/w3c/epub-specs/pull/2575#issuecomment-1646519990 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?

[mattgarrish]

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.

[mattgarrish]

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

[mattgarrish]

I've updated this pull request to incorporate the changes that were in #2575.