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

Hi!

I wonder, does supporting a media attribut on every SVG element (like on
the <link> or <source> HTML element) would be possible as an alternative to
the <switch> element for modern web design?


2014-06-24 7:56 GMT+02:00 Tab Atkins Jr. <jackalmage@gmail.com>:

> 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>.
>
>
> >> 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.
>
> ~TJ
>
>


-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>