1.4.3 - CSS4 Variable Fonts - What is bold? #341
Comments
|
From @patrickhlauke on February 20, 2018 23:46 even defining bold numerically won't actually help much, as it still depends entirely on the individual font. bottom line is that this SC has been problematic from the start (with its use of "point" from the print world, and its initial insistence that it meant "as measured on the screen" - which cannot be set nor guaranteed by authors). and the handwavy "bold" won't get any more precise by adding a number there either. IMO of course. |
|
From @patrickhlauke on February 20, 2018 23:48
on that point, you always need to refer to the actual computed value (the amended understanding doc clarifies this). |
|
From @slafleche on February 21, 2018 14:23 Unless we analyze the actual font, I don't really see how we can do much more than look at the font-weight. The designer can always make bad decisions for the font or make odd stylistic choices. |
|
From @patrickhlauke on February 21, 2018 14:48 having slept on it, adding a clarification that "bold" means a (computed) font weight value of 700 and over probably won't do any harm (but yes, won't make the SC any more subjective in terms of its handwavy nature about fonts themselves). |
|
From @jake-abma on March 4, 2018 9:19 [Personal response] There’s more to boldness than just a number like “700 and over”. Just as there is no standard for “normal” weight across typeface families, there is no standard for “bold” weight. When defined in CSS the 700 is like a criterion which ‘defaults’ to bold but this is also the case for 600. The exact calculation is dependent on the Font Matching Algorithm. The Font Matching Algorithm in CSS decides whether the face shown is a bold variant or not. This is done using the character map of the font, data which maps characters to the default glyph for that character. In general, bold weights map to faces with heavier weights and light weights map to faces with lighter weights. “Bolder” and “Lighter” just decrease or increase a step from the inherited value when their min or max limit is not yet reached. The font weight numbers/sizes in CSS are not technology agnostic so by adding ‘700 and over ’ this may conflict with other technologies and going that way we should mention and define a mapping to the “CSS number approach” as we do with “CSS pixels” but I think this brings us worse off than needed. As can be seen in the CSS Fonts Module Level 4 a weight mapping for a font family with 300 and 600 weight faces is also very common. When we take Lucida Sans as an example which has lots of typefaces, name + number specifies weights within each Lucida style and also coordinates weights between different families. Names like “UltraThin”, “Thin”, “Normal”, and “Black” suggest the visual impression of each weight. Corresponding CSS numbers, 100, 200, 400, and 800, respectively, indicate that each weight in the list is twice as dark as the previous one. Lucida Basic font weight names combine traditional weight names with CSS font-weight numbers. But when we see the naming and their number in CSS “Thin” is 100 NOT 200 and “Black” is 800 NOT 900. http://lucidafonts.com/fonts Other progressions are also definable in this naming method. For example, in the series of Normal (400), Bold (600), and ExtraBlack (900), each successive weight is 1.5 times as dark as the previous one. The many gradations of weight in Lucida allow a typographer or graphic designer to choose different kinds of weight progressions for different contexts For typeface names we see however, even after a century of naming bold weights, there is still no standardization between type families, such that the bold of one family will be the same weight as the bold of another family. This makes the fixation of a number by CSS even more difficult. When checking the history of numbers for weights we see:
And of course we have the CSS variant of :
CONCLUSION: As the UNDERSTANDING doc already mentiones:
Adding the number makes the concept of bold more difficult to be used within the limits and rules allowed by the underlying technology. The difference between CSS Fonts Module Level 3 and CSS Fonts Module Level 4 doesn’t change this. |
|
From @jake-abma on March 4, 2018 9:20 [Proposed unofficial response] |
|
From @patrickhlauke on March 4, 2018 12:23 @jake-abma unless i'm mistaken, the question here was about elaborating in the understanding document, which is non-normative and thus should be editable without breaking the "can't touch this" backwards compatibility requirement on the normative SC/glossary definitions part. |
|
From @joe-watkins on March 6, 2018 20:24 @jake-abma Thanks for the awesome thoughtful responses ;) @patrickhlauke is correct - elaboration of the understanding doc in some way to help define what "bold" is and how to test for bold, both manually and automated! It is already a bit fuzzy and will get fuzzier as type matures on the web. @jake-abma How do you recommend assessing type on the web for WCAG compliance? How do we say a font is "bold"? Particularly the 18.5px - 24px sizes. For example, if we visit this page in current Chrome -- does this type in the H1 meet WCAG color contrast minimums and how did you arrive at this conclusion? Things get real interesting when you introduce a variable font with |
|
From @lauracarlson on March 6, 2018 20:47 Hi Jake, @jake-abma wrote:
Maybe consider adding that the Working Group will move this issue to the WCAG 2.0 repo because it affects a 2.0 understanding document. Then the last sentence in the proposed response can be deleted. |
|
From @WayneEDick on March 6, 2018 21:44 Joe, Sincerely, Wayne On Tue, Feb 20, 2018 at 10:44 AM, Joe Watkins notifications@github.com
|
|
From @patrickhlauke on March 6, 2018 22:59 @WayneEDick the use of "18pt or 14pt bold" has been in WCAG 2.0 for ages, and was not up for debate as part of the 2.1 work. @joe-watkins' issue here is simply to further clarify that "bold", in scenarios where font weight is set numerically in CSS, would equate to "700 or higher" |
|
From @WayneEDick on March 7, 2018 1:55 Why would that change contrast ratio? On Tue, Mar 6, 2018 at 2:59 PM, Patrick H. Lauke notifications@github.com
|
|
From @jake-abma on March 7, 2018 8:18 Exactly, that is what my whole response is all about! In the end "Bold" is a judgement call from the tester based on the visual appearance. Or at least it should be. The why is because the number doesn't say anything about whether it's truly 'bold' or not. It is an indicator though and sets a benchmark. What CSS does is just to place a benchmark for what is normal, bold, black etc., and numbers 'snap' to these benchmarks. As I've written in the previous comment about what's in the Understanding doc:
So here we see that in general this benchmark is seen as sufficient and for most fonts you're 'kind of save'. But your example shows that it doesn't always work and this is also the case for fonts faces who can be considered as 'in between'. The gray tone of text, the ratio of the thickness of vertical stems in letters like ‘l’ to its font x-height is a way that type designers measure relative weights. A more accurate way to indicate visual weight is to measure the percentage of black pixels in the total area of the typeface body when the font is set solid, that is, with no extra leading or inter-line spacing. And we're not even talking about color font palettes. So unless we place the screen in a vacuüm space, calibrate the lightness and use a spectrometer on each glyph to really get a number for the density we are left with a benchmark and human judgement call... LOL "700 and over" is not the correct number if you ask me, if used it should be "550 and over for CSS only" (snaps to 700 if I'm right) but that is nothing more than a CSS trick to pick a font face. My suggestion is to leave bold as is, have CSS decide on basis of a number if a bold face should be used (550 or higher) and as a tester judge on experience and knowledge. Bold is also used in the normative definition for 'large scale' (text)
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#larger-scaledef |
|
From @patrickhlauke on March 7, 2018 8:50 @jake-abma in the end, both "bold" and the applicability of "18 points" and "14 points" is a judgement call really, but here we are...WCAG 2.0 uses these terms normatively. The point of understanding doc is then to translate that into something that authors and testers can understand and hopefully makes stuff testable - and judgement calls are tricky to make testable, which is why we gravitate towards "good enough I guess" numbers. Long story short: I'm in favour of adding a tiny extra clarification that gives a numeric value for "bold". Yes, it will depend on the specific font, but so does pretty much everything else in this ill-conceived SC. Maybe, in addition to saying what |
|
From @mraccess77 on March 7, 2018 13:30 @jake-abma wrote "700 and over" is not the correct number if you ask me, if used it should be "550 and over for CSS only" (snaps to 700 if I'm right) but that is nothing more than a CSS trick to pick a font face. I’m sorry, I can’t live with that. For me a font weight of 550 is not bold – using some sample English fonts and comparing CSS bold to CSS 550 there is stark difference. Comparing CSS bold to 700 looks the same to me. While I agree there are differences in font strokes and this can make a big difference – dropping to 550 for all fonts allows people to meet a lower threshold without providing sufficient weight for users with low vision. |
|
From @jake-abma on March 7, 2018 14:6 @mraccess77 I took the 550 because of the mapping at https://www.w3.org/TR/css-fonts-4/#bolderlighter where 550 'jumps' to 700, if no other face is present like 600, and 549 'jumps' to 400 I also asked Wilco Fiers and in aXe they use >600 for checking bold. In the end it's up to the typographer to make the font face 'big' enough so we experience it as bold |
|
From @mraccess77 on March 7, 2018 14:31 @jake-abma As long as the end effect of a relative bolder based on inheritance comes out as 700+ that is fine. I wasn't clear from your post if you were talking about relative bolder or bold. But from what I hear now you are saying if some element has a 550 weight font and then applies bolder to a descendant we should come out with a weight of 900 on the descendant. That makes sense. |
|
From @patrickhlauke on March 7, 2018 16:10 @jake-abma bolder/lighter etc is probably muddying the waters here. we're talking about the absolute
|
|
From @jake-abma on March 7, 2018 16:53 @patrickhlauke , I know that but that's the approach for/from the CSS spec makers and not a definite/absolute true, a font with 600 as bold is/can be also (mapped to) bold. But again, if you read all my comments it's just a matter of what number you place to set a benchmark. So in the Understanding doc you could mention that CSS takes 700 as the bold benchmark but not:
... in general because in my opinion that does create possible harm |
|
From @awkawk on March 7, 2018 17:17 I agree that we aren't changing the normative SC text, so it is good to focus on the Understanding content. The way that I would suggest that we handle this is by adding a "note 3" in the intent section. Anyone want to take a crack at a concise note? Also, we are moving ALL understanding content to the 2.1 repo, so please use that one for branches/PRs. The Understanding documents will cover 2.0 and 2.1, and the source files will be housed in the 2.1 repo. |
|
From @patrickhlauke on March 7, 2018 18:56
as in if a page uses a particular font, and the author sets or are you talking about the possibility that a designer chooses a font that has its bold form already at another numerical value, and sets that value in their CSS, so the computed value is below |
|
From @patrickhlauke on March 7, 2018 18:58 so, if we're adding a note that "smears" the exact value a bit because fonts can be different for the font weight, we should also fudge it for the point size I'd say...which then makes the whole SC essentially non-testable as it relies on a judgement call by auditors/authors. |
|
From @jake-abma on March 8, 2018 8:39
Yes! See my code pen for examples and check 549, 550 for Arial and Lucida weight numbers at: https://codepen.io/Jake-Abma/pen/xPNVWx And please check the facts from Lucida, This is why 700 and up is just not an absolute truth for Bold. Lucida Facts:
=> Normal weight = 400 AND Bold weight = 600 !!! Lucida CSS Values: |
|
From @jake-abma on March 8, 2018 8:42 (ps. I only added normal and bold for Lucida, not all other faces...) |
|
From @patrickhlauke on March 8, 2018 10:27 the codepen doesn't work as loading the extra font is blocked due to CORS policy in browsers. However, if I understand what you're saying, then yes I agree that As the point size and "bold" is in the normative SC text, we can't get around it. so as the precedent for "let's set a number even though it's probably meaningless, and let's handwave it for CJK" has been established, i see no further harm (the harm's already done) in saying that "bold" per spec resolves to but, to be honest, i particularly loathe this SC exactly because it gives a false sense of scientific correctness by providing hard figures (in terms of font size in points) which yes can be unambiguously tested (even by automated tools) but may not mean anything in real life. i will add however, as anecdote, that prior to seeing this issue raised here, i had various two separate people in the past ask me about what "bold" would be when an author had set their just being mindful that if we add a note saying, in essence, "both size and weight are actually dependent on the font, so the hard figures we gave here may not be right", we're effectively undermining the entire basis on which the normative SC stands... |
|
From @jake-abma on March 8, 2018 10:37 This is why suggestion would be to add a note telling CSS uses 700 for a bold benchmark and as the understanding doc already mentioned:
You're save 'most of the times' But not like:
But, leave the above/Understanding text as is and add a separate note:
This way bold is just, well... 'bold', as meant by the typographer, and we stay technology agnostic |
|
From @patrickhlauke on March 8, 2018 10:39
this presupposes auditors use their judgement to determine if something is "bold" or not. as long as that's aknowledged (that this is all eyeballing)... |
|
From @joe-watkins on March 8, 2018 17:48 @jake-abma thanks for shedding light on the font mapping. Not being pinned down to a number makes sense to me. This would support my original post about font widths and weights in CSS 4. I think we just need to convey in the understanding doc that it comes down to human judgement in a more clear and direct fashion. Some folks may interpret the existing documentation in that way but others don't. (I'd imagine a clearer definition would be handy during litigation as well) e.g. "Because various web fonts map to bold typefaces differently. "bold" can be defined by human judgement." If in the future font authors and browsers have more solid standards for folks to lean on computed styles we could poke at this again. It would be nice, then robots and more importantly people with low vision or no vision could test for this. |
|
From @WayneEDick on March 8, 2018 19:51 The understanding document is simply wrong regarding with it's calculation The American Printing House reference (now broken) is in reference to print The APH says:
The Note is an indicator of the focus on print. It is completely irrelevant Wayne On Thu, Mar 8, 2018 at 9:49 AM, Joe Watkins notifications@github.com
|
|
From @DavidMacDonald on March 20, 2018 21:5 Perhaps add a sentence like this to the understanding
|
|
From @awkawk on March 20, 2018 21:7 WG decided to defer a decision on how to address this issue in the Understanding document until it has more time when WCAG 2.1 reaches PR or REC. |
|
Noting that #665 overlaps with this one a lot, we should close one and reference from the other. Given that #665 wasn't imported to this repo, let's close this issue. Pinging the current participants: @WayneEDick, @patrickhlauke, @jake-abma, @DavidMacDonald, @joe-watkins, @awkawk, @mraccess77, @lauracarlson This is closed but not forgotten.. |
|
I have just spent time doing a mini lit review, and cannot fine reading
speed experiments that use font weight.
I'll look a little more.
Best, Wayne
…On Wed, May 8, 2019 at 10:02 AM Alastair Campbell ***@***.***> wrote:
Closed #341 <#341>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#341 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AB6Q4FYBNFEAMYUBPRA4BWDPUMBQ3ANCNFSM4FESSSPQ>
.
|
|
Hi Wayne, If you find something, please add it to #665, thanks. |
From @joe-watkins on February 20, 2018 18:44
Looking ahead to CSS4 fonts, an author can define a font weight with an integer of 1-999, not being limited to multiples of 100.
An author can also define a font-weight with a text value of
bolderorlighterwhich affects the font's inherited weight.With this being said, perhaps there is an opportunity within the SC to expand upon what 'bold' means?
In terms of the number value, I'm assuming bold is anything above 700 for a font. So maybe an addition of the number value to the SC intent may help folks understand?
18 point text or 14 point bold (or a minimum font weight of 700) text is judged to be large enough to require a lower contrast ratio.Don't want to make this more confusing but wanted to throw the idea out there :)
https://www.w3.org/TR/css-fonts-4/#font-weight-prop
https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html
Copied from original issue: w3c/wcag21#772
The text was updated successfully, but these errors were encountered: