W3C home > Mailing lists > Public > www-style@w3.org > January 2018

Re: CSS-4 and min|max-device-width

From: Alice Wonder <alice@domblogger.net>
Date: Mon, 8 Jan 2018 12:31:08 -0800
To: www-style@w3.org
Message-ID: <c2bfcd93-9d7e-d4fd-58f7-903fa9cf51f9@domblogger.net>
On 01/08/2018 12:03 PM, Tab Atkins Jr. wrote:
> On Mon, Jan 8, 2018 at 9:38 AM, Levantovsky, Vladimir
> <Vladimir.Levantovsky@monotype.com> wrote:
>> On Sunday, January 07, 2018 6:20 AM Henrik Andersson wrote:
>>> To: Alice Wonder; www-style@w3.org
>>> Subject: Re: CSS-4 and min|max-device-width
>>> So to summarize, you actually want a media query that determinates the
>>> viewport width while ignoring zooming.
>>> Or in other words, you want the layout to remain locked down independently
>>> of the device zoom level.
>> I believe that having a media query that determines width while ignoring
>> zoom level would also be a useful feature for CSS4 font-variation-settings
>> property. If a website content is presented with a specific font variation
>> feature set based on a particular width, you wouldn’t want that setting to
>> be changing based on zoom level, and risk having the text content be
>> re-rendered and reflow because of it. People often zoom in to make text
>> easier to read, but you'd want to preserve the original layout at the same
>> time.
> Note the *very important* distinction between browser zoom (which
> affect the device-* queries) and pinch-zoom, which does not.

I'm sure that difference means a lot to the person who needs to press 
Ctrl-Plus to make the web page a little bigger in order to see something 
because their eyes are not as a good as the designer's eyes and they are 
not using a touch-screen that allows a pinch zoom.

> Browser-zoom actually changes the sizes of the units, and reduces the
> size of the viewport accordingly (so that its reported width, in the
> new, larger units, is exactly the actual width of the device).
> Pinch-zoom doesn't do any of this, it's more like a transform.

Browser zoom changes the pixel density, yes. You can see this by doing 
responsive images where you use the srcset to specify the pixel density.

> Browser-zoom already, almost by definition, causes reflows. Having
> text change as a result as well is completely fine.

Having some text flow changes isn't a problem. It's having layout 
changes because layout is based upon min|max-width queries instead of 
min|max-device-width queries that is a problem

  (Or if it's not,
> then what you actually want is to discriminate based on the resolution
> of the device, which is also available via MQ.)  Pinch-zoom never
> causes reflows (unless it's buggy), and text wouldn't change due to it
> either.
>> What problem does removing device-width media queries solve?
> Trying to infer the user's hardware, and that hardware's capabilities,
> from window size has always been a game you can't win.

Exactly why I want to query device-width and not viewport width.

device-width doesn't change when the viewport changes, except for when 
orientation also changes.

What I do is make a container div. On small device-width devices, like 
phones and tablets, that container uses 100% of viewport width.

On large devices - it doesn't use 100% of viewport width but instead a 
percentage of it, with a min-width and max-width set, usually centered 
vi auto left-margin

You can then make the CSS flow within a breakpoint so for example you 
use a particular layout for portrait orientation that is max-width-640px 
and a different for max-device-width 1024 pix and a different for even 

The user then pressing ctrl-plus to increase their pixel density and 
make things bigger still gets a fluid design but the layout doesn't 
switch to what is best for tablets because now their viewport is smaller.

device-width solves the problem of CSS pixels in the viewport being 
rather arbitrary, and now CSS4 wants to take that important solution away.

Why? What problem does it solve, and why can't designers that problem 
exists for just choose not to use it?
Received on Monday, 8 January 2018 20:31:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 8 January 2018 20:31:37 UTC