W3C home > Mailing lists > Public > www-svg@w3.org > March 2014

Re: Media queries in <switch> elements

From: Chris Lilley <chris@w3.org>
Date: Fri, 14 Mar 2014 18:05:06 +0100
Message-ID: <154680031.20140314180506@w3.org>
To: Kari Pihkala <kari.pihkala@gmail.com>
CC: www-svg@w3.org
Hello Kari,

Friday, March 14, 2014, 11:20:56 AM, you wrote:

> I would like to get a clarification to the sentence "All others
> will be bypassed and therefore not rendered." in the switch element.

> What does "will be bypassed" mean?

> This question was actually asked already years ago:
> http://lists.w3.org/Archives/Public/www-svg/2005Jul/0042.html - without a proper answer.

I agree that the language in the spec should clearly define what is
meant. You seem to be imagining physical removal from the DOM, while
"not rendered" is the intention here.

> I tested the bypassed elements on browsers:

>  - the bypassed elements seem to be in the DOM tree

Yes. The other elements are not physically removed from the DOM.
Conditions on the switch may be dynamic and thus the branch which
evaluates to true may change over time.

>  - CSS selectors seem to always match them (e.g., the :first-child selector)

yes, as a consequence of their being in the DOM.

>  - content (image href) seems to always be loaded
>  - animations are run
>  - scripts are run
>
yes (same reason) although it would be useful to be able to have finer
grained control over media loading on non-rendered children of switch
(and on elements with display: none in general).

>  - events (onmouseover, what about others?) are not fired (because the element is not rendered?)

yes, and that is indeed the reason.

>  - a use element referencing a "not-rendered" element seems not to render it

yes (same reason)

>   - bounding boxes are inconsistent between browser

The bbox should be that of a non-rendered element (display: none).

>  - bounding boxes do not contribute to the parent bounding box

Correct.

Thanks for your careful testing. The results (except for the bbox
variability) are as expected.

> Looks like only the rendering is affected. There isn't really any "bypassing". Is that true?

That was the original intent of the spec wording. Given that you find
it confusing and also given that bypassing means the same thing as not
rendered, i suggest the following improved wording (this would be an
SVG 1.1 erratum and a change to SVG2):

  All others will not be rendered (as if the display property were
  set to none.)

Would that clarification address your comment?






> 2014-03-14 9:59 GMT+02:00 Kari Pihkala <kari.pihkala@gmail.com>:
>  
> Hi,


> The postpone attribute in Resource Priorities checks that the
> display attribute isn't 'none' and "the bounding box of the element
> is inside the User Agent's interpretation of the Document's viewport".
>   
> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePriorities_for_SVG

>   

> The switch element defines: ".. processes and renders the first
> child for which these attributes evaluate to true. All others will
> be bypassed and therefore not rendered."  
> https://svgwg.org/svg2-draft/struct.html#SwitchElement



> Does the switch element "not rendered" mean that the bounding box
> of the element is not inside the viewport? In that case, resource priorities will work nicely.


> What is the bounding box of a "not rendered" element? I tested
> Safari and Firefox on Mac and they seem to disagree. Safari gives
> (0,0,0,0) while FF gives real coordinates or an exception.  


> Is bounding box (0,0,0,0) inside the viewport? Is <image width="0"
> height="0" xlink:href="huge.png" postpone="true"/> loaded? 


> Anyway, this would be nice:  


> <image xlink:href="big.png" media="screen and (min-width: 10em)" postpone="true"/> 
>   <image xlink:href="small.png" media="screen and (max-width: 10em)" postpone="true"/>


> Cheers,
>   
> Kari




> 2014-03-14 8:11 GMT+02:00 Satoru Takagi <sa-takagi@kddi.com>:
>  

>    
> Hi,
>  
>  I wonder that the current implementations can offer the similar effect, although it
>  does not use 'switch'.
> 
> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Zoom_feature_for_media_queries#min.
>     2Fmax-width.2Fheight_properties_in_CSS_Media_Queries
>  Of course, it does not carry out conditional dynamic resource loading.
>  Then, we had a discussion on dynamic loading based on the document which
>  you pointed out. http://www.w3.org/2013/06/03-svg-minutes.html#item18
>  
>  In the meantime, the editor's draft of resource priorities was published.
>  http://www.w3.org/TR/resource-priorities/
>  
>  Since it had roughly aligned with the argument on previous our discussion, discussion
>  regarding that is going.
> 
> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePriorities_for_SVG
>  http://www.w3.org/2013/11/14-svg-minutes.html#item02
> 
> http://www.w3.org/Search/Mail/Public/search?type-index=public-web-perf&index-type=t&
>     keywords=svg&search=Search
>  
>  I have not made reference about 'switch' element because our use case was
>  not only choosing only one resource in them. Our use case is being able to
>  choose some of divided fragments of graphics based on the conditions by
>  zooming and panning.
>  http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0087.html
>  It is like introducing it to this page.
>  http://www.microsoft.com/web/solutions/zoomit.aspx
>  The source code by SVG may be such a thing.
>  http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0103.html
>  I wonder that it is a superordinate concept that were examined as
>  responsive/adaptive images until now.
>  
>  Regards,
>  
>  Satoru
>  

