[css-device-adapt] Should Device Adaptation include a normative definition of <meta> viewport?

[ChumpChief]

Spec: https://drafts.csswg.org/css-device-adapt/

The viewport tag is absolutely essential for correct rendering of any mobile content, yet is not normatively defined. Should it be? I think the answer is yes.

[frivoal]

Yes, the web totally depends on it, there is a lot of interoperability, it should be specified, and the css-device-adapt spec looks like a good place to do it. Even though the syntax of the viewport tag isn't CSS, what it affects is absolutely in scope, so that's good. That also lets us say what happens if you use both.

The current informative definition probably needs some extra scrutiny before we can simply turn it into being normative, but it's a decent start.

There's one thing I am not sure about: in #258 (and the follow up conversation that's should happen in #326 & #327), there have been questions that @Viewport shouldn't have nearly as many features than it currently does, and that maybe it needs to be parred down to only with:auto or min-width: <lenght>. The current definition of @Viewport is featurefull enough that we can express the viewport tag in terms of @Viewport. If we do the simplification, that will no longer be true though.

[fantasai]

Two points:

1. I think it should be the goal of @Viewport to fully replace the viewport
2. I totally agree we should define viewport in Device Adaptation. If you want a WG resolution to that effect, add
   Agenda+? :)

~fantasai

[foolip]

After the blink-dev Intent to Implement: @viewport it looks unlikely that @viewport will become implemented everywhere. @bokand @yoavweiss, would you agree?

What would be the best place to move the definition of https://drafts.csswg.org/css-device-adapt/#viewport-meta and making it normative? There are bugs about this in Gecko, and we need something to write tests against. @miketaylr FYI.

[bokand]

I would agree we're unlikely to ever ship it, given the perf concerns raised by Yoav.

I don't know where the remaining parts of the spec should go except that it should probably end up in the same spec as visualViewport spec and the layout/visual viewport once we spec those.

[foolip]

Would that be https://github.com/WICG/ViewportAPI, or should it be a spec on which that builds?

[bokand]

I think someone mentioned at one point it would probably make sense in CSSOM-View, but I don't really know how spec-land is devided so I don' treally have an opinion.

[foolip]

CSSOM View sounds reasonable, yeah. @zcorpan, WDYT?

[frivoal]

There are some high level concepts in @viewport that are think are worth it:

• This is about styling, interelated with layout, and should be in CSS
• It can express "this layout breaks down if the viewport is smaller than / larger than FOO"

Other than that, I like the current design, but wouldn't mind a complete overhaul of the design, if that helped address the concerns.

Either way, I think the CSSWG should indeed take step back, and think about the future of this module, because currently it does not seem to be on a good path.

[foolip]

So what's the best destination for meta viewport?

[frivoal]

@foolip hard to say before we decide the fate of that module. If it should survive, in this form or another one, this is the right place. if not, the I guess CSSOM View isn't too bad. Of we could gut this module of everything other than the meta viewport (which would make me sad, but you don't always get what you want).

[css-meeting-bot]

The Working Group just discussed Should Device Adaptation include a normative definition of <meta> viewport?, and agreed to the following resolutions:

• RESOLVED: Spec the <meta> viewport in CSSOM VIew

The full IRC log of that discussion

<dael> Topic: Should Device Adaptation include a normative definition of <meta> viewport?
<dael> github: https://github.com//issues/331
<dael> florian: The spec has a description of <meta. described in terms of the rest of the spec. People want a normative definition. Problem is the rest of the spec is not getting adoption. Do we expect that to be fixed or do we think this spec will die because it has some issues and gets pushback. If we think it'll never be adopted defining <meta> in terms of it is not useful.
<dael> florian: That's the question.
<dael> dbaron: one way to look at this is if you suppose there is a spec fo meta viewport and then you propose @Viewport that spec would have to define how meta-viewport works on top of it. You can looka t one possible answer is you should do both. device adapatation should define it in terms of how it works that's compat with the existing unwritten and that should be written.
<dael> florian: device adaptation was supposed to be written that way.
<dael> dbaron: And that's one theory of how things could work.
<dael> florian: So if we go by that it says there should be another spec and then device adapatation should continue existing as-is. IF we start from now rather then the past?
<dael> dbaron: Pretty much, I think.
<dael> florian: I think I can buy that.
<dael> florian: Who should write that? It's about layout so maybe CSS, but it's meta HTML so perhaps HTML. Which WG should own this.
<dael> florian: If it's us CSSOM VIew was suggested. Is it?
<dael> astearns: CSSOM VIew doesn't have a current editor.
<dael> astearns: There was a suggestion about an incubation doc.
<dael> florian: Incubation is supposed to be things we're not sure about. Spec needs to be written properly, but there's no wonder if people will buy into the idea.
<dael> astearns: I don't know how much there is about meta viewport. COuld it stand in its own module? Or better in CSSOM View?
<dael> florian: MOstly a who will edit question. If it's same person as CSSOM VIew easier together. If not, seperate.
<dael> astearns: Rossen it's an Edge person who brough tthis up COuld they edit it into CSSOM VIew?
<dael> Rossen: Sure, we can edit it in. I'll talk to MaRakow or fremy.
<dael> astearns: Obj to having this definition edited into css om view?
<dael> florian: I don't know if we need to resolve on spec if we find a person who wants to do it they can pick where it should go, cssom or seperate.
<dael> Rossen: The people I mentioned won't take over cssom, but they can do a PR. I didn't intend to indicate they would take cssom view
<bradk> Why not just add the meta spec to the device adaptation spec?
<dael> astearns: And a PR might be less work then spinning up a new module.
<dael> astearns: bradk asked [reads] it is in the device adapatation spec.
<dael> astearns: I guess the suggestion is just have the normative deifnition there.
<dael> florian: Google pushed back saying they don't want the entire spec to exist so putting things in there looks like an invitation to gut the rest and leave only that which brings us back to what dbaron suggested where they can co-exist.
<dael> astearns: I think there's value in seperating. It makes sense to put it in CSSOM view. That specs known things.
<dael> astearns: This fits in that bucket.
<bradk> I don’t object
<dael> RESOLVED: Spec the <meta> viewport in CSSOM VIew
<dael> astearns: Thanks everyone. We are not meeting next week, we will meet Jan 3rd.
<dael> astearns: Have a good break!
<bradk> Happy holidays!
<dael> Rossen: One more thing, I want to thank the WG for the very productive 2017. We did quite a bit of work and a whole bunch of specs are getting ready to REC and I'm looking forward to 2018. Thank you everyone for a super awesome year and happy olidays.
<dael> florian: THanks for awesome chairing

