Re: Making <switch> useful

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, 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/

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

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

> 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).

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

> 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 13:56:11 UTC