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

> My perspective on this is that the only truly useful feature of meta
 viewport is "width=device-width".

Mostly agree.  This solves the main problem of "Many browsers on 
phones/tablets have a magical default scaling behavior that I need to 
**disable** (not **control**) to make my responsive layout work".

I would love to believe that developers would do something like this 
-- IMO this would be a pretty reasonable use of fixed-width:

```
/* My layout is responsive down to 360px but breaks below that */
@viewport { width: device-width; }
@media (max-width: 360px) {
    @viewport { width: 360px; }
}
```

But in reality I think the usage for fixed-width is more likely to 
utilize server-side UA detection and cultivate non-responsive sites as
 @alexelias mentions.  And as @RByers 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.

So I'd be in favor of this feature being a simple "off" switch for 
magical browser scaling, at least for L1.

> user-scalable=no: arguably useful on desktop as well, although this 
can also be achieved by preventDefaulting input events (which use 
cases like maps which truly care about this are likely to do anyway).

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.

In Edge we have the -ms-content-zooming property which can disable 
touch zooming:

`html { -ms-content-zooming: none; }`

Or enable it for specific elements in the page:

```
.thing {
    overflow: auto;
    -ms-content-zooming: zoom;
}
```
https://jsfiddle.net/31x0gsum/

This feature certainly has its flaws, but the part I really like is 
that it treats zoomability as an element behavior rather than as a 
page-level meta tag.  Whether that's done through a separate CSS 
property like -ms-content-zooming, extensions to the overflow 
property, HTML attributes, etc. I have fewer opinions on, but I do 
think it's appropriate to provide control over zoomability that's 
as-granular as the already-existing control over scrollability with 
the overflow property.

I don't mean to derail this thread with discussion of how such a 
feature could/should work; just want to point out that we could 
support this functionality in other ways even if it's dropped from 
this feature, and that I would be in favor of that approach.

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

Received on Monday, 11 July 2016 17:42:03 UTC