Discussion:
[css-fonts] font-size property and font-weight-property
(too old to reply)
Dennis Heuer
2018-01-14 00:15:31 UTC
Permalink
Hello all

Sorry, but here's another such case of strange naming:

https://www.w3.org/TR/css-fonts-3/

3.5 Font size: the font-size property:

<absolute-size>
An <absolute-size> keyword refers to an entry in a table of font
sizes computed and kept by the user agent. Possible values are:

[ xx-small | x-small | small | medium | large | x-large | xx-large ]

<relative-size>
A <relative-size> keyword is interpreted relative to the table of
font sizes and the computed ‘font-size’ of the parent element.

Possible values are:

[ larger | smaller ]


(read it all before you answer!)

To be honest, how can a 'keyword' be an absolute size, specifically
when it only 'refers to an entry in a table'? How can 'xx-large' be an
absolute size?

You might answer that there is an absolute size-value in the table. But
that might be the same true for the 'relative-size' keyword 'larger'
that might resolve to just the next entry in that same table. For a
user of this standard this is all just funny talk. For him the term
'absolute-size' in respect to 'xx-large' is like a geek-joke! He has
his very own idea of what is the absolute value for 'xx-large' until he
just tries it.

I please you to exchange the keyword 'absolute-size' with something like
'named-size', 'specified-size', 'provided-size' or 'particular-size'. If
we then don't talk about the table but just about the keywords, the
difference is more obvious:

The 'relative-size' is relative to a current size, the 'specified-size'
is as such...

Please also drop those loose names like 'xx-large'. A technical standard
is not a boutique!


3.2 Font weight: the font-weight property Name:

Value: normal | bold | bolder | lighter | 100 | 200 | 300 | 400
| 500 | 600 | 700 | 800 | 900

You dropped the explanation to the 9-scale. Without explanation the
long numbers don't seem to mean anything specific to remember well.
Even though they look alike and make people wonder why they behave
so strange. The strange behaviour is actually still reasoned about.

I'd prefer to have the terms available to which the numbers are
'roughly' related.

I'd also prefer more clarity. The terms/numbers should refer to
*concrete* mean weights (as factors!?) to which the user agent shall
seek *close* alternatives. Even the latter seems to be not guaranteed
by the matching algorithm in section 5:

* If the desired weight is less than 400, weights below the desired
weight are checked in descending order followed by weights above the
desired weight in ascending order until a match is found.

Do I get this right that a relatively close greater weight is ignored
if a far smaller weight is found?

I understand that the seek first goes downwards to not break a layout.
But, why this one is the lonely one going upwards:

* If the desired weight is greater than 500, weights above the desired
weight are checked in ascending order followed by weights below the
desired weight in descending order until a match is found.

My guess is that these matching rules are a bit helpless. Also, to keep
a layout in bounds, not only the weight as such but also the overall
use of weights in the layout is important. If I use an H1 with 700 and
an H2 with 500, I want both 1) to stay in that relation and 2) to not
grow out of bounds.

I guess that you should be more clear about limits. Or is the weighting
not of that priority to you? Is a side-show, shurely.

Instead of giving vague guesses for typical font names and metrics
never working I'd like to define *concrete* averages, bounds, ratios or
'legitimate distances' that state what shall happen, what might happen,
what should never happen, for this element but not for that element and
for these elements in respect. I mean, using 'em' for all lengths is one
of those proofs that layouters rather care about relations than about
individual facts. I find that css doesn't respect this enough. For
example, one can design for different @media-types but not for
different actual @font-metrics, i.e. to switch to a more loft layout
when the user sets large font. Weighting keywords like 'medium' and
'xx-large' don't make this better. They don't serve like em or @media.

Regards,
---------------------------------------------------------------------
Dennis Heuer
***@verschwendbare-verweise.seinswende.de
Dennis Heuer
2018-01-16 01:15:36 UTC
Permalink
Fantasai,

On Mon, 15 Jan 2018 14:27:21 -0800
It is an absolute size because its size is not relative to anything
else in the page: it is absolute in the same way that px sizes are
absolute. The fact that it's a named constant doesn't make it any
less absolute.
First, it's called a keyword, not a constant. A keyword is only a
reference (into a table, as stated in the document explicitly.)

Second, 'xx-large' (funny that is!) is relative to any similar element
in the page that might be set to 'xx-small'. Please don't answer that
everything's relative. Even though you would have gotten over your
thinking in absolutes...

