Re: [css3-flexbox] Best way to denote flexible lengths

On Fri, Apr 15, 2011 at 9:09 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
>> Currently I have padding (and margin) not take flex values; they simply
>> take 'auto', which is treated like 1fr.  Is that okay?
>
> Ah, right. I have concerns with applying flexibility to padding to begin with, so less is better.

How do you feel about removing flexible padding, and instead speccing
a 'box-align' property, as was discussed a few years ago?


> I was confused however by the first paragraph of section 5:
>
>        "Flexible lengths can be used for the ‘width’, ‘height’,
>        ‘padding’, and ‘margin’ properties..."
>
> In your current model padding does have flex, but doesn't take flex(). It will be a challenge to describe in a way that won't confuse more people. Which may mean that there is inconsistency in the model and they should either take flex() or not be mentioned in the same sentence with 'width'.

Yeah, I think that's just leftover text.  I'll need to reword that.


> For implementation it will be no more difficult to implement padding:flex() than padding:auto. I think the reason we wanted to just use 'auto' was that it would eliminate the need for flex() function altogether. If flex() does in fact apply to only width and height, there are ways to express that with properties without property explosion or new values...

Nah, we went for auto margin and padding so we wouldn't have to track
an additional 16 values per element (each relative flex is 3 values,
times 4 padding and 4 margin properties, minus the one value per you
already have to track).

As I've said before, I feel very strongly that it's confusing to
authors to have the flexibility separate from the box-model property
it applies to.


>> > It may be a good idea to not allow flex(1 auto 0). It is just weird. Can
>> we say that if there are two non-negative numbers they must be together? I
>> think there is precedent in background shortcut property.
>>
>> I agree that it's weird, but I don't think there's a strong reason to
>> disallow it.  I can if you feel strongly about it, though.
>
> It will be easy to define if you use the same pattern as background shorthand property. http://www.w3.org/TR/css3-background/#the-background
>
> If flex() can take space separated flexibility and size, and flexibility is one or two numbers, then the weird sequence is not allowed.

Okay, I'll make the edit on Monday.


>> > For unitless length, it may be OK to require '0px'. It can also be
>> defined that if there are 3 numbers, the last one is the preferred length
>> (then the first two are never ambiguous).
>>
>> Sure, we can do that, but then values like flex(0 1 1), which are
>> potentially unambiguous, would be invalid.  Is that okay?  If so, then
>> I'll go ahead and change the description to allow it.
>
> Yes, flex(0 1 1) would be invalid and I like that.

Ok.

~TJ

Received on Saturday, 16 April 2011 05:06:57 UTC