747754 - (@viewport) Implement @viewport at-rule

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, enhancement)

Description

[Florian Bender]

iOS Safari introduced <meta> viewport for influencing how Websites are rendered on mobile devices. However, the design of <meta> viewport is flawed (not solely by handling this via a HTML tag instead of CSS) and implementations across different platforms differ (see e. g. device-width and landscape mode). 

The Opera Dev Team designed a CSS replacement for the <meta> viewport tag including how to handle the <meta> viewport tag when CSS Device Adaption is implemented by an engine. See W3C editor's draft: http://dev.w3.org/csswg/css-device-adapt/

Opera Mobile and IE10 already implemented the proposal (with vendor prefixes). 

Especially for Fennec, but also possibly Fx, this proposal is very helpful, as it also defines how to handle a <meta> viewport tag and clarifies features resp. provides more flexibility than iOS's solution. 

Please implement it (with vendor prefix, as the proposal hasn't matured yet).

Comment 1

[Florian Bender]

Opera Post: http://www.opera.com/docs/specs/presto28/css/viewportdeviceadaptation/
MSDN Post: http://msdn.microsoft.com/library/ie/hh708740.aspx

Comment 3

[Anthony Ricaud (:rik)]

WebKit is also working on an implementation: https://bugs.webkit.org/show_bug.cgi?id=95959

Comment 4

[Peter Gasston]

Already implemented in WebKit now: https://bugs.webkit.org/show_bug.cgi?id=95961

Comment 5

[Peter Gasston]

Sorry, meant that the @viewport rule is implemented, not the whole module.

Comment 6

[Florian Bender]

The Chromium Bug is crbug.com/155477 – Moz could be the last one to implement this.

Comment 7

[Florian Bender]

This has since been implemented behind a runtime flag in Chrome. IE10 has a prefixed implementation. Don't know if Opera has this enabled after switching to Blink, or they regressed. Either way, Gecko is indeed the last big engine that has no implementation of @viewport.

Comment 8

[Jonny Barnes]

Has this been implemented yet?

Comment 9

[Matt Brubeck (:mbrubeck)]

(In reply to Jonny Barnes from comment #8)
> Has this been implemented yet?

No. When this is implemented, then this bug's status will be changed from NEW to RESOLVED.

Comment 10

[Karl Dubost💡 :karlcow]

As of today
http://caniuse.com/#feat=css-deviceadaptation

* IE11 and Edge with -ms- prefix
* Opera Mini with -o- prefix
* Still behind a flag for Chrome.

Comment 11

[Florian Bender]

Removing parity-webkit since the implementation seems to have been abandoned after Google forked to Blink.

Comment 12

[Ghostbird]

I'd love to see this too. I recently ran into the issue where my web-page just looked horrible on a 4k(UHD actuall) resolution, without any good solution.
If I had been able to reliably use @viewport{max-width:1980px} I could've just zoomed the page and retained the same view as on an HD screen. There just wasn't enough content to fill a 4K screen.
Maybe there's another solution, but the viewport CSS rule seemed like the proper way to do this.

Comment 13

[Sebastian Zartner [:sebo]]

I've adjusted the summary to reflect what this is actually asking for and in regard of the newly created tracking bug 1354483.

Sebastian

Comment 14

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 15

[Gérard Talbot]

An edge test with @viewport {width: 50vw;}
http://w3c-test.org/css/css-values/vh-support-atviewport.html

Expected result:
http://w3c-test.org/css/css-values/reference/vh-support-atviewport-ref.htm

Comment 16

[Hiroyuki Ikezoe (:hiro)]

I did a brief chat with Karl on IRC, he told me that he has not seen any webcompat issues caused by @viewport rule (probably that's because Chrome has implemented it but pref-ed off by default). Also he suggested that we can implement @viewport rule with a pref offed by default and ship it when Chrome ships. That sounds a reasonable plan to me. :) With this plan, we can fix bug 1552713 with the same manner what Chrome does (see bug 1552713 comment 2).

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Wait, it's not clear to me why @viewport is needed to fix that bug. That seems just to override the min-ratio, why can't it be done directly in C++?

Comment 18

[Hiroyuki Ikezoe (:hiro)]

We can of course do it in C++, but it requires a ifdef block or a platform check.

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Or a pref, y'know ;)

We'd need the same to inject the viewport stylesheets (or to enable / disable @viewport), right? (That's what Blink does with the document->GetSettings() bits here).

I didn't want to imply that @viewport is not worth implementing, just that it's probably not worth it to block fixing that bug on implementing @viewport.

Comment 20

[Hiroyuki Ikezoe (:hiro)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #19)

Or a pref, y'know ;)

We'd need the same to inject the viewport stylesheets (or to enable / disable @viewport), right? (That's what Blink does with the document->GetSettings() bits here).

I didn't notice it, that's good to know. (there is another style sheet for television)

I didn't want to imply that @viewport is not worth implementing, just that it's probably not worth it to block fixing that bug on implementing @viewport.

Yeah, anyways, I am now open about how to fix bug1552713 (I didn't block the bug on it) so I'd wait for the webcompat triage on that bug, as of now there is only one issue so we don't need to rush to fix it probably.

Comment 21

[Tantek Çelik]

FYI CSS WG just resolved to drop "@viewport" (see https://github.com/w3c/csswg-drafts/issues/4766), no shipping engine implements it, and Blink apparently objects (thinks it's a bad idea) per https://github.com/w3c/csswg-drafts/issues/258.

Unless we care strongly (and think @viewport is a good design, which I highly doubt given the preloader-hostile conclusion in 258), we should WONTFIX this.

If you want to help better solve the problem that @viewport was supposed to solve (but never did), please contribute to:
https://github.com/w3c/csswg-drafts/issues/326
https://github.com/w3c/csswg-drafts/issues/331
Thanks.

Comment 22

[Hiroyuki Ikezoe (:hiro)]

I don't object to drop it.

I actually prefer @viewport in some ways, it has cascading rules. Whereas in the case of meta viewport it's super unclear if there are multiple meta viewport tags.

I am going to mark this as INVALID.