You seem to only think in implementation details of a UA, even though
css will be written by layouters. From the viewpoint of a layouter, who
might just not care if the browser has a table or not, the name
'xx-large' for a 'keyword' is not addressing any guessable absolute
value. Get the perspective right, please!
It is far too late to drop any keywords from font-size; these have
existed since CSS1 and are widely used on the Web. As Florian
explained, we cannot make changes that break considerable amounts of
existing content.
Scan the list if you did not read my comment about W3C not knowing about
Post by Dennis Heuer
You dropped the explanation to the 9-scale. Without explanation the
long numbers don't seem to mean anything specific to remember well.
Even though they look alike and make people wonder why they behave
so strange. The strange behaviour is actually still reasoned about.
I don't understand this complaint about "strange behavior" here.
They're just numbers.
For a pragmat! For a user of the standard they look like, say, marks on
a scale. Don't know why ;) Though these marks look so huge like they
have very important meaning and so wisely stepped as if they are
perfect numbers, they behave different with different fonts. For a user
that is STRANGE! Thin, instead, is thin. If it is so thin or so thin is
not important. It is thin, and that is ok! Css should guarantee that
thin is thin and everything's fine!
Post by Dennis Heuer
I'd prefer to have the terms available to which the numbers are
'roughly' related.
I don't think a "rough" relation is helpful to interoperability, but
certainly one could file an issue requesting names for each of the
numbers.
The term 'roughly' is taken from the spec and meaning the actual
current relation to the names given in the spec. But those names can
not be used as keywords. That is what I addressed. In other words, I
actually filed that issue with the replied to email (will not go to
github!)
Post by Dennis Heuer
I'd also prefer more clarity. The terms/numbers should refer to
*concrete* mean weights (as factors!?) to which the user agent shall
seek *close* alternatives. Even the latter seems to be not
What the numbers mean is determined by the font designer. CSS does not
have any control over the thickness of the strokes; the meaning of
100 vs 400 is determined by the fonts.
You get the point? Read the above again!
Because when the author specifies a greater weight than the typical
weight of paragraph text (which is, by convention, in the 400-500
range), they are indicating that they want a noticeable difference in
weight: a bolder font than the regular weight. Therefore we search
upwards until we find one.
That is an escalating guess not getting out of bounds only because the
browser will hopefully find some font early enough. This is not a
system that works. This is a system that works by common circumstances
(e.g. not using those numbers). Limits for a seek to both directions,
combined with other tricks like: "If you can't find something in reach,
make what you can serve a bit darker or lighter!", would be more to my
fit. That's why I'd rather like to have semantic rules specifying
*weightings*, also between different elements.
1. Use 'em' or 'ch' values in your media queries. These will let
you adjust your layout based on the size of the font the user chose.
If more 'em's fit in the width, then more text will fit, so you can
have more items side-by-side. If fewer ems fit, then less text will
fit, so you will need to reduce the number of columns.
You can see this in effect if you select the “Zoom Text Only”
http://csswg.inkedblade.net/staging/redesign/divya/
2. Do not size the root element (<HTML>) and specify the sizes in
your page using 'rem', 'em', or 'ch' units. Anything you size with
these units will size relative to the user's default font size.
~fantasai
You know that this is only relatively relative and only guessing for
what I argued about. I'd rather like to know certain behaviour of a
font that is not neccessarily catched with em, like how it spans. I
guess that this can only be benchmarked. Or do you provide all these
font options to let me configure down the font to behave? How does that
look alike? However, I still don't see how to do this effectively
because of the differences between the options, and because the user
can override this...

Regards,
---------------------------------------------------------------------
Dennis Heuer
***@verschwendbare-verweise.seinswende.de
fantasai
2018-01-16 20:02:10 UTC
Permalink
Post by Dennis Heuer
On Mon, 15 Jan 2018 14:27:21 -0800
It is an absolute size because its size is not relative to anything
else in the page: it is absolute in the same way that px sizes are
absolute. The fact that it's a named constant doesn't make it any
less absolute.
First, it's called a keyword, not a constant. A keyword is only a
reference (into a table, as stated in the document explicitly.)
The keyword behaves as a named constant, is what I was trying to point out.
(Other keywords do not behave as named constants: their behavior varies
depending on other factors and cannot be mapped to an absolute px value.)
Post by Dennis Heuer
Second, 'xx-large' (funny that is!) is relative to any similar element
in the page that might be set to 'xx-small'. Please don't answer that
everything's relative. Even though you would have gotten over your
thinking in absolutes...
I think you are the one who is trying to argue that everything is relative. :)

