Tweak viewport meta warning #607
Conversation
| <p>Developers should not use the <code>user-scalable=no</code> or <code>maximum-scale=1.0</code> | ||
| values in the <code>content</code> attribute as their use hinders users' ability to zoom the | ||
| content to a size that is legible for their needs.</p> | ||
| <p><a href="https://www.w3.org/TR/css-device-adapt-1/#viewport-meta"><code><meta name="viewport" content="..."></code></a> allows authors to define specific viewport characteristics (such as the layout viewport's width and zoom factor) for their documents. Among these is the ability to prevent or restrict users from being able to zoom, using <code>content</code> values such as <code>user-scalable=no</code> or <code>maximum-scale=1.0</code>. Suppressing or limiting the ability of users to resize a document is an accessibility and usability issue, and should be avoided.</p> |
There was a problem hiding this comment.
can you put in some line breaks please :)
There was a problem hiding this comment.
sigh...fair enough ;)
| display a warning if developers use these values.</p> | ||
|
|
||
| <p>There may be specific use cases where preventing users from zooming may be appropriate, such as map applications (where custom zoom functionality is handled via scripting) or games (designed specifically for a fixed viewport). However, in general this practice should be avoided, and HTML conformance checking tools should display a warning if they encounter these values.</p> | ||
|
|
There was a problem hiding this comment.
What I said before. Design for a fixed viewport is too broad a statement IMHO.
Where there is a zoom mechanism, handled by the application - as in the map example - there is a clear use case. Can you explain the game case more clearly?
There was a problem hiding this comment.
dropped that bit, as i agree. it's not EASY, but games CAN be made to work when zoomed
|
I also fixed the IPR thing. |
|
force-pushed a new version with the fixes, @chaals |
| allows authors to define specific viewport characteristics (such as the layout viewport's width and zoom factor) | ||
| for their documents. Among these is the ability to prevent or restrict users from being able to zoom, using | ||
| <code>content</code> values such as <code>user-scalable=no</code> or <code>maximum-scale=1.0</code>. Suppressing | ||
| or limiting the ability of users to resize a document is an accessibility and usability issue, and should be avoided.</p> |
There was a problem hiding this comment.
Hmm. s/is an accessibility/causes accessibility/ ...
|
|
||
| <p>Note that most user agents now include options/settings that allow users to always zoom, regardless of any | ||
| <code><meta name="viewport" content="..."></code> restrictions, and certain browsers have already started to | ||
| simply ignore these values altogether.</p> |
There was a problem hiding this comment.
You could simplify this: Note that most user agents allow users to zoom, regardless of ... However this sometimes involves configuration settings that some users may not find.
| @@ -823,9 +823,11 @@ | |||
|
|
|||
| <div class="warning"> | |||
|
|
|||
| <p>Developers should not use the <code>user-scalable=no</code> or <code>maximum-scale=1.0</code> | |||
There was a problem hiding this comment.
This deletion removes the normative "should not" needs to be worked into updated prose.
- introduce the actual name="viewport" meta, as this only applies in this specific case - link to CSS device adaptation, currently still the only "official" (non-Apple) doc where this is documented - expand/rewrite advice - include note about UAs ignoring these values (either with an opt-in setting or outright)
|
more force-pushing to address @stevefaulkner and @chaals concerns/suggestions, hopefully... |
- introduce the actual name="viewport" meta, as this only applies in this specific case - link to CSS device adaptation, currently still the only "official" (non-Apple) doc where this is documented - expand/rewrite advice - include note about UAs ignoring these values (either with an opt-in setting or outright) thanks @patrickhlauke and @chaals for review
this specific case
(non-Apple) doc where this is documented
setting or outright)