W3C home > Mailing lists > Public > www-style@w3.org > May 2010

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

From: Zack Weinberg <zweinberg@mozilla.com>
Date: Fri, 28 May 2010 09:26:29 -0700
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "W3C Emailing list for WWW Style" <www-style@w3.org>
Message-ID: <20100528092629.3cf815a1@moxana.local>
"Andrew Fedoniouk" <news@terrainformatica.com> wrote:
> >
> > 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

Oh.  You're looking at Appendix G.  Appendix G is NOT
the generic syntax.  The generic syntax is here:
http://www.w3.org/TR/CSS21/syndata.html#tokenization

and the relevant bits are

NUMBER 		{num}
PERCENTAGE 	{num}%
DIMENSION 	{num}{ident}

declaration : property S* ':' S* value;
value       : [ any | block | ATKEYWORD S* ]+;
any         : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING
              | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
              | DASHMATCH | ':' | FUNCTION S* any* ')' 
              | '(' S* any* ')' | '[' S* any* ']' ] S*;

(Maybe I should have said "core syntax" instead?)  Anyway, the
Appendix G grammar can be, and indeed already has been, modified
by Level 3 modules, but the section 4 grammar is not supposed to
change, and 

   top: 2*;

is not a valid 'declaration' per the section 4 grammar.

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

No more nor less than with your proposal.  You constant-fold it to
calc(5px + 2fl), which is exactly as hard to evaluate as flex(5px, 2fl).
In other words, from my perspective, allowing fl inside calc() is just
syntactic sugar for your proposal.

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

I am not especially familiar for the rules for what happens if width,
min-width, and max-width are mutually contradictory.  Naively, I'd
expect that to mean the same thing as 

  A { min-width: 100px; max-width: 300px; }

I do not see that flexes make resolving such contradictions any harder
than it already is, regardless of their semantics.

zw
Received on Friday, 28 May 2010 16:27:04 GMT

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