- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Thu, 27 May 2010 00:21:58 -0700
- 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 UTC