Open ChumpChief opened 8 years ago
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.
Two points:
~fantasai
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.
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.
Would that be https://github.com/WICG/ViewportAPI, or should it be a spec on which that builds?
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.
CSSOM View sounds reasonable, yeah. @zcorpan, WDYT?
There are some high level concepts in @viewport
that are think are worth it:
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.
So what's the best destination for meta viewport?
@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).
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
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:
- 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
- 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:
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 :).
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.
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.
Note:
When there are multiple meta viewport
instances:
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.
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.
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.