[domenic]

FWIW we try to keep all browser-affecting meta elements indexed in HTML; see https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names. That way we can also include document conformance requirements, and ensure that the processing stays consistent with others (e.g. it reacts to insertion into the document/removal from the document, but doesn't pierce shadow trees).

It probably makes sense for the CSSWG to own the actual viewport-related processing model, though. So to me it makes sense to have CSSOM View define that part, then have a smaller bit in HTML. Something like:

The value must be a [valid viewport string], which (does something useful).

If any meta elements are inserted into the document or removed from the document, or existing meta elements have their name or content attributes changed, run the following steps:

1. Let candidate elements be the list of all meta elements that meet the following criteria, in tree order:
   • The element is in a document tree.
   • The element has a name attribute, whose value is an ASCII case-insensitive match for viewport
   • The element has a content attribute, whose value is not the empty string
2. Run the [process meta viewports] algorithm given the list containing each of candidate element's content attribute values.

Here the []-delimited bits would be defined in CSSOM View, and the ()-delimited bit needs your help to describe.

Some notes:

• "valid viewport string" can be a strict what-we-want-authors-to-write definition, for HTML conformance checkers
• "process meta viewports" will need to do parsing (possibly more leniently than valid viewport string), and decide whether things that come first or last in the document have precedence, and whether you fall back to the lower-precedence one in the sequence if it's unparseable, or if you just give up and use the default... Lots of possibilities there.

We may also want to add a conformance requirement that you only include one meta viewport per document. Or maybe we want to allow multiple, if "process meta viewports" has a fallback mechanism, so you can e.g. use two and fallback in browsers that don't support one.

I'm happy to help with the HTML side of this BTW :).

[frivoal]

This makes sense to me, but I am afraid we'll have a resource problem to work on this: css-device adaptation has not had editorial attention for many years, and cssom-view is without an active editor for the moment.

I wouldn't mind working on this in theory, but I don't foresee being able to prioritize it any time soon.

[domenic]

It sounds like there may be some Edge folks willing to help? From the above:

<dael> florian: MOstly a who will edit question. If it's same person as CSSOM VIew easier together. If not, seperate.
<dael> astearns: Rossen it's an Edge person who brough tthis up COuld they edit it into CSSOM VIew?
<dael> Rossen: Sure, we can edit it in. I'll talk to MaRakow or fremy.

[karlcow]

Note:
When there are multiple meta viewport instances:

• Firefox merges them
• Chrome uses the latest one

[hiikezoe]

Note:
When there are multiple meta viewport instances:

* Firefox merges them

* Chrome uses the latest one

I should have commented here. Firefox now uses the last modified one which matches, I believe, Chrome's behavior. But the new behavior hasn't been available on stable mobile Firefox (i.e. Fennec), it will be available on the new mobile Firefox application called Fenix.

[ByteEater-pl]

To enable a CSS solution (perhaps a less powerful @viewport rule, to be extended if needed in future levels), which would be definitely better in terms of separation of concerns (it's styling after all, not document semantics) and applicable beyond HTML, as well as serve @bradkemper's use case (which is general and in my opinion important), I suggest specifying it anyway and adding some hints which user agents can heed to improve performance. Like an additional link relation indicating that the linked resource is likely to influence the viewport. Link relations can be used in HTML rel and rev attributes as well as in HTTP headers, in both directions (also with rel and rev parameters). Maybe even @viewport should be defined to do nothing in an external stylesheet if it doesn't have this link relation with the resource whose representation is styled.