- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Sep 2019 07:08:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Dynamic text size`, and agreed to the following: * `RESOLVED: There should be a way to have true font sizes.` <details><summary>The full IRC log of that discussion</summary> <mstange> Topic: Dynamic text size<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/3708<br> <mstange> ???: For a long time we've had scalable fonts that are based on the Desktop Web.<br> <heycam> s/???/jcraig/<br> <mstange> jcraig: It took us a while to make it work on all extreme cases.<br> <mstange> ... We would like to support low vision users who have extremely large text sizes.<br> <mstange> ... Forcing such giant font sizes on web pages would make most web pages unreadable.<br> <mstange> ... We would like to have a way to opt in to larger font sizes.<br> <mstange> ... as an author.<br> <mstange> ... We would also like to propose a feature that allows web pages to detect large font sizes and adjust the sizes of other elements.<br> <mstange> ... We have some aspects of this that are available today: You could detect based on min-width in ems, but that does not work consistently.<br> <mstange> ... Right now there is no standard way to opt in to this that works across all browsers.<br> <mstange> ... Most browsers on mobile systems don't want to break their users' layout.<br> <mstange> ... We have examples where it would be very difficult or even impossible to achieve the intended layouts today.<br> <mstange> jcraig: [demo]<br> <mstange> ... I have applied iOS settings that render text extremely large and bold.<br> <mstange> ... I can show how different apps deal with this setting.<br> <mstange> ... Calendar switches to 3 or 2 column layouts.<br> <mstange> ... The Books app switches from a 2 column layout to a single column layout.<br> <fantasai> These are all very easy to do if you have flexbox/grid and correctly implement media queries in em units<br> <fantasai> or ch units<br> <mstange> ... In Mail, with larger font sizes, the title gets clipped but the email's time is preserved.<br> <mstange> fantasai: Is the problem that we can't actually implement media queries with em and ch units because the web would break, but you want to have media queries with em and ch units?<br> <mstange> ... Everything you've demonstrated here is totally possible with em and ch units in media queries.<br> <mstange> ... On mobile you're not returning the correct values because that would break. So what you're saying is you want real units?<br> <mstange> jcraig: What we want is an ability for an author to say "I can handle any font size you throw at me."<br> <mstange> florian: How possible is that this signal becomes worthless over time as it gets copied around, and we need to add still another signal?<br> <mstange> chris: People are rapidly going to find out that just copying this around will break them.<br> <mstange> jcraig: The reason we don't turn this on by default is that web developers *don't* find out that it breaks them.<br> <mstange> ... They haven't turned on these large fonts on their system.<br> <chris> fair point, retracted<br> <mstange> jcraig: The first part of what we need is the opt in to the higher font sizes. The second part is the media query part.<br> <mstange> fantasai: In order to do the kind of layout transformations you want, you also have to know how many letters fit on the screen. You'd use the min-width query.<br> <mstange> jcraig: That would get us some of the way.<br> <mstange> fantasai: Having just the media query for the font size is not enough if you can't relate it to the size of the viewport.<br> <mstange> florian: You can't compare the font size and the viewport because the lengths have different units.<br> <mstange> ... The thing you call an opt in would also opt in the media queries to behave properly.<br> <mstange> ... Whichever opt-in we have needs to opt in both to behave how things were originally intended.<br> <AmeliaBR> `@media (min-height: 10em)` only works if the window root em size is accurate. So if we don't reveal the accurate preferred em value except in an environment value, you'd need to use `@media (min-height: calc(10*env(user-font-size)) )`<br> <mstange> ???: If you have a user font size variable, you can use calc to obtain the right answer.<br> <heycam> s/???/fremy/<br> <mstange> fantasai: As an environment variable, it would work out.<br> <mstange> ... But (?) it would be multiple variables, not one variable.<br> <mstange> fantasai: The size of ch is dependent on the initial font, not on the font that is used.<br> <mstange> florian: There is a number of ways you can use environment variables to do what you want, but if the opt-in mechanism opted in everything, it would also work.<br> <AmeliaBR> s/(?)/Firefox uses different font-sizes for different languages, so/<br> <mstange> florian: Is there reason to exclude media queries from the opt in?<br> <mstange> jcraig: It should not be excluded.<br> <mstange> fremy: You want to be able to opt in only parts of a web site.<br> <mstange> ... If the developer in the iframe did the work to deal with large fonts, if it is embedded in another website that does not handle them, all the work is for nothing.<br> <mstange> jcraig: The reverse is also true.<br> <mstange> fantasai: If the widget is inheriting the font from the parent document, then it's going to have problems if the parent document picks a larger font, regardless.<br> <mstange> fremy: You cannot say media queries behave differently for different parts of the same document.<br> <mstange> florian: Yes, if you put a responsive widget into a non-responsive website, then yes, your responsiveness is wasted.<br> <mstange> jcraig: It sounds like we're agreeing that it would be useful to have an opt-in for websites to express that they can handle large font sizes.<br> <mstange> florian: And we do not agree on the media query part - depending on how we do the opt-in switch, that switch may also opt in media queries automatically.<br> <mstange> florian: If we can't make the existing media queries work, we maybe need to add more media queries.<br> <mstange> jcraig: That sounds reasonable. Once we have an opt-in we can experiment and see in what cases it's not good enough.<br> <mstange> AmeliaBR: Having it in CSS would be better than having it in markup because you can put it into one shared stylesheet.<br> <mstange> ... In order to get useful media queries, the opt in has to be outside of a property.<br> <mstange> ... If somebody has explicitly set this opt in value, then the existing font-size keywords that were supposed to be relative to the user-chosen default font size can actually do that.<br> <plinss> q+<br> <mstange> ... Otherwise, the default size will be the legacy 16px.<br> <mstange> jcraig: I think that sounds ok. But a new media query would be clearer in terms of what we want to communicate to authors.<br> <mstange> ... Without that, the complexity of doing layouts based on width and layouts based on font-size is going to result in lots of media query blocks. (?)<br> <mstange> Rossen_: We need to work towards a resolution.<br> <Rossen_> q?<br> <Rossen_> ack plh<br> <Rossen_> ack plinss<br> <Rossen_> ack fantasai<br> <jcraig> Q+<br> <mstange> plinss: I'm concerned about adding yet another mode switch. Mode switches are bad. Can we do the right thing without a switch?<br> <mstange> fantasai: I hate meta tags because you can't put them in a stylesheet and link them from everywhere.<br> <mstange> ... However, it seems to make the most sense to add this as a meta tag because it affects media queries and the initial containing block size.<br> <gsnedders> RRSAgent: make the minutes<br> <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html gsnedders<br> <mstange> ... And once the mode has been switched, font sizes and everything else can start working the way initially intended.<br> <florian> q+?<br> <mstange> ... These things all belong together so we should just tack on a meta tag.<br> <mstange> Rossen_: I do not hear agreement on exact technicalities.<br> <mstange> Rossen_: Let's have a resolution on having a way to opt in, even if we don't have the exact way of doing it.<br> <mstange> Rossen_: Objections on opting in to true user font sizes?<br> <mstange> jcraig: We (Apple) tried to do this without a mode switch, by default, and all 200 000 apps broke.<br> <mstange> ... Even with an opt-in switch, it took years for all first party apps to support this mode.<br> <mstange> fantasai: I don't like mode switches either, but the alternative is to add an entire set of units. A mode switch is a lot simpler.<br> <mstange> AmeliaBR: I came in with the same concerns as plinss, but one thing I did bring up was that, at the user agent level, there should be reflection of the fact that there are two cclasses of users.<br> <mstange> ... Some users want fonts that don't want broken web pages, and some users want readable fonts even if pages are broken.<br> <mstange> ... It seems that most users will accept smaller fonts if it means that pages are not broken.<br> <mstange> plinss: I have no concerns with a user switch. I have concerns with adding a switch to the web platform.<br> <mstange> ... If we have to commit the sin again of adding another mode switch, let's add it in a way that it can fade away in the future, and not such that content will break if authors don't anticipate the switch.<br> <mstange> ... There is real costs to adding mode switches.<br> <mstange> myles: The resolution seems to be about intention, not implementation. Let's try to agree on that.<br> <mstange> Rossen_: Objections to having the option to have two font sizes?<br> <fantasai> s/two/true/<br> <mstange> RESOLVED: There should be a way to have true font sizes.<br> <karl> RRSAgent, make minutes<br> <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/15-css-minutes.html karl<br> <emilio> cmp: https://bugzilla.mozilla.org/show_bug.cgi?id=1252821<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3708#issuecomment-532091468 using your GitHub account
Received on Tuesday, 17 September 2019 07:08:57 UTC