Re: Making <switch> useful

Hi,

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.

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

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.

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

Greetings,
Dirk


On Sep 10, 2013, at 3:33 AM, Satoru Takagi <sa-takagi@kddi.com> wrote:

> Hi Mr. chris,
> 
>>> I've therefore been wondering if there be interest in adding a @media 
>>> test attribute for <switch>.
> 
> +1
> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#5.9.2_The_.27switch.27_
> element
> 
> But, I like that it is the same element in HTML and SVG. And application coverage of switch is 
> larger than picture.
> 
> 
> 
> Although cord size is big, similar processing can be expressed by Resource Priorities and css 
> media queries.
> ===== switch + media attr.
> <svg>
>   <switch>
>    <image media="(min-width: 45em)" xlink:href="large.jpg" width="500" height="500">
>    <image media="(min-width: 18em)" xlink:href="med.jpg" width="500" height="500">
>    <image xlink:href="small.jpg" width="500" height="500">
>   </switch>
>   <title>Accessible text</title>
> </svg>
> 
> 
> ===== css media queries + Resource Priorities
> <svg>
> <style>
> @media (min-width: 18em){
>  #sma{   display : none;  }
>  #med{   display : inline;  }
> }
> @media (min-width: 45em){
>  #sma{   display : none;  }
>  #med{   display : none;  }
>  #lar{   display : inline;  }
> }
> </style>
> <image id="lar" postpone display="none" src="large.jpg" width="500" height="500">
> <image id="med" postpone display="none" src="med.jpg" width="500" height="500">
> <image id="sma" postpone display="inline" src="small.jpg" width="500" height="500">
> </svg>
> 
> 
> Regards,
> 
> Satoru Takagi
> 
>> Hello Robin,
>> 
>> Monday, September 9, 2013, 9:48:56 PM, you wrote:
>> 
>>> I've therefore been wondering if there be interest in adding a @media 
>>> test attribute for <switch>.
>> 
>> Yes, its a clear and obvious thing to do. Media queries evaluate to
>> true or false so are a good fit for the switch construct.
>> 
>> Just had dinner with Marcos and Youav from the responsive images group
>> (they are meeting tomorrow at Mozilla France, where CSS WG will be
>> meeting the next three days) and they thought it was a good idea too.
>> 
>>> I realise that it makes it dynamic;
>> Its already dynamic (or should be).
>> 
>>> though
>>> I would hope that that has relatively minimal impact on implementation
>>> (given that the DOM is there and live anyway). A somewhat clearer 
>>> processing model for <switch> might have to be written, but it seems 
>>> manageable.
>> 
>>> For backwards compatibility, it would currently be necessary to polyfill
>>> @media ・but that's doable. If this proves useful for responsive images
>>> though, I have to admit that I'll it would be rather tempting to just 
>>> highjack this into HTML :)
>> 
>> Its an obvious combination that should be documented in SVG2.
>> 
>> Which html5 element(s) would it go on?
>> 
>> 
>> -- 
>> Best regards,
>> Chris                            mailto:chris@w3.org
>> 
>> 
>

Received on Tuesday, 10 September 2013 10:23:33 UTC