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

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

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Thu, 27 May 2010 00:21:58 -0700
Message-ID: <EF589BC8D4814994B84368E79572079B@terra3>
To: "Zack Weinberg" <zweinberg@mozilla.com>
Cc: <www-style@w3.org>

--------------------------------------------------
From: "Zack Weinberg" <zweinberg@mozilla.com>
Sent: Wednesday, May 26, 2010 10:37 PM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <www-style@w3.org>
Subject: Re: [flex-units] unit abbreviations and the flex()

> "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
> 
>> Referring to http://www.xanthir.com/:wih document.
>> 
>> I don't think that 'fl' is particularly good name for flex units.
>> One of the reasons is that character 'l' is very close 
>> to either 'I' or '1' in most of fonts in use for development.
>> 
>> I think that something like 1fx is better.
>> 
>> But I would like community to consider '*' (star) as a flex unit 
>> designator.
> 
> Can't be done; '1*' is not a DIMENSION token.  '1fl' is readable enough
> in my opinion, but I wouldn't object to '1fx'.

True, but flex units are not dimensions. 
In the same sense as PERCENTAGE is not DIMENSION.

Existing syntax just needs these two updates:

PERCENTAGE	::=	num '%'
FLEX	                ::=	num '*'


any        : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING | FLEX
              | DELIM | URI | HASH | UNICODE-RANGE | INCLUDES
              | FUNCTION S* any* ')' | DASHMATCH | '(' S* any* ')'
              | '[' S* any* ']' ] S*;


I do not see any problems with this, do you?

> 
> I have no strong opinion on any of the rest of what you say, although I
> think that it would be better to arrange things so flex units can
> participate in calc expressions, than to introduce a new function.
> 

Full form of flex unit value is a triple of flex-strength, min and max
constraints. Additive flexes have one more "preferred" value so it 
is a quadruple. I do not see any sense of trying to fit flexes inside
the calc() while anyway you know that you will need full form at 
some point. E.g. you may wish to define something like
 border-spacing: flex(*, 0, 10px) 
to implement  box-pack:justify in more configurable fashion
then you have in XUL at the moment.

In any case you will need to deal with possibility of 
negative flexes like here 
   calc( (10 - 10em/10%) * 1fx )
I do not think that Gecko as any other existing UI has 
any room for implementing algebraic analysis of calc 
expressions to split them on fixed and flex parts for separate
calculations.

-- 
Andrew Fedoniouk

http://terrainformatica.com





 
Received on Thursday, 27 May 2010 07:22:31 GMT

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