[css-device-adapt] Remove @viewport

[smfr]

https://www.w3.org/TR/css-device-adapt-1/#atviewport-rule

The @Viewport rule in this spec has not gained traction. I propose that we remove it, and use the spec to simply define the <meta name="viewport"> tag.

[smfr]

Issue #258 has some relevant discussion. If browsers are unwilling to implement, then there's no point keeping @Viewport around. Punting it to the next level just kicks the can down the road.

[frivoal]

I like @viewport, but I cannot disagree about its lack of traction. In fact, it's lost traction: it used to ship in Opera and IE, but with the demise of those as standalone engines, it's no longer in any modern browser. That makes me sad, but it's nonetheless true.

Also, the viewport meta needs a spec.

Also, we recently discussed specifying the definitions of layout viewport and visual viewport, and temporarily agreed that they could go in cssom-view, but there was some reluctance about that due to the fact that not all implementations that care about the viewport have an OM, so the coupling felt wrong.

With all that in mind, moving the definitions of the viewports here, defining the viewport meta alongside, and removing the rest seems sensible to me.

There are a number of useful things that @viewport does/did that the meta viewport doesn't do, so it would probably be good to set up an explainer somewhere to preserve those, in the hope that we'll get back to this some day, but the current state of affairs doesn't help anyone.

[css-meeting-bot]

The CSS Working Group just discussed [css-device-adapt] Remove @viewport, and agreed to the following:

• RESOLVED: Remove @viewport, retire the spec, move the meta tag to a new spec (CSS Viewport)
• RESOLVED: Move layout visual viewport spec into CSS Viewport spec

The full IRC log of that discussion

<dael> Topic: [css-device-adapt] Remove @Viewport
<dael> github: https://github.com//issues/4766
<dael> smfr: Since @Viewport hasn't tracktion on shipping browsers I propose we remove and just spec the metatag which has wide support
<dael> TabAtkins: Support
<dael> florian: Yeah, I'm editor. I like @Viewport but I can't disagree. It doesn't have traction
<dael> florian: Related; we resolved to define the viewports and CSSOM View as the host. If device adaptation doesn't contain @Viewport this is a good host for them. Should we move
<dael> smfr: Don't agree b/c spec of layout and visual viewports is about layout, not about adapting to devices. That's why i think like elsewhere. This is right for tap highlight color or things only for devices.
<dael> florian: Why I'm not happy with them in CSSOM View is not all things care about viewports have OM. Where else it should live, this felt okay. i can live elsewhere. I don't feel OM view is a better home
<dael> smfr: I think OM View is a bad name for a spec.
<dael> fantasai: I agree with them in device adaptation. Less convinced with things that are touch specific. It's fundimental to a lot of devices and I think it goes in UI. But I agree with dropping @Viewport and shifting meta viewport into device adaptation
<dael> florian: If device adaptation name is the problem we can retire as a note and have a new spec called viewports
<dael> smfr: That would be fine. If layout and viewport is moved to another spec I should be editor on that.
<dael> smfr: Layout and visual viewport will tie into scrolling and coord system for getBoundingClientRect. That's why I think more closely with OM View
<dael> florian: A bunch need to refer to them but that's not defining what they are
<dael> Rossen_: We are moving away from original topic. Given that we don't have layout and viewports spec yet we can decide where to host once we have spec text closer.
<dael> Rossen_: Back to original proposal to remove @Viewport. I didn't hear any challenges and I hear support.
<dael> Rossen_: Obj to removing @Viewport?
<dael> florian: Don't object. Suggest we retire spec
<dael> smfr: Need live spec for meta viewport
<dael> florian: Yeah, cal it viewport spec
<dael> tantek: Drop from lack of impl interest?
<dael> many: yes
<dael> florian: Proposed by Opera, drop by MS, and then both companies switched engines and Google had concerns
<florian> s/drop by MS/adopted by MS/
<dael> Rossen_: And we didn't have any use of it. Adding it didn't add to capabilities we had. No one has asked for it after we decided to move on to Blink platform
<tantek> Gecko BTW: https://bugzilla.mozilla.org/show_bug.cgi?id=747754
<dael> tantek: Checking Mozilla bug ^
<dael> Rossen_: tantek are you trying to push back on resolution?
<florian> s/switched engines/switched to engines that lack that feature/
<dael> tantek: I read GH and hearing reasoning from absense of evidence. I wanted to site relevent Gecko bugs and I guess Blink.
<dael> florian: Google has objected to it
<smfr> https://github.com//issues/258
<dael> tantek: I didn't see that in the bug. It wasn't linked. That's a strong claim so I'd like a link
<dael> smfr: There's a link to ^ from Google saying @Viewport is loader hostile
<dael> florian: That'st he one
<dael> tantek: They think it's bad idea
<dael> smfr: And WK agrees
<dael> tantek: So it's bad design not neglect?
<dael> florian: Both.
<dael> tantek: Can't be both
<dael> Rossen_: Let's try to resolve on this. tantek do you object to the resolution? If you object let's record it and move on.
<dael> tantek: I can't find a reason to object
<dael> RESOLVED: Remove @Viewport, retire the spec, move the meta tag to a new spec (CSS Viewport)
<dael> florian: And make smfr an editor of that
<dael> smfr: Okay with that
<dael> smfr: Also okay with layout and visual viewports being in this new spec
<dbaron> I'm not sure what I think about the objection of being preloader-hostile -- I think many good features may not fit nicely with preloading but that doesn't mean we shouldn't do them for other reasons.
<dael> Rossen_: Prop: Move layout visual viewport spec into CSS Viewport Spec
<dael> RESOLVED: Move layout visual viewport spec into CSS Viewport spec
<dael> smfr: Viewport or Viewports?
<smfr> “viewport” or “viewports”?
<dael> TabAtkins: Prefer singular. Maybe only have one plural in backgrounds
<dael> smfr: Fine
<fantasai> +1 to css-viewport
<dael> Rossen_: Let's stick singular for now

