whatwg
Define <meta name=viewport>
Mostly filing this since folks might look for it here, given it isn't in the HTML Standard yet. This is mostly tracked by the CSS WG, who seem to lack resources to get this done. If anyone is interested in taking this on, dive in over at https://github.com/w3c/csswg-drafts/issues/331.
@annevk Is this still the case?
I see https://drafts.csswg.org/css-viewport/#viewport-meta exists.
Allowing sites to use system font size what discussed to be part of <meta viewport>. Per a discussion about 2.5 years ago:
Resolution from the F2F was to have a an opt-in switch for the web authors to get the true user font size, even on small screen device... Ideally the opt-in could be phased out over time if/when the Web handled scalability better. General consensus was that this should be an addition to
<meta viewport>
Originally posted by @cookiecrook in https://github.com/w3c/csswg-drafts/issues/3708#issuecomment-532113043
I would like to continue tracking the font accessibility issue with PWA/Home Screen apps and hopefully find a resolution for Android users (Apple/Webkit has -apple-system-body).
I don't see "viewport" defined at https://html.spec.whatwg.org/#standard-metadata-names so this still seems like a problem, yes. (Note that it's a value of name, not its own attribute.)
(There is one mention under "speculative fetch" that should be turned into an xref as part of adding this.)
@clshortfuse, WebKit/Safari resolution was not to rely on -apple-system-body... Continue reading in the same thread:
@ cookiecrook wrote:
The end solution was not the old -apple-system value, which is not widely used.
The solution was that Safari added a site-specific font size control that adjusts the font for any web text, regardless of how the author specifies the units.
@clshortfuse wrote:
But Android is still forced to 16px.
Any browser can add a font size controller to the UI. No additional spec work needed.
Then the relevant zoom unit is em or rem.
Sorry, but I'm still confused. I understood that it's not a CSS problem, assuming that it's a viewport (HTML) issue. The Chromium team won't move forward without a spec. And there is no spec for using native system font size.
So the resolution was... don't use native system font size and instead use em rem? That doesn't really work for PWA/Home Screen apps. I'm still using -apple-system-body to this day for Home Screen Apps on iOS. Are you saying I shouldn't? Is Apple planning on dropping dynamic font? If that's the case, what is Apple's suggested solution for font-scaling with Home Screen Apps? I don't think forcing 16px font is an accessible solution.
Current WAI guidance still suggests using -apple-system-body. Is that wrong then?
As I recall, there was an issue opened regarding Home Screen web apps, but I don't think there is a solution.
@cookiecrook Thanks for the heads-up and I sincerely apologize for the confusion. I'm kicking myself here because I could have worked on this sooner. I'll probably investigate the Web App Manifest and see if I can gain some traction there.
I'm definitely off topic here and we can mark the comments as such.
No apologies necessary. The other "zoom unit" thread you commented on was a more complex issue that I'm still not sure I fully understand.
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1915077 it should be defined what happens to changes to a <meta name=viewport> element (e.g. remove).
Demo: https://meta-viewport-changes.glitch.me/
It seems Firefox responds to changes to the content attribute (e.g. change to initial-scale=0.5) and inserting the element, but not removing the element (testing with devtools). Same in Chrome (devtools) and Safari (on iPad).
Since there seems to be interop in ignoring removing the element, I think that's what should be standardized.
@zcorpan I ... don't think that makes any sense. If browsers didn't respond to any changes, that would be one thing. But responding to changes except for removing the element seems super weird. If we're not constrained by compat, I think it would make more sense to align on responding to all changes. We should give authors a consistent story about how this works.
@fantasai OK, that is fair enough. It indeed seems unlikely that the current behavior is required for compat.