Handling of unknown elements (was: Re: A few comments on http://dev.w3.org/SVG/proposals/improving-svg-dom/)

On Tue, 24 Jun 2014 07:56:41 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> On Mon, Jun 23, 2014 at 9:31 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> On Jun 24, 2014, at 5:01 AM, Robert O'Callahan <robert@ocallahan.org>  
>> wrote:
>>> Are <switch>, hasExtension, systemLanguage, requiredFeatures and  
>>> requiredExtensions worth keeping? I think this kind of feature  
>>> selection is widely considerd an anti-pattern at this point. Have  
>>> these actually been used in good ways? If so, I haven't seen it.
>>
>> <switch> and requiredFeatures have been used in the past. Mostly to  
>> check if filters are supported IIRC. In practice they probably return  
>> true already today and removing would not hurt if we would ignore  
>> <switch>. But SVG doesn’t “ignore” elements. An unknown element causes  
>> an error. We had discussions about interpreting unknown elements as  
>> <g>, personally I think this is a nightmare to support. The other APIs  
>> are under consideration for removal already.
>
> Why would it be hard to support "unknown elements act like <g>"?
> That's the desired behavior SVG web components, at least.
>
> (An interesting question is what prototype to give unknown elements
> that are descendants of an SVG element.  Do they get SVGElement, or
> HTMLUnknownElement?)
>
>> In Chrome the usage of <switch> is 0.027%[1], no data for the other  
>> attributes.
>
> Yeah, that's too much usage for straight dropping, given our current
> "ignore unknown elements" behavior, but would be fine if we switched
> to a "fail open" strategy of treating it like <g>.

I don't think "treating it like <g>" is general enough to apply  
everywhere, e.g existing <switch> content would not render correctly if it  
was treated that way, and there are elements where <g> child elements  
aren't allowed currently.

Regardless of which fallback strategy is used, can we even apply the same  
strategy for deprecated/removed elements without breaking existing content?

The "fail open" strategy seems better suited for content that is mostly  
textbased, but I'm not convinced it's the best choice for elements in svg  
in general. So, here's a crazy idea: why not render the text contents of  
unknown elements that are children of a <text> element?


-- 
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

Received on Tuesday, 24 June 2014 12:17:20 UTC