36px anywhere in the document is 36px. This is what makes it an absolute
length. xx-large is the same.
Post by Dennis Heuer
You seem to only think in implementation details of a UA, even though
css will be written by layouters. From the viewpoint of a layouter, who
might just not care if the browser has a table or not, the name
'xx-large' for a 'keyword' is not addressing any guessable absolute
value. Get the perspective right, please!
The exact value is not guessable, indeed, but its relation to the other
keywords like x-small is quite guessable.
Post by Dennis Heuer
It is far too late to drop any keywords from font-size; these have
existed since CSS1 and are widely used on the Web. As Florian
explained, we cannot make changes that break considerable amounts of
existing content.
Scan the list if you did not read my comment about W3C not knowing about
Yes, and unfortunately, I don't have the time to write a detailed explanation
of why the Web (HTML, CSS, JavaScript, the DOM), is unversioned. But that is
how it is. CSS was designed for this reality, this is why we have forwards-
compatible parsing rules and @supports.

Fwiw, the HTML Working Group tried to version it by creating XHTML2 but it
was a failure *because* it was versioned.
Post by Dennis Heuer
Post by Dennis Heuer
You dropped the explanation to the 9-scale. Without explanation the
long numbers don't seem to mean anything specific to remember well.
Even though they look alike and make people wonder why they behave
so strange. The strange behaviour is actually still reasoned about.
I don't understand this complaint about "strange behavior" here.
They're just numbers.
For a pragmat! For a user of the standard they look like, say, marks on
a scale. Don't know why ;) Though these marks look so huge like they
have very important meaning and so wisely stepped as if they are
perfect numbers, they behave different with different fonts. For a user
that is STRANGE! Thin, instead, is thin. If it is so thin or so thin is
not important. It is thin, and that is ok! Css should guarantee that
thin is thin and everything's fine!
We can't do that, because there is no font technology that creates an
absolute scale of boldness across all fonts.

If you stick to a single font family--and choose one with sufficient
weight variants--then you can get the predictable behavior you want.
For example, Avenir has six weights. And in the future, variable font
technology will allow interpolation of weight across the scale, so you
can get many more options with such a font.
Post by Dennis Heuer
Post by Dennis Heuer
I'd also prefer more clarity. The terms/numbers should refer to
*concrete* mean weights (as factors!?) to which the user agent shall
seek *close* alternatives. Even the latter seems to be not
What the numbers mean is determined by the font designer. CSS does not
have any control over the thickness of the strokes; the meaning of
100 vs 400 is determined by the fonts.
You get the point? Read the above again!
See above.
Post by Dennis Heuer
You know that this is only relatively relative and only guessing for
what I argued about. I'd rather like to know certain behaviour of a
font that is not neccessarily catched with em, like how it spans. I
guess that this can only be benchmarked. Or do you provide all these
font options to let me configure down the font to behave? How does that
look alike? However, I still don't see how to do this effectively
because of the differences between the options, and because the user
can override this...
I'm not sure what you mean by "spans", but the ch unit is keyed to the
font pitch. You can use that.

And yes, the user can always override things. That is by design: the user
should be able to adjust the page so that it is readable for him/her.

~fantasai
John Hudson
2018-01-16 21:02:06 UTC
Permalink
Post by fantasai
We can't do that, because there is no font technology that creates an
absolute scale of boldness across all fonts.
If you stick to a single font family--and choose one with sufficient
weight variants--then you can get the predictable behavior you want.
For example, Avenir has six weights. And in the future, variable font
technology will allow interpolation of weight across the scale, so you
can get many more options with such a font.
There's also the possibility, with variable fonts, of defining a weight
axis (in addition to the CSS scale 'wght' axis that is already part of
the OpenType Design-Variation Axis Tag Registry*) that uses something
like per-mille-of-em as a scale, related to a typical key stem weight.
This would enable not an absolute scale of boldness — since boldness is
a perceptual phenomenon affected not just individual stem weights but
overall texture of text, which differs not only across typeface designs
but across writing systems — but closer matching than the enitrely
arbitrary assignment of font weights to CSS weight class numbers.

JH


