Closed Bug 747754 (@viewport) Opened 8 years ago Closed 5 months ago

Implement @viewport at-rule

Categories

(Core :: CSS Parsing and Computation, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED INVALID
Webcompat Priority ?

People

(Reporter: fb+mozdev, Unassigned)

References

(Blocks 2 open bugs, )

Details

(4 keywords)

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).
Severity: normal → enhancement
Duplicate of this bug: 242646
WebKit is also working on an implementation: https://bugs.webkit.org/show_bug.cgi?id=95959
Depends on: 804584
Blocks: 804584
No longer depends on: 804584
Already implemented in WebKit now: https://bugs.webkit.org/show_bug.cgi?id=95961
Sorry, meant that the @viewport rule is implemented, not the whole module.
Keywords: dev-doc-needed
Blocks: 677989
The Chromium Bug is crbug.com/155477 – Moz could be the last one to implement this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [parity-IE], [parity-Opera] → [parity-IE] [parity-Opera] [parity-webkit]
See Also: → 845690
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.
Whiteboard: [parity-IE] [parity-Opera] [parity-webkit] → [parity-IE] [parity-Opera] [parity-webkit] [parity-blink]
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.
Removing parity-webkit since the implementation seems to have been abandoned after Google forked to Blink.
Whiteboard: [parity-IE] [parity-Opera] [parity-webkit] [parity-blink] → [parity-IE] [parity-Opera] [parity-blink]
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.
I've adjusted the summary to reflect what this is actually asking for and in regard of the newly created tracking bug 1354483.

Sebastian
Alias: @viewport
Summary: [CSS-WD] implement CSS Device Adaptation → Implement @viewport at-rule
Whiteboard: [parity-IE] [parity-Opera] [parity-blink] → [parity-blink][parity-IE][parity-presto opera]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-blink][parity-IE][parity-presto opera]
See Also: → 1552713
Webcompat Priority: --- → ?

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).

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++?

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

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.

(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.

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.

Flags: needinfo?(svoisen)
Flags: needinfo?(hikezoe.birchill)

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.

Status: NEW → RESOLVED
Closed: 5 months ago
Flags: needinfo?(svoisen)
Flags: needinfo?(hikezoe.birchill)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.