epub:type="noteref" on <a> inside svg about epubcheck HOT 11 CLOSED

It does look like a false positive. Thanks for the report!

from epubcheck.

The "it includes" made me think there could be others not explicitly listed there, but maybe not.

Ya, I don't think so, beyond maybe extension elements -- but as far as I can tell those aren't rendered by default and I don't think epubcheck verifies them anyway. Looking at various element definitions, they all appear to be categorized as renderable or never-rendered content.

from epubcheck.

Thank you very much, @rdeltour @mattgarrish!

from epubcheck.

I had a closer look about this. Not sure how to interpret the spec:

• for SVG content documents, epub:type is now only allowed on on structural, shape, or text elements (a is not one of them, it is a container element).
• SVG embedded in HTML must follow the content conformance requirements defined for SVG content documents. EPUBCheck is in fact reusing the same schema for standalone SVG and embedded SVG fragments.

That said, strictly speaking, the last point above only references 6.2.3 "Restrictions on SVG", and the epub:type constraints mentioned in the first point above are defined in 6.2.2 "SVG requirements".

So this raises the following questions:

• shouldn't the epub:type requirements for SVG apply both to SVG content documents and embedded SVG? In that case, the spec should be fixed to ensure they do.
• does it really make sense to forbid epub:type on SVG a elements? if not, then the spec would need to be fixed too.

@mattgarrish @iherman any thoughts?

(edited to use dated spec refs)

from epubcheck.

shouldn't the epub:type requirements for SVG apply both to SVG content documents and embedded SVG? In that case, the spec should be fixed to ensure they do.

Ya, they do. The only difference between the two is that one is a standalone file and the other is a document fragment. I'm sure we can solve the referencing issue with a bit of work. We can't just reference the section that allows epub:type, though, because it also defines that svg content documents must be standalone files.

does it really make sense to forbid epub:type on SVG a elements

No, as I recall, the restrictions were added to try and match the HTML restriction that epub:type isn't allowed on metadata elements. The attribute should still be allowed on a elements. SVG isn't my area of expertise, so I don't know if it's as easy as adding in container elements to the list or not. @iherman, I believe you added the restrictions, so any thoughts on this?

(More relevant to when we fix the EPUB spec, but for some reason these category references in the 3.3 spec go to the SVG 1.1 definitions; the rest of the SVG references use "TR/SVG/" urls. We should look at fixing them.)

from epubcheck.

I'm sure we can solve the referencing issue with a bit of work. We can't just reference the section that allows epub:type, though, because it also defines that svg content documents must be standalone files.

yeah, the simplest might be to move the epub:type bullet to 6.2.3?

does it really make sense to forbid epub:type on SVG a elements

No, as I recall, the restrictions were added to try and match the HTML restriction that epub:type isn't allowed on metadata elements. The attribute should still be allowed on a elements.

👍

from epubcheck.

To be honest, I do not remember any more, so I would have to look at all this more closely, and I am not sure I can do that before Monday or maybe even Tuesday.

However... with my W3C staff contact's hat on: the spec is now in Proposed Rec, ie, under the vote of the AC. In theory, provided that the AC will vote positively, the only changes that we will be allowed to do when moving the document to a Rec are cosmetic ones: spelling mistakes, essentially (plus the adaptation of the document header and the status section). This means that this thing should be submitted as a possible Erratum to the spec, with a Summary as for the proposed handling of it, and once the maintenance WG has been set up, that WG may decide to make a republication following the process. I am sorry to be awfully administrative with al this, but that is the way it is, and we will have to follow the rules...

from epubcheck.

that is the way it is, and we will have to follow the rules...

sure, but in any case we can incubate any erratum to the PR spec in EPUBCheck (as long as we figure out what to do here).

from epubcheck.

but in any case we can incubate any erratum to the PR spec in EPUBCheck

Ya, I wasn't considering the actual fixing of the spec at this point. What we need to figure out is what the restriction should be for svg.

Looking at the SVG2 spec, is there any reason why we couldn't have just said the epub:type attribute must be used on renderable elements?

That definition includes a along with most of what is in the other 1.1 categories. It doesn't look like it would allow epub:type on reference elements like tref, defs, or symbol, but do those matter for structural semantics? (i.e., would epub:type be specified elsewhere in those cases?)

from epubcheck.

Looking at the SVG2 spec, is there any reason why we couldn't have just said the epub:type attribute must be used on renderable elements?

Yes, I figured the same (but I'm no SVG expert).
Also, I couldn't find a compiled list of renderable elements… beyond making one myself by looking at all the elements individually 😅

from epubcheck.

Also, I couldn't find a compiled list of renderable elements… beyond making one myself by looking at all the elements individually 😅

Oh, scratch that, maybe the elements listed in the paragraph is all I need. The "it includes" made me think there could be others not explicitly listed there, but maybe not.

from epubcheck.