Re: A few comments on http://dev.w3.org/SVG/proposals/improving-svg-dom/

On Jun 24, 2014, at 7:56 AM, 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?)

That might get clear if we could decide on making SVGElement implement HTMLElement (and solving all issues including the mentioned issues in this thread).

No, the problem that I see are new elements for paint servers like <color>, mesh gradients, conical gradients (I hope it stays in CSS) or new operation types in addition to <mask>, <filter> and so on. The content of these elements shall not be displayed. Or the layout might depend on a new created viewport by the currently unknown element. This is an issue of forwards compatibility.


> 
>> 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>.
> 
> 
>>> Seems to me that getCTM, getScreenCTM and getTransformToElement should all be replaced by a new GeometryUtils method, say getTransform(optional TransformOptions options), with TransformOptions { GeometryNode to; }.
>> 
>> The interface from CSSOM View definitely applies to SVG as well[2].
>> 
>> There is nothing comparable to getCTM, getScreenCTM yet. Note that Canvas has a currentTransform attribute that some browser vendors would like to replaced with a non-live getter. This could be an opportunity to unify the API across SVG, CSS/HTML and Canvas. However, at this point I would say that the support for getCTM is mandatory. A lot of content uses it today already.
> 
> I'm in favor of a nice general new GeometryUtils method, and if
> necessary, supporting getCTM as an alias of the method with filled-in
> arguments.

As long as we alias getCTM to do the right thing, I am fine. In general I support an API that is less SVG focused. getScreenCTM is not reliable in WebKit or Blink based browsers — at least when it comes to inline SVG or high-DPI displays — but can still be aliased to the new API.

Greetings,
Dirk

> 
> ~TJ
>

Received on Tuesday, 24 June 2014 07:30:39 UTC