*https://www.microsoft.com/typography/otspec/dvaraxisreg.htm
Dennis Heuer
2018-01-16 22:17:02 UTC
Permalink
On Tue, 16 Jan 2018 12:02:10 -0800
Post by fantasai
Post by Dennis Heuer
On Mon, 15 Jan 2018 14:27:21 -0800
It is an absolute size because its size is not relative to anything
else in the page: it is absolute in the same way that px sizes are
absolute. The fact that it's a named constant doesn't make it any
less absolute.
First, it's called a keyword, not a constant. A keyword is only a
reference (into a table, as stated in the document explicitly.)
The keyword behaves as a named constant, is what I was trying to
point out. (Other keywords do not behave as named constants: their
behavior varies depending on other factors and cannot be mapped to an
absolute px value.)
Post by Dennis Heuer
Second, 'xx-large' (funny that is!) is relative to any similar
element in the page that might be set to 'xx-small'. Please don't
answer that everything's relative. Even though you would have
gotten over your thinking in absolutes...
I think you are the one who is trying to argue that everything is relative. :)
I personally can handle this correctly...
Post by fantasai
36px anywhere in the document is 36px. This is what makes it an
absolute length. xx-large is the same.
Post by Dennis Heuer
You seem to only think in implementation details of a UA, even
though css will be written by layouters. From the viewpoint of a
layouter, who might just not care if the browser has a table or
not, the name 'xx-large' for a 'keyword' is not addressing any
guessable absolute value. Get the perspective right, please!
The exact value is not guessable, indeed, but its relation to the
other keywords like x-small is quite guessable.
So what is this talking about absolute values when you agree that the
keywords are used and only understood to be relative to each other?
This is what I talk about. You mix up perspectives (to always be right
no matter how you turn.) See what you are talking!
Post by fantasai
Post by Dennis Heuer
It is far too late to drop any keywords from font-size; these have
existed since CSS1 and are widely used on the Web. As Florian
explained, we cannot make changes that break considerable amounts
of existing content.
Scan the list if you did not read my comment about W3C not knowing
Yes, and unfortunately, I don't have the time to write a detailed
explanation of why the Web (HTML, CSS, JavaScript, the DOM), is
unversioned. But that is how it is. CSS was designed for this
reality, this is why we have forwards- compatible parsing rules and
@supports.
Fwiw, the HTML Working Group tried to version it by creating XHTML2
but it was a failure *because* it was versioned.
Could name enough counter examples. However... There definitly was more
to the story of XHTML, which was abandoned by the outer world before it
was released. And, ah, what about WhatWG? ... Let's drop this part!
Post by fantasai
Post by Dennis Heuer
Post by Dennis Heuer
You dropped the explanation to the 9-scale. Without explanation
the long numbers don't seem to mean anything specific to remember
well. Even though they look alike and make people wonder why they
behave so strange. The strange behaviour is actually still
reasoned about.
I don't understand this complaint about "strange behavior" here.
They're just numbers.
For a pragmat! For a user of the standard they look like, say,
marks on a scale. Don't know why ;) Though these marks look so huge
like they have very important meaning and so wisely stepped as if
they are perfect numbers, they behave different with different
fonts. For a user that is STRANGE! Thin, instead, is thin. If it is
so thin or so thin is not important. It is thin, and that is ok!
Css should guarantee that thin is thin and everything's fine!
We can't do that, because there is no font technology that creates an
absolute scale of boldness across all fonts.
Again this word 'absolute'. As you already guessed, I myself don't use
this. I also don't need it. My guess was benchmarking (consider your
test-suites for the browsers as part of a font-breaks-layout-how-so
benchmarking), once done on the user's system and then cached...
There are other imaginable ways... This is possible. Maybe it will never
be done. That's a different issue... It was just a guess... Or a please!
Post by fantasai
If you stick to a single font family--and choose one with sufficient
weight variants--then you can get the predictable behavior you want.
For example, Avenir has six weights. And in the future, variable font
technology will allow interpolation of weight across the scale, so you
can get many more options with such a font.
Post by Dennis Heuer
Post by Dennis Heuer
I'd also prefer more clarity. The terms/numbers should refer to
*concrete* mean weights (as factors!?) to which the user agent
shall seek *close* alternatives. Even the latter seems to be not
What the numbers mean is determined by the font designer. CSS does
not have any control over the thickness of the strokes; the
meaning of 100 vs 400 is determined by the fonts.
You get the point? Read the above again!
See above.
Post by Dennis Heuer
You know that this is only relatively relative and only guessing for
what I argued about. I'd rather like to know certain behaviour of a
font that is not neccessarily catched with em, like how it spans. I
guess that this can only be benchmarked. Or do you provide all these
font options to let me configure down the font to behave? How does
that look alike? However, I still don't see how to do this
effectively because of the differences between the options, and
because the user can override this...
I'm not sure what you mean by "spans", but the ch unit is keyed to the
font pitch. You can use that.
Webopedia: https://www.webopedia.com/TERM/P/pitch.html

In proportional-pitch fonts, different characters have different
widths, depending on their size. For example, the letter d would be
wider than the letter I. Proportional fonts, therefore, have no pitch
value.

Whatever, using fonts will stay being a matter of trust - in the 0, if
i'm correct? Or is that different from browser to browser?

Just to mention here: In all sources I read, like the css specs,
firefox manuals and wikipedia, em reflects to pt, and pt reflects to
em. This often via 'font-size' which itself reflects back and forth.
This is also very helpful!
Post by fantasai
And yes, the user can always override things. That is by design: the
user should be able to adjust the page so that it is readable for
him/her.
~fantasai
Regards,
---------------------------------------------------------------------
Dennis Heuer
***@verschwendbare-verweise.seinswende.de

Loading...