- From: Paul LeBeau <paul.lebeau@gmail.com>
- Date: Wed, 20 Aug 2014 16:36:54 +1200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Jeremie Patonnier <jeremie.patonnier@gmail.com>, www-svg <www-svg@w3.org>
- Message-ID: <CACfsppA0iLz0uunK1-D9cfv0_3fmvP2zaUwoaW+m2r4m7gRBog@mail.gmail.com>
Tab wrote:
> Paul wrote:
> So my questions are:
>>
>> 1. Is it reasonable for a standalone (ie. non-browser) renderer to use
>> the output size of the SVG as the @media width/height determinant?
>
>No, setting width/height on the <svg> root is identical to setting it
>on the <html> root. It doesn't define an "output size", just an SVG
>viewport, and if you set overflow:visible, you can still render things
>outside of that rectangle.
By output size I meant the initial viewport. So, if I was rendering an SVG
icon to a 32x32 bitmap, would it be reasonable to treat the bitmap width as
the MQ 'device-width' and/or 'width'?
> No, MQs by design are evaluated before styles are, to avoid circular
dependencies.
Ok. Wasn't aware of that. What about SVGs loaded as <img src="foo.svg">?
In that situation the size of the viewport is determined before the SVG is
rendered, is it not? Would it be reasonable to treat the image bitmap
width as the MQ 'device-width' and/or 'width' then?
Either way, would it not be desirable to find some mechanism by which SVG
can support the vector icons use case better?
Paul
On 20 August 2014 08:35, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Aug 19, 2014 at 10:52 AM, Paul LeBeau <paul.lebeau@gmail.com>
> wrote:
> > Sorry if I haven't been clear so far. I am thinking about the two
> different
> > use cases:
> >
> > 1. SVG in a web page
> > 2. Standalone SVG used to define an application icon
> >
> > If, for example, I have an element in the icon that I want to appear
> only if
> > the final size of the icon is greater than 32x32.
> >
> > <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
> > <style type="text/css">
> > <![CDATA[
> > @media (max-height: 32px) {
> > .greater-than-32 {
> > display: none;
> > }
> > }
> > ]]>
> > </style>
> >
> > <circle cx="50" cy="50" r="40" fill="orange"/>
> > <rect x="50" y="50" width="40" height="40" fill="green"
> > class="greater-than-32"/>
> >
> > </svg>
> >
> > If you try this in a browser (Chrome and FF worked), the green rectangle
> > disappears when the browser window height drops below 32px. Ok good, but
> > this behaviour is dependent on the browser height.
>
> More specifically, it's based on the CSS viewport width/height. (This
> means that embedded documents such as <iframe>s or <img>s use their
> laid-out size as their viewport size.)
>
> > What if I want this
> > behaviour when I set the SVG to 16x16?:
> >
> > <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"
> width="16"
> > height="16">...</svg>
> >
> > If you try this, you'll see that the 16x16 SVG has the rectangle until
> the
> > window height drops below 32px.
>
> Yes, setting the size of the root element has no effect on the viewport's
> size.
>
> (Note, though, the mismatch between CSS's use of "viewport" and SVG's
> use of the same term. SVG uses it to refer to the coordinate space
> established by an <svg>.)
>
> > So my questions are:
> >
> > 1. Is it reasonable for a standalone (ie. non-browser) renderer to use
> > the output size of the SVG as the @media width/height determinant?
>
> No, setting width/height on the <svg> root is identical to setting it
> on the <html> root. It doesn't define an "output size", just an SVG
> viewport, and if you set overflow:visible, you can still render things
> outside of that rectangle.
>
> > 2. Should there be a way to specify svg height rather than browser
> window
> > height in an in-browser context? There is currently, 'height' and
> > 'device-height'. Is there a case for 'element-height'? Eg. @media
> > (max-element-height: 32px). I feel sure that web authors would love to
> have
> > the ability like this to control the way their web icons look based on
> how
> > they are used on the page.
>
> No, MQs by design are evaluated before styles are, to avoid circular
> dependencies.
>
> ~TJ
>
Received on Wednesday, 20 August 2014 04:37:41 UTC