This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
<meta name="viewport" ...> is now implemented in multiple browsers, so it seems like it should be defined in the HTML(5) spec. I realize that process that led to <meta name="viewport" ...> being created was... less than ideal, and that it's also suboptimal as a means for addressing the use case it's designed for (and that doing it via CSS a la http://people.opera.com/rune/TR/css-viewport/ would probably be better), but the fact is that's it is now implemented in multiple browsers, and quite a lot of sites are using it, and the lack of a standard spec for it does not help to ensure interoperability of those sites.
IMHO it would be very unfortunate if this terrible design was immortalized in the HTML5 spec. <meta viewport> prevents serving same markup to all clients - layout changes can't be done with media queries and stylesheets alone. Hopefully it's still used only by small fraction of the web, mostly pages that were intended to be webkit-only and served to clients with "iP*" in their user-agent string. If anything, I'd prefer HTML5 spec to make <meta name=viewport> non-conforming and defer to the @viewport spec. AFAIK behaviors of <meta name=viewport> map closely to properties in @viewport, so the latter spec could be the place where <meta name=viewport> is documented (if that is really required).
What do you need besides what's already being done in the CSSWG? http://dev.w3.org/csswg/css-device-adapt/
For now, I've added name=viewport to the WHATWG Wiki MetaExtensions page: http://wiki.whatwg.org/wiki/MetaExtensions#viewport
(In reply to comment #1) > IMHO it would be very unfortunate if this terrible design was immortalized in > the HTML5 spec. > > <meta viewport> prevents serving same markup to all clients - layout changes > can't be done with media queries and stylesheets alone. To be clear, I don't personally like meta viewport either. I'm just trying to help figure out what (if anything) we should do for it as far as the HTML5 spec goes. > Hopefully it's still used only by small fraction of the web, mostly pages that > were intended to be webkit-only and served to clients with "iP*" in their > user-agent string. Whatever the original intent of the creators of the pages wast, I think meta viewport is now implemented in Fennec and Opera and mobile IE6 (and probably in mobile IE9 also). Whatever small fraction of the Web it may be used on now, the trend seems to be that use of it is going to increase, not decrease. > If anything, I'd prefer HTML5 spec to make <meta name=viewport> non-conforming > and defer to the @viewport spec. I guess another option (rather than mentioning it at all in the HTML5 spec) is to get it registered (status=Accepted) on the WHATWG Wiki MetaExtensions page. Which I think is what will happen if/when the "CSS Device Adaptation" spec ever actually gets published by the CSS working group and then proceeds to CR. But if really do want to discourage use of meta viewport, it should be listed in the "Non-conforming features" section of the spec: http://dev.w3.org/html5/spec/obsolete.html#non-conforming-features For one thing, that would be a signal to developers of conformance checkers of what their apps should report for documents containing meta viewport (e.g., emit an error message saying, "The 'viewport' value for the 'name' attribute on the meta element is obsolete; use CSS with a @viewport rule instead." (or whatever). > AFAIK behaviors of <meta name=viewport> map closely to properties in @viewport, > so the latter spec could be the place where <meta name=viewport> is documented > (if that is really required). I see now that it is documented in the "Viewport META element" section of the "CSS Device Adaptation" draft - http://dev.w3.org/csswg/css-device-adapt/
(In reply to comment #2) > What do you need besides what's already being done in the CSSWG? > > http://dev.w3.org/csswg/css-device-adapt/ Until you posted that link here, I wasn't aware that draft was available on dev.w3.org, or that the CSS WG had any intention of taking it up as a deliverable. But I see that spec is also now listed in the CSS WG draft charter - http://www.w3.org/2010/09/CSSWG/charter.html - so it's clear now that they do intend to move it forward. So I guess that since as far as the HTML5 spec goes, since it already provides a means for registering extensions to the set of predefined name values in the spec, the main other thing that needed doing was to register this one in the WHATWG Wiki MetaExtensions page, which I've now done. But going forward, if we do want to discourage Web developers from using meta viewport, and encouraging them to use CSS instead. it may make sense to mention it in the spec. I guess it would seem odd to list it in the "Non-conforming features" part of the spec -- since the intro paragraph for that section says, "Elements in the following list are entirely obsolete, and must not be used by authors", and meta viewport isn't really obsolete. But it would make more sense if that intro read, "Elements in the following list are either entirely obsolete or have never been valid in any version of HTML, and must not be used by authors".
(In reply to comment #5) > I guess > it would seem odd to list it in the "Non-conforming features" part of the spec > -- since the intro paragraph for that section says, "Elements in the following > list are entirely obsolete, and must not be used by authors", and meta viewport > isn't really obsolete. But it would make more sense if that intro read, > "Elements in the following list are either entirely obsolete or have never been > valid in any version of HTML, and must not be used by authors". There are already things in that section that have never been valid in any version of HTML, like (AFAIK) <bgsound>.
The design of <meta name="viewport" ...> is quite unfortunate compared to @viewport. However, authors will want to use <meta name="viewport" ...> to support already shipped versions of the Android default browser which are the new IE6 that's unlikely to be updated. Telling authors that this is invalid doesn't really help anyone. Once @viewport is ready for use (implemented in all browsers and not vendor-prefixed), its benefits over <meta name="viewport" ...> will be so obvious that it shouldn't need a validation *error* to advertise it.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Since we're not convinced the design of this value is that great, let's leave it in the wiki for now and figure out what to do with it when we revamp how we're handling registries.
Reopening. The design of <meta name=viewport> is bad compared to @viewport, but the reality is that it's now part of the platform that needs to be documented and that is currently getting implemented inconsistently (http://www.quirksmode.org/mobile/tableViewport.html#metaviewport) across browsers something that a spec could have prevented. I'm also curious about how "we" are going to revamp registries. I sure don't want to ask people to do busy-work in that area again.
mass-moved component to LC1
The "revamping" I was talking about is the idea of changing registries to a tentative registration place followed by the spec adopting the successful and discarding the failures. I don't think there's any busywork involved here (?). In the meantime, and indeed even after such a change, whether this is registered in the spec or in the registry the documentation will still have to occur in a CSS spec. It's impractical for the HTML spec to start defining things like the viewport and initial containing block dimensions. So I don't really know what you are expecting from the HTML spec here, if anything.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>. Status: Rejected Change Description: no spec change Rationale: http://dev.w3.org/csswg/css-device-adapt/ defines this and it is out of scope for HTML.