W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: Proposal: related-units-base directive

From: Josef Schmid <e9427749@student.tuwien.ac.at>
Date: Mon, 19 Jan 2009 21:28:03 +0100
Message-ID: <4974E253.50309@student.tuwien.ac.at>
To: www-style@w3.org
CC: "Tab Atkins Jr." <jackalmage@gmail.com>

Tab Atkins Jr. schrieb:
> On Wed, Jan 14, 2009 at 11:28 AM, Josef Schmid
> <e9427749@student.tuwien.ac.at> wrote:
>> Hi, too all!
>>
>> This is a proposal to make the 'rem' unit more
>> useful.
>>
>> For this proposal _relative_ units are different
>> to _related_ units.
>> So 'rem' is a _related_ unit, and 'em' is _relative_.
>>
>> The whole idea is, that the reference point can be
>> change to something different as the root element.
>>
>> Synopsis:
>>  related-units-base: <value>;
>>  related-units-base: <value> <value>;
>>
>> Values:
>>  inherit .... the same as for the parent node.
>>               This is the default, except
>>               for the root element.
>>  root ....... the root element
>>  default .... browser/user default, honor
>>               user style-sheets for root,
>>               but not form author.
>>  sel(<css selector>) ... the css-selector
>>               is the base. Only selectors
>>               which address preceding nodes
>>               in document order before the context node
>>               (selector of the set where the rule is part of)
>>               are allowed. Behavior is undefined for others.
>>               If the selector match multiple nodes, the first
>>               is used.
>>               If the selector match the actual node it is
>>               ignored, but are valid for descendants if the
>>               inherit.
>>  this-for-inherits ... Make the actual node the base
>>               for descendant node if the inherit.
>>               This needs some further clarification,
>>               but hopefully the idea is clear.
>>
>> If the directive have two values, the first value is used,
>> but the second is bequeathed.
>>
>> ----
>>
>> More values that are maybe interesting:
>>   my-parent ... the parent of the node where the directive
>>                 is used.
>>   parent ...... the parent node, this makes the all inherits
>>                 _relative_.
>>
>> ----
>>
>> Example:
>> div.toolbox { related-units-base: this-for-inherits;
>>              /* ^- identical to
>>                    related-units-base: inherit this-for-inherits;
>>              */
>>              font-size: 12pt;
>>            }
>> ..toolbox h1 { font-size: 1.2em; }
>>
>> ----
>>
>> Other ways to reach the intended exists, ala:
>>  * 'from' unit expander,
>>  * value-link(...),
>>  * unit-base for relative units + feature switch,
>>
>> So if you think like me this is a issue that should be solved,
>> but don't like this proposal than ...
> 
> I'm unconvinced that this is actually an issue.  The rem unit is
> undoubtedly useful

Yes, it make some things easier...
.... but neither it introduce something new nor is the simplification
as large as desirable.

> - I have run into problems with em-based
> measurements in most projects I've done, where I need to manually
> compensate for a parent with larger or smaller text than normal.

Interestingly enough, i never have such a problem.
Maybe because my (html) stucture design was always infected
by my subconscious mind about css restrictions.

But because the structure should independent from presentation,
i also think this does matter, anyway.


> I'd actually use *only* the rem unit in many cases, because it more
> accurately maps to what I actually want (a unit that maps to the
> user's preferred font-size).

So far as i understand the definition of 'rem', this is different
from "user's preferred font-size".

This is only true, if you don't set/change the font-size of the
root element (as author).

Of course you try to define a standard usage for you and
for your co-workers;
e.g. :root > * { font-size: 8vh /* 12pt 14px etc. */ }
      .something-user-setting-based { font-size: 1rem }
and make sure all text is inside a sub element container.

(Btw. how does the "magic body" interact with this, here?)



> However, I have not yet come upon a case in my designs where I've
> wanted the em of an arbitrary element in the document.
> 
> Are there any reasonable use-cases that would require this sort of power?


I hope the following assumptions are reasonable for you:
*) A stylesheet file/suite is normally for a whole site - or at least
    for a big amount of pages.
*) Nowadays a page is composed of different parts, like navigation menu,
    blog, ...
    Even without mashups and 'web2.0 widgets'.
    (And without dirty one's hands with ad banners.)
*) The content and the environment is evolving so the the site must
    be maintained continuously.

In this case the 'rem' unit like it is now, can become easily a trap,
of the kind "buy now, pay later". Of course the costs are than
much more than paying instantly.

As an extreme example: If you style all with 'rem' instead of 'em'
and you would make your menu stuff larger by 10%. You have
to change all entires, and not only for the menu container element.

We can use your use-case as example here:
..your_block { font-size: 0.9rem }
..your_block h1 { font-size: 1.2em }
..your_block h1 .h1comment { font-size: 0.9rem }
      /* dont forget this to change also -^ */

Of course if you style only on page you can easily test and
be sure that you don't forget anything to change.

So without more flexibility 'rem' should be deprecated as bad practice,
and calculating relative values is more work at the design phase
((and maybe introduce rounding errors)),
but on the other hand 'em' is than more stable.

With the '_related_' version you bypass the same oddity, get even more
readability and don't pay to hold consistence and maintainability.


bye,
   Josef
Received on Monday, 19 January 2009 20:29:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT