Make unknown elements behave exactly as if the element name were replaced by 'g'

[nikosandronikos]

This behaviour will simplify things and tidy up a few other issues.

[dirkschulze]

@nikosandronikos I thought we did not want to do that because of obvious problems with the HTML5 parser? IIRC there were pages that could break. And it would require substantial changes to HTML5 as well.

[nikosandronikos]

@dirkschulze What's your recollection of what we did want?
Document structure says to treat unknown as 'g' for rendering purposes already.
https://svgwg.org/svg2-draft/struct.html#UnknownElement

[dirkschulze]

@nikosandronikos i thought we reverted the decision because of the mentioned problem and negative feedback from the HTML guys. And this was probably not encountered on writing this paragraph.

[nikosandronikos]

Looks like we did
https://www.w3.org/2013/02/06-svg-minutes.html#action10

[AmeliaBR]

I am confused by this change. If we've got conflicting resolutions from different years, shouldn't we at least discuss? Why not keep SVGUnknownElement, but make it clear that the HTML parser can still work the way it currently does when it encounters an element that is valid in HTML?

Regardless, if we are going to get rid of a future-focused approach to unknown elements, then we really need to fix the future-focused aspects of <switch> feature testing.

[nikosandronikos]

The most recent resolution was to drop it.
The first resolution is very wishy washy, quite a lot of people didn't like the feature.

Here's the history that I could find:

First discussion of requirement:
https://www.w3.org/2012/01/13-svg-irc#T23-54-06
Group was worried about breaking existing content. Didn't seem sold on the feature. Resolution was dependent on getting feedback about how content would be impacted.

The later discussion of dropping the requirement, and using SVGElement for unknown elements: https://www.w3.org/2013/02/06-svg-minutes.html#item09
https://www.w3.org/2013/11/14-svg-minutes.html#item04 (topic wasn't captured, so scroll up from there)

The weird thing is, @erikdahlstrom made the change after that resolution in df82a47
This was just prior to a F2F, so perhaps he was trying to get the chapter in order and address the annotations that had been added?

[erikdahlstrom]

I was sceptical in the first discussion, https://www.w3.org/2012/01/13-svg-irc#T23-54-06, but was convinced that it was fine later on.

I see you changed the wording (738f1e8#diff-eb0a191797624dd3a48fa681d3061212) since I last touched the spec text, and the current wording doesn't seem to make sense to me.

Particularly this paragraph: "Elements and SVG document fragments rooted by those elements, that are in the SVG namespace and are not defined by this specification must not be rendered, but must be included in the DOM tree."

Not sure what "those elements" refers to, and if it's "unknown elements" then what that is needs to be specified too.

The example shows <text><text></text></text>, which is a known svg element, that needs further explanation for why it shouldn't render (presumably because it violates the text element content model).

Sad to see the "rendering of unknown elements" feature dropped, because <switch> is a really bad substitute IMHO.

[nikosandronikos]

Do you recall where later discussions happened? I can't find anything after the 2013 Sydney F2F.

Sad to see the "rendering of unknown elements" feature dropped, because is a really bad substitute IMHO.

Could you clarify the above comment? substitute for what?

I don't mind putting it back in, there'll be some further tidying up needed (per the original subject of this issue). In removing it, I was just going off the latest resolutions I could find.

[jarek-foksa]

Elements and SVG document fragments rooted by those elements, that are in the SVG namespace and are not defined by this specification must not be rendered, but must be included in the DOM tree.

The SVG spec should make exception here for properly registered custom elements. While the Custom Elements spec does not currently allow for registering elements in the SVG namespace, this will probably change in future.

[AmeliaBR]

@jarek-foksa That's one of the main reasons for at least supporting basic rendering of an unknown element: allowing upgrades and new features in a backwards compatible manner.

At yesterday's telcon, we resolved to adopt the "unknown elements are treated like <g>" behavior in SVG 2, but to mark it as "at risk" pending implementer feedback.

[jarek-foksa]

According to the current definition custom elements must inherit from SVGUnknownElement, which does not seem right.

[nikosandronikos]

Custom elements aren't supported for SVG. When they are, we can define that anything registered as a custom element isn't an unknown element. I'd rather not add speculative normative text now.