Re: Making <switch> useful

On Sep 10, 2013, at 3:55 PM, Robin Berjon <robin@w3.org> wrote:

> Hi Dirk,
> 
> On 10/09/2013 12:23 , Dirk Schulze wrote:
>> I did not make up my mind on this idea but have some comments. All
>> browsers do support nearly all features of SVG. Naturally, switch
>> returns true for all the supported features. Language switching could
>> still be treated correctly by some browsers but we have different and
>> better ways to switch based on language anyway with the lang
>> attribute. Therefore, saying it is reliably implemented may not quite
>> get the point.
> 
> Well it does bring some important value: it means that the code is
> there,

It is there, SVG specific and not implemented correctly in at least two browser engines.

> and it means that it is possible to build shims on top of it that
> actually work. I did a quick hack on that assumption:
> 
>    http://berjon.com/presentations/20130910-ricg-switch/demo/

Right, you can archive the same what you did in the demo with media queries and display: none instead and no JS would be involved at all. The todays switch does not give you any more value.

> 
>> The question is what you really want to address with the switch
>> element. From what I see from your suggestion, it is some kind of a
>> counter proposal (or supporting proposal?) to <picture> to select the
>> right image to render.
> 
> Yes, it is a proposal/friend of the picture element. Its goal is to
> address the same use cases but in a way that can leverage what's already
> in implementations, provide viable fallback, and allow relatively simple
> shims.
> 
> Note that it's not just for images, you can responsive all the things
> with it ― notably video.

All three share the same concern mentioned in the other response.

Also, did you check that Firefox and IE really don't create renderers for the child elements? Especially the image loading would be interesting here.

> 
>> If you look at the SVG content in the web
>> right now, just a very tiny part of SVG images actually embed pixel
>> images. The SVG files that do are mainly created by authoring tools
>> such as illustrator to export filters which were not supported by UAs
>> at the time.
> 
> I know, but that's not the point. The idea is not so much to change SVG
> as to take one of its features that's already supported and generalise
> it, making it more broadly available on the platform.

But it is not supported, at least not what you want of it.

> 
>> I would like to keep SVG a vector format and not just a container to
>> support the use case of <picture> which should be addressed
>> differently.
> 
> Agreed. I'd be happy to take pretty much everything that's not vectors
> out of SVG, and where it's useful make it globally available (in fact,
> I'd also like the vector stuff to be usable directly in HTML without any
> <svg> container ― but that's another story).

That is a different topic.

> 
>> Also, the usage of switch is very low, that is why the Chromium team
>> did investigate to remove it entirely. As a final note, at least for
>> WebKit and Blink still all nodes get processed and therefore all
>> image would be downloaded, even if they are rejected for drawing at
>> the end. Because of the low usage, there was never a need to fix this
>> behavior.
> 
> I know, I noticed that the implementation there is rather poor. It is
> not at all dynamic so that you have to kick the nodes in order to get
> changes to the DOM to apply. Nevertheless, it does leave the fallback
> door open.

What is the fallback? You don't have media query support on switch today. So you could actually use anything to archive the same as the switch element supports. Note that WebKit and Blink still load all resources that are children of <switch>. That means in the "meantime" you force WebKit/Blink based browsers to download ALL images, not just one too big image.

You may suggest <swicth> to WHATWG or HTML WG. If they and UAs adapt it, then there is nothing blocking the idea. I certainly won't. Most likely the browsers would reimplement <switch> from scratch then since the current version is restricted to SVG very much. And you can not even use <switch> from SVG as fallback in a meaningful way. Even a pure CSS solution would be more reasonable.

Greetings,
Dirk

> 
>> Unless you do not have other use cases which can not easily be
>> addressed with a simple class attribute and media queries in a CSS
>> style sheet, I do not see a need to encourage the usage of <switch>.
> 
> Well down that path you can handle responsive images would be handles
> with a <div> and backgrounds picked from MQs. This addresses the use
> cases that <picture> does by reusing some existing foundation and
> working on things other than pictures. I'm not saying that it's the
> silver bullet, but it does have some useful properties.
> 
> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 10 September 2013 15:03:47 UTC