Re: [css-fonts] font-size property and font-weight-property

Fantasai,

On Mon, 15 Jan 2018 14:27:21 -0800
fantasai <fantasai.lists@inkedblade.net> wrote:

> 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
versioning even though using github ;) Scan for @css: 3;

> > 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!

> > 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!)

> 
> > 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:
> 
> 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.

> There are two ways you can adapt to larger fonts:
> 
>    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”
> option in Firefox and zoom in/out on this page:
>         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
einz@verschwendbare-verweise.seinswende.de

Received on Tuesday, 16 January 2018 01:38:44 UTC