Re: [csswg-drafts] [css-device-adapt] @viewport is preloader-hostile

> If the argument is that UAs should be able to handle overflow in 
whatever way they want, they're already empowered to do so. That's how
 mobile browsers shipped in the first place, choosing to zoom out 
oversized desktop sites instead of showing a scrollbar.

I don't buy that. Browsers can handle overflow anyway they want, but 
overflowing is not the only negative effect of a viewport that's too 
small. Overlapping content or elements being squeezed too much happen 
as well. I don't care about the syntax all that much (other than the 
fact that this is presentation and should be somewhere in CSS), but 
the ability to say "don't squeeze the content below this size, and 
provide an appropriate UI if the window/screen's too small" is 
important.

We haven't missed it too much so far, because responsive has mostly 
meant going down to 320px. But:
- The most popular phones now are more than 320px across
- Things smaller than phones, like smartwatches, are emerging

This means that I expect the long term trend to be an increase in the 
number of sites which are responsive enough to deal with small/mobile 
devices with dominant marketshare (and anything larger), but not 
responsive enough to deal with all devices out there.

> data shows the number of sites using fixed widths is shrinking 
anyway -- I don't think it's wise to over-optimize for a dying trend.

I agree that fixed-size sites are going down, and I am only interested
 in specifying a width when it is a min-width, (or when it is used in 
combination with @media (max-width), which boils down to the same 
thing).

No website is responsible all the way to width=1px. Device sizes vary,
 and I doubt that the area of the most popular device being the 
smallest device (iPhone) is ever coming back. So, if you combine these
 two facts, we need some way to indicate how small the viewport can 
get before the layout becomes broken, so that UAs that have a smaller 
screen/window can cope.

I think I'd be perfectly happy to drop the fixed width part of 
`@viewport`, and reduce the featureset to:
`@viewport-min-width: <length>;` (or rather some writing-modes aware 
equivalent).

Mobile UAs would have `@viewport-min-width: 980px;`, and you'd be free
 to set it to `@viewport-min-width: 320px;` or `@viewport-min-width: 
375px;` or `@viewport-min-width: 25em;` or whatever makes sense for 
your design.

Maybe we need it in both dimensions, but if we do it logically rather 
than physically, I am not even sure about that.

I think this would be more robust than what we currently have with 
regards to progressive adoption by different classes of browsers. 
Unlike `@viewport {width:...;}` which needs to be supported from day 
one on mobile and desktop lest sites start relying on it only applying
 to mobile, we wouldn't have that problem, and adding support for this
 in a desktop browser even if most sites didn't expect it wouldn't 
break anything.

As for the preloader, being strict that this has to be at the top of 
the stylesheet like `@import` or `@charset`, maybe even with the 
restriction that it must either be inline in `<head>`, or in 
stylesheets directly linked from the document, and not in recursively 
`@import`ed stylesheets would be accetable restrictions if that'd 
help.

> I think it's important to have a declarative mechanism for disabling
 user scaling rather than preventDefaulting input events for 
performance reasons. But I don't think it has to be tied to the 
feature that controls layout dimensions. And I don't think it's 
important for this part of the feature to be preloader-friendly if its
 only effect is to control user interaction after the page has 
completed loading. So while I think we need to retain this 
functionality in some feature, I'd actually prefer it be split out 
from layout dimension control.

Sounds reasonable to me.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/258#issuecomment-231954237 
using your GitHub account

Received on Tuesday, 12 July 2016 07:00:55 UTC