W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2016

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

From: alexelias via GitHub <sysbot+gh@w3.org>
Date: Thu, 07 Jul 2016 20:59:50 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-231205738-1467925188-sysbot+gh@w3.org>
The min-width semantics are indeed good, that's why Chrome for Android
 and iOS Safari already treat `meta width=` quite similarly to 
`@viewport min-width`.  I just tested this again on 
http://output.jsbin.com/dakihubara -- you can see on phones they zoom 
out to fit the entire image.  (If developers don't want that behavior,
 they can set `initial-scale=1`, as I mentioned above.)  The main 
difference is that `min-width: 0` is no-op, whereas `meta width=0` 
would break flexible layouts because mobile browsers also use the 
`width` value as the initial size in the absence of other constraints 
(whereas desktop browsers use the window size as initial size).

> And this works just as well on desktop to let you deal with small 
windows.

If you're suggesting that when a responsive site is in a floating 
window that the user resizes below the min-width, the browser should 
start zooming out to keep a complete fit, I disagree.  This would look
 jarring and silly -- it's too different from how windows normally 
react to resizing.  (If anyone did want this, JS polyfills using CSS 
transforms to achieve the same behavior should already to be out there
 somewhere.)

If you're suggesting min-width should act as a hard "wall" against 
resize and prevent the user from shrinking the floating window any 
further, I think this is infeasible in a tabbed browser (imagine 1 of 
20 tabs has this restriction), so that's the kind of powerful 
capability only suited to "webapp manifest" type things.

-- 
GitHub Notification of comment by alexelias
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/258#issuecomment-231205738 
using your GitHub account
Received on Thursday, 7 July 2016 20:59:58 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:00 UTC