>  
 >>
 >>
 >> That sounds like a nice idea! Also, it would be nice to have a way to
 >> control loading of media so that those image and video elements which are
 >> not displayed are not fetched. I believe the current browsers fetch all
 >> even if they are not displayed.
 >>
 >> <switch>
 >>   <!-- some way not to load big.png if small.png is displayed would be nice
 >> for mobile phones -->
 >>   <image xlink:href="big.png" media="screen and (max-width: 10em)"/>
 >>   <image xlink:href="small.png"/>
 >> </switch>
 >>
 >> This section doesn't mention the poor switch element at all:
 >> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_Like_Syntax#5.10_Specifying_
>  whether_external_resources_are_required_for_proper_rendering
 >>
 >> Cheers,
 >> Kari
 >>
 >>
 >>
 >> 2014-03-06 17:25 GMT+02:00 Manuel Strehl <svg@manuel-strehl.de>:
 >>
 >> > Ah, the correct link to Robin's presentation:
 >> >
 >> > http://berjon.com/presentations/20130910-ricg-switch/
 >> >
 >> > Thanks, David, for pointing it out!
 >> >
 >> > Manuel
 >> >
 >> > Am 6.3.2014 11:15, schrieb Manuel Strehl:
 >> >
 >> >  Hi,
 >> >>
 >> >> recently several posts and tutorials sing the song of "responsive
 >> >> SVG", e.g. Clown Car,
 >> >> <http://coding.smashingmagazine.com/2013/06/02/clown-car-technique-
 >> >> solving-for-adaptive-images-in-responsive-web-design/>,
 >> >> Responsive Icons, <http://responsiveicons.co.uk/> or more recently,
 >> >> <http://coding.smashingmagazine.com/2014/03/05/rethinking-responsive-svg/
 >> >> >.
 >> >>
 >> >> In all these articles some combination of CSS media queries and JS are
 >> >> leveraged. The humble <switch> element is never even mentioned. And
 >> >> that's because it's useless here. I've found this brainstorming:
 >> >>
 >> >> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IFrame_
 >> >> Like_Syntax#5.9.2_The_.27switch.27_element
 >> >>
 >> >> and this presentation from Robin Berjon:
 >> >>
 >> >> http://coding.smashingmagazine.com/2014/03/05/rethinking-responsive-svg/
 >> >>
 >> >> where a "media" attribute is mentioned, and I'd like to ask, if there
 >> >> are any ongoing discussions towards adding it. It may be useful inside
 >> >> a <switch> element to complete requiredFeature and requiredExtension
 >> >> and mirror <video> in HTML, or even stand-alone, on arbitrary
 >> >> rendering elements.
 >> >>
 >> >> The advantage is straight-forward in-markup ways to declare, which
 >> >> parts of the image to render, and which to discard in some viewing
 >> >> circumstances. Since evaluation of media queries is already
 >> >> implemented in browsers and the result is basically a simple "display
 >> >> full"/"display none" switch, I'd suspect implementations to be not
 >> >> completely insanely hard.
 >> >>
 >> >> Reference SVG of what I'm talking about:
 >> >>
 >> >> <svg>
 >> >>
 >> >>   <!-- inside switch element: -->
 >> >>   <switch>
 >> >>     <rect media="screen and (max-width: 1em)"/>
 >> >>     <rect media="print" />
 >> >>   </switch>
 >> >>
 >> >>   <!-- or standalone: -->
 >> >>   <rect media="print" />
 >> >>
 >> >> </svg>
 >> >>
 >> >> Cheers,
 >> >> Manuel
 >> >>
 >> >
 >> >
 >>
 >>
 >>
 >>
>  
>  

>  




-- 
Best regards,
 Chris                            mailto:chris@w3.org
Received on Friday, 14 March 2014 17:05:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:51 UTC