[TalbotG]

• RESOLVED: Remove @Viewport, retire the spec,
  move the meta tag to a new spec (CSS Viewport)

There are 2 tests specifically testing @Viewport :
http://wpt.live/css/css-values/vh-support-atviewport.html
http://wpt.live/css/css-device-adapt/idlharness.html
Should we remove such tests?

[smfr]

Yes.

[karlcow]

@RByers is there an intent to unship this?
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/resolver/viewport_style_resolver.cc?l=85-113&rcl=7e6122a30da5d3a0ffded6610e526934c0fa21b7

[astearns]

My assumptions on what we need to do with publishing and process for all of this

• Create an ED of css-viewport
• Get a resolution on FWPD of css-viewport
• Get a resolution on publishing css-device-adaptation as a NOTE

I think it would be best if the publishing all happened at once, with something in the NOTE version of css-device-adaptation pointing to the new module.

[ddbeck]

Hi folks! Do you still plan to remove @viewport from the spec? I'd like to update the compatibility data on MDN to reflect the state of this feature. Having it definitively removed or knowing that it's unlikely to happen soon would be helpful for that. Thank you!

[Malvoz]

@ddbeck per #4766 (comment):

RESOLVED: Remove @viewport, retire the spec, move the meta tag to a new spec (CSS Viewport)

[karlcow]

My assumptions on what we need to do with publishing and process for all of this

* Create an ED of css-viewport

@astearns do you know if it has been started?

[astearns]

I expect not. @smfr, am I wrong?

[smfr]

I have an early draft which I have not pushed yet.

[Zhang-Junzhi]

There are a number of useful things that @viewport does/did that the meta viewport doesn't do, so it would probably be good to set up an explainer somewhere to preserve those, in the hope that we'll get back to this some day, but the current state of affairs doesn't help anyone.

I also hope so. meta viewport doesn't make much sense. Letting HTML tags care about layout doesn't meet the fundamental principle of HTML. This should return to CSS someday.

Is there any plan to make a similar feature come back to CSS in the near future?

[IS4Code]

I have a number of pages, some auto-generated and with limited control of their actual layout or the tags, but I have control of the CSS that is applied to them all. A meta tag is the worst place where something that seems to fix displaying these pages on a phone should be placed. It is the style that controls whether a page is optimized for phones, not the content.

[softwaredevkev]

Not sure if this is the best place to ask, but I figured I'd give it a go. What got me here initially was wondering how the element <meta name="viewport" content="width=device-width; initial-scale=1.0"> was being processed. That lead me to the CSS Device Adaptation page.

It is my understanding that the browser then parses this line and translates it into an @viewport rule and then inserts it into the DOM as if it were in a <style> element. I was then shocked to find out this CSS rule is deprecated, leading to another question and why I'm here. My question is if the @viewport rule is deprecated, then how can the <meta name="viewport" content="width=device-width; initial-scale=1.0"> HTML tag still work?

Keep in mind, I'm extremely new to the field of web development and so I don't yet understand how things happen "under-the-hood" so to speak. Please be gentle. Thank you.

[karlcow]

@kevinwr On Firefox side some of your questions are here.

https://searchfox.org/mozilla-central/rev/6b099d836c882bc155d2ef285e0ad0ab9f5038f6/dom/base/nsViewportInfo.h
https://searchfox.org/mozilla-central/rev/6b099d836c882bc155d2ef285e0ad0ab9f5038f6/dom/base/Document.cpp#9909

@smfr is the person who may have the start of a draft but it's not public yet for how it is working.
#4766 (comment)

[jmi2k]

I agree with @Zhang-Junzhi and @IllidanS4. The meta tag is an style element, it should be inside CSS somehow. Having it in HTML is an ugly hack, and removing it from CSS just because browsers don't want to implement sounds like a fairly weak argument. Standards are there precisely to guide implementations towards correct, sound solutions.

tl;dr: get rid of that meta tag for setting up the viewport, gives us a CSS solution instead

[ByteEater-pl]

I'm not sure if the comment I made on #331 would be better placed here. Anyway, linking to let people discussing and reading here know.