Re: Disadvantages of ch unit (was: stability of root em unit spec)

Hi, all!

Giovanni Campagna schrieb:
> I like your idea, just I think your gone a bit too far wanting to allow any
> char from any selector
> look at "width of 'ᚘ' from #my-id > div.my-class:nth-child(4)"
> (char is U+1698, OGHAM LETTER IFIN)
> it is perfectly legal in your proposal but doesn't have a real use case

Its impossible to design a language in which silly and useless
sentence are impossible.
I see use cases, even your example isn't one.


> Instead, it adds unneeded complexity for 2 reasons:
> 1) your not backcompatible with the current syntax

Why? Because 'of' and 'from' doesn't exist now, the expression is
simply ignored.


> 2) CSS parsers already exists and their tokenizers don't expect whitespace
> inside values

Inside units. The parser need only look at the next token.
If the next token is 'from' then this and the next token, or
bracket-expression is part of the unit.
If it is 'of' then this and the following string is part (also)
of the unit.


> 3) you're introducing two syntax keywords (of and from)

yes, and? Instead of 'ch', 'rem' and many other that will
follow.


> 4) I'm not sure if this syntax is compatible with shorthand properties,
> where whitespace is meaningful to divide the shorthand into the full form
> (there are already too many issues about shorthand property syntax)

I think this shouldn't be a problem. See also under 2.
(Maybe for readability the web developer should advised to
  use more whitespace between values.)

> A part from syntax, which may be resolved using something like
> chw(<string>,<selector>) (where cwh is char width)


> your proposal has two problems:
> 1) you assume that given char exists in the selected font (which is not
> always true)

All use cases i can think of are based that this char is used
in content also.
So the same rules should apply.
Use the Unicode replacement char (U+FFFD), or if this also
doesn't exist whatever your browser would show, perhaps '?'.


> 2) you assume that a full loaded document (to fully resolve selectors) is
> linked with the style sheet (incremental parsing is not allowed)

Restrict it too elements which are before.
All preceding nodes in document order
before the context node (selector of the set where the rule is part of).
And make the general case undefined.
(Or maybe overly restrict it to ancestors, if you like.
  Or tell this your web developers
  if you thing this more understandable.)


> 3) the selector may match more than one element, and those may have
> different actual values

Here exists 3 possiblities to resolve the issue:
a) It's undefined, the author is responsible that only one element
    is matched.
b) The first element in the stream is used, ala XPath 1.0(?).
c) The syntax is restricted to only a few clear things,
    like :root, html, body, #idref, body:first-child etc.
    For the most use cases this is enough, but if you will
    use CSS for non-HTML then (c) is problematic, and it is
    also difficult to define what should allowed and what not.
Personally i prefer (b).


> 4) you assume that an actual value for all font properties for that element
> is already found, which in turn means:
> - no transformation can be applied to the computed value from the specified
> value, because computed values are calculated earlier than actual values
> (now instead the computed value of em or ex is aware of font metrics)

Maybe i overlook something. But where is the difference?
Why should it not work for say 'width of "m"', but it does for 'em'?


> - the desidered element must already have been processed, ie you cannot
> reference an element later in the tree and your constraining UA processing
> order (now the only constraint is "parent before childs" for inheritance)

This is fine. Of course this restriction must explicitly worded in the
definition. Like your argument no 2, or not?


> Moreover, the width of '0', 'x' and 'm' are widely used in written
> typography, and the root version of em was introduced to simplify
> accessibility, as the root font size initial value is user decided, so using
> relative units allows to scale appropriately when zooming text, while not
> dealing with nasty inheritance effects (0.7rem is always the 70% of default
> font, while 0.7em is 70% of parent's font)

Yes but:
a) Often sides are composed and my base is not :root.
    (Even the whole side is from me, it can be the same unnatural as the
     value of my parent, so 'rem' isn't a win over 'em'.)
b) This alone cry for rex, rch and r% !


thanx,
   Josef

Received on Friday, 9 January 2009 20:35:12 UTC