- From: Erik Dahlström <ed@opera.com>
- Date: Tue, 24 Jun 2014 14:16:20 +0200
- To: "Dirk Schulze" <dschulze@adobe.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "robert@ocallahan.org" <robert@ocallahan.org>, www-svg <www-svg@w3.org>
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