Re: Media queries in <switch> elements

Thanks, it did clarify things. It makes sense that the non-rendered
elements are treated as if the display property were set to none.

- Kari




2014-03-14 19:05 GMT+02:00 Chris Lilley <chris@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
>
>