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

On 01/15/2018 05:15 PM, Dennis Heuer wrote:
> 
> 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.)

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

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

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

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

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.

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

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

See above.
> 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

Received on Tuesday, 16 January 2018 20:02:39 UTC