Re: [flex-units] unit abbreviations and the flex()

--------------------------------------------------
From: "Zack Weinberg" <zweinberg@mozilla.com>
Sent: Thursday, May 27, 2010 10:33 PM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "W3C Emailing list for WWW Style" <www-style@w3.org>
Subject: Re: [flex-units] unit abbreviations and the flex()

> "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
>> >> I do not see any problems with this, do you?
>> >
>> > You're proposing a change in the CSS2.1 generic syntax.  I don't
>> > think that's worth doing just for the (arguable) additional
>> > readability of '1*' over '1fl'.
>>
>> Any new unit type will be a change of CSS2.1 generic syntax.
>> E.g. 1pt is a LENGTH unit.  Adding either 1* or 1fl will require
>> change of CSS2.1 generic syntax.
>
> Nonsense.  <length> is not part of the generic syntax; adding new
> <length> productions does not of itself require any change to the
> generic syntax, as long as what you add is a possible <any>
> production, which '1fl' is and '1*' isn't.

Are we using the same document:
http://www.w3.org/TR/CSS21/grammar.html#scanner
?

These are

{num}{P}{X}		{return LENGTH;}
{num}{C}{M}		{return LENGTH;}
{num}{M}{M}		{return LENGTH;}
{num}{I}{N}		{return LENGTH;}
{num}{P}{T}		{return LENGTH;}
{num}{P}{C}		{return LENGTH;}

the only LENGTH units in CSS2.1.

Or you refer to something else?

Sorry but I do not see how it is different to add this

{num}{F}{L}		{return FLEX;}

and this:

{num}*			{return FLEX;}

What it will change in principle?

>
>> If you really think that \hspace{10px plus 1fil}  makes real sense
>> in CSS context then I think that flex() function that I've proposed
>> is simple and predictable. So that expression will be written
>> as flex( 10px, 1* ). No?
>
> I don't get it.  Either you are saying flex(10px, 1*) is easier to
> understand at a glance than calc(10px + 1fl), or else you are saying
> that the latter would be harder to implement.  But both of those
> assertions are ridiculous.
>

How many times you need to execute this expression:

width: calc(10px / 2 + 2 * 1fl);

to get the result? At least twice. First time to compute
free space and second time to compute flexes.
That is at best. I don't think that Gecko (as any other UA) has a room
for doubled calc() evaluations.

And as Tab mentioned once it is not clear what calc(10px - 1fl) means
and how to handle this in runtime.

Question to you:
what will be computed min and max widths of this element:

A {  width: calc(10px + 1fl); min-width: 100px; max-width: 300px; }

?

Haven't seen the need of additive flexes ( and calc(A + flex) is additive 
flex )
in 4 years while we are using them. Probably in context of TeX it makes
sense but in CSS...  Mental model of flexes is based on existing algorithms
used in <table>s and <frameset>s.  Developers accept them
almost instantly, proved many times.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Friday, 28 May 2010 06:34:13 UTC