-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify svg title phrasing content restrictions #2358
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I think the first sentence is unnecessary, because it repeats what the SVG spec already says. Per SVG spec a title
element may include just about anything using an XML namespace, and the first sentence is just repeating that. The only important restriction, consistent with the restriction on foreign objects, is that only the HTML namespace is acceptable.
The first sentence is, per se, not wrong, so if we are worried about backward compatibility, we may just as well keep it, although it seems that epubcheck did not do anything with the content of the title element so far...
The spec sort of alludes to elements defaulting into the html namespace in a note, although I'm not sure why this would be true except maybe when embedded in html:
I find these one-type requirements awkward to phrase, especially since it's not required to use any HTML markup. I guess we could try:
|
Yep, I found the SVG spec a bit awkward in this respect (let alone the fact that I doubt SVG implementation really do too much with titles...)
Yeah, better. But isn't it correct, per SVG spec, that it must be in the HTML namespace, ie, with an explicit xmlns statement? That is the way I understand the SVG spec... It may be better to make that explicit in our case, too... |
Yes, the HTML elements definition says its all elements in the http://www.w3.org/1999/xhtml namespace. We could make it even more explicit with:
I don't think we have to be that explicit, since we're using the xml flavour of svg, but no harm, either. You could write non-namespaced elements when embedded in HTML (for the HTML parser), but xml validation should flag them as non-conforming to the schema since they wouldn't be from a foreign namespace. But I can't find an example of anyone using html in a title anywhere. We could probably restrict the title to text if this is really to make reading system developer life simpler, since that's probably what almost all SVGs use anyway. Testing some more with epubcheck, though, it enforces the weird all-or-nothing approach the original prose made me think of. If you use anything but text in a title, all the content has to be in an html element to be valid:
You can't mix text and html elements like this or you get an error:
Given it took me a while to finally stumble on how to make epubcheck not complain, I'd be even more amazed if there are any EPUBs that have html markup in their titles. |
I would opt for using the text above, and call it a day...
So would I. I would go even further: I would be amazed if any HTML+SVG implementation would ever use the styling in the svg title element in displaying the tooltip, regardless of EPUB, and that anybody around would ever use this feature. Taking into account that the title element in HTML accepts only text as its content, I think that the richer structure of the SVG title element is an aspirational definition for now... But that is not our problem after all. Our reduced text just puts the title element in line with the rest of the SVG restrictions, and that is all we should do. |
I forgot to react on this:
I would not bother. It puts an extra load of checking on the RS Implementers, whereas currently RS implementations can simply push the corpse into WebViews' courtyard without any further ado. Let the WebViews implementers deal with this. We could put a note into our spec warning implementers that if they care about interoperability they should stick with pure text. |
This PR implements the text in #2355 (comment)
I'm still not sure I see the point of the restriction, though.
Fixes #2355
Preview | Diff