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

> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, January 08, 2018 1:58 PM
> To: Alice Wonder <alice@domblogger.net>
> Cc: www-style list <www-style@w3.org>
> Subject: Re: CSS-4 and min|max-device-width
> 
> On Mon, Jan 8, 2018 at 12:31 PM, Alice Wonder <alice@domblogger.net>
> wrote:
> > On 01/08/2018 12:03 PM, Tab Atkins Jr. wrote:
> >> 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.

At risk of introducing a side-issue - I'll be happy to start a new thread if you'd prefer - pinch-zoom not reflowing is a bug to me. It makes many websites unusable for me on mobile because I find their fonts too small. Pinch-zoom without reflow adds sufficient cognitive load for me that when I have to scroll for each line in each paragraph in order to read the full line because it hasn't been reflowed, then I don't really grasp the content. So I wind up waiting to read long-form content until I'm at a desktop, which does reflow when I zoom.

I acknowledge that knowing the device dimensions doesn't help with this, but calling pinch-zoom reflow buggy is counter to what I would find good experience. That said, if browsers and CSS were to support the iPhone's Larger Text setting (under General > Accessibility), that would be a partial workaround (depending on how much larger the site made the type before flowing the text).

> >>> 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
> 
> That's quite a problem - it means that if the user has the window at a
> small size (or has used a lot of browser zoom, which amounts to the same
> thing), they'll continue getting a display that is *meant for* a much
> larger window.  The size of my monitor has no relation to how I want a
> web page to display; I *might* have the browser full-screen, or it might
> only take half of my screen, or I might use a large zoom, or both!  A
> layout based on my monitor size is only appropriate in the first
> situation, where it's indistinguishable from basing it on my window size
> anyway.
> 
> > 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 larger.
> >
> > 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.
> 
> Either the "tablet design" is based solely on the size of the screen -
> in which case you *should* give it to the desktop browser with a small
> or highly-zoomed window - or it's based on other factors, like the
> tablet being a touch device, which you should be detecting more directly
> with the (pointer) and (hover) queries, rather than trying to infer the
> device based on its size. There are "tablets" that are the size of
> desktop monitors, after all, and desktop monitors that are tablet-sized.
> 
> > 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?
> 
> It solves the problem, explained up above, of designers forgetting that
> not everyone uses their browser full-screen and at normal zoom, and of
> designers trying (incorrectly) to guess a device's capabilities from its
> screen size.
> 
> ~TJ

Hope this helps.
Charles Belov
Webmaster, Communications and Marketing
San Francisco Municipal Transportation Agency 
1 South Van Ness Avenue, 3rd Floor 
San Francisco, CA  94103
Email: charles.belov@sfmta.com 
Phone: 415.701.4388
www.sfmta.com 
 
Find us on: Facebook Twitter YouTube

Received on Monday, 8 January 2018 23:15:15 UTC