2018-01-14 00:15:31 UTC
Sorry, but here's another such case of strange naming:
3.5 Font size: the font-size property:
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 ]
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
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
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.