- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Tue, 14 Apr 2009 16:08:20 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Giovanni Campagna <scampa.giovanni@gmail.com>, "Philip TAYLOR (Ret'd)" <P.Taylor@rhul.ac.uk>, www-style <www-style@w3.org>
Tab Atkins Jr. wrote: > Is there a particular reason that a bare * needs to be supported? > Andrew, you keep citing it as a necessity. It does appear to be a > very slight convenience, but that's all. > Actually I am not so insisting on bare *. It just practice that shows that in most cases you will need just '1*'. So ability to use bare * instead is just a nice to have feature for the same reasonings as why we have shorthand properties if we have full set of atomic ones. > I wouldn't be crushed if I had to write "margin: 0 1*;" or "margin: 0 > 1fl;" rather than "margin: 0 *;". > > (With that said, I understand the mnemonic that using "*" as a unit > brings - it evokes the feel of the * wildcard in regexps, in that it > grabs everything that isn't otherwise specified. However, I also > remember that the % unit caused some issues in calc(), leading to the > WG having to adopt "mod" as the modulo function in calc rather than > the more standard % glyph.) > calc() is using its own micro-format that is already somehow isolated from the rest. E.g. '/' inside it means different thing than outside. In any case flexes so far are not applicable inside the calc() by its definition. But if we will come up with the idea how they can be used there then we always can say that they must be used in their canonic form as '1*'. In any case flexes greatly reduce the need of the calc(). In almost all cases calc() expression is better to be replaced by flexes. Flexes umm... flex better. calc() probably will be useful if will come up with something like: height: calc( 1.2em * this.num-of-children ); but this is really another story. > Giovanni Campagna said: > >> Grid Positioning copied that syntax into "grid-columns" >> and "grid-rows", ignoring the existance of a "fr" unit. >> > > IIRC, the "fr" unit didn't exist at that time. Hakon introduced it > relatively recently into GCPM for the border-parts proposal. I > distinctly recall getting into a naming argument then, as I liked the > unit "fl" (from flex) better than "fr" (from "fraction"). > > But seriously guys, this is a tiny, tiny issue about the name of a > unit. It's totally not worth the effort. > Yes the name is not that critical indeed. The thing is that flexes are not dimensional units in the sense of "the length has to be 10mm". Flexes express desire and so by their idea are close to percentage [from free space] so people would expect them to be close to percents by their notation. > ~TJ > > > -- Andrew Fedoniouk. http://terrainformatica.com
Received on Tuesday, 14 April 2009 23:09:08 UTC