Re: Controlling content based on resolution

On Tue, Aug 19, 2014 at 9:36 PM, Paul LeBeau <paul.lebeau@gmail.com> wrote:
> 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'?

Not sure precisely what you mean by "rendering to a 32x32 bitmap", but
if you mean something like "render into a 32x32 <img> element" or
maybe a 32x32 favicon, then those dimensions *should* be reflected by
the width and height MQs.

Don't worry about device-width/height, those are broken and dumb.

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

If by "image bitmap width" you mean the dimensions of the <img>, yes.
The <img> establishes a sub-document that gets its own viewport, with
a size equal to the element's size.

> Either way, would it not be desirable to find some mechanism by which SVG
> can support the vector icons use case better?

Using MQs to show/hide vector or <image> in your SVG seems to do that, no?

~TJ

Received on Wednesday, 20 August 2014 07:24:09 UTC