Use the viewport meta tag instead of a CSS property

[majido]

Olli, @smaug----, suggested that we should perhaps spec this as a new attribute in the viewport meta tag.

Why viewport meta tag isn't used? It is mentioned in the proposal but then "A CSS, or Javascript based solution is preferable to meta tags." without no explanation. viewport meta tag is after all currently the way to control viewport, and here the idea is to affect to the default handling of viewport. Very similar to 'user-scalable' of viewport tag.

[majido]

Originally I preferred a CSS property over a viewport meta due to the following:

1. Although the current proposal's scope is limited to viewport use-cases (i.e., navigation), it is not hard to imagine potential use-cases for inner scrollables (disabling bounce effects etc.). A css attribute may later be extended for use with all scrollables but viewport meta tag is specific to viewport.
2. Viewport meta tag seems to be rather underspecified and not consistently supported across browsers. So it was not clear to me if it is a good idea to add more logic to it.

(1) is non-critical hypothetical use-case and (2) seems to being covered by css-device-adapt more or less. So neither objections is blocking. So perhaps we should consider to make this a viewport meta instead of a CSS attribute.

[majido]

@rune-opera @frivoal : does something like the proposed overscroll-action is a good fit for viewport meta and CSS Device Adaptation spec? We like to implement something of the sort in Blink whether it is a new css attribute or a viewport meta.

/cc @RByers who had some concerns about @Viewport needing a major overhaul.

[smaug----]

Viewport meta tag seems to be rather underspecified and not consistently supported across browsers. So it was not clear to me if it is a good idea to add more logic to it.

Is really not an argument at all. The new proposal is totally un-supported by all the browsers, and not well specified either. I'd rather fix the existing stuff than add new stuff to the already complicated platform.

[bradkemper]

HTML coding and CSS coding is often done by separate teams, often with little or no control over each other. Often the HTML is made available by a vendor for their clients to style/brand, and one such client often has zero chance of changing the HTML.

What viewport does (currently as an HTML tag) is clearly presentation style. It should be in CSS.

Also, it is very often a logistical nightmare to try to change a tag on every single page of a large site, which may contain old legacy pages, pages done by different teams, third party sub-sites, etc. With one or two (or a few) style sheets though, it becomes a simple matter to make sweeping styling changes, and this is an important reason for viewport styling to be part of linked CSS style sheets.

[smaug----]

viewport behavior is not presentation style. It is way closer to event handling.

But anyhow, what I'd like to see here is to first reuse the existing viewport since that is rather commonly supported feature already, and then sort out the issues in https://drafts.csswg.org/css-device-adapt/ and let also CSS to control the behavior of viewport.

What I don't want is to invent something totally new for this kind of feature when the platform already has some very similar APIs elsewhere.

[majido]

The proposed overscroll-action is most similar to user-scalable property in the viewport meta (which is also present in the css-device-adapt) in the sense that it provides a directive to user agent on how to interpret a user action.

And similar to user-scalable this does not suffer from the preloader issue that is is a concern for other descriptors in css-adapt-api so it should be possible to have these both in the viewport meta tag and eventually in the @Viewport CSS property.