W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css3-flexbox] One final round of bikeshedding on property/value names?

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 18 Apr 2012 12:25:55 -0700
Message-ID: <CANMdWTvDuFwV6e3FaB8s2e=QT9ae0Vu3euokVF=CojUmGuQSfw@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: Alex Mogilevsky <alexmog@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
On Wed, Apr 18, 2012 at 12:05 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> On 04/17/2012 07:31 PM, Alex Mogilevsky wrote:
>> From: fantasai [mailto:fantasai.lists@**inkedblade.net<fantasai.lists@inkedblade.net>
>> ]
>>  Please refer to the original email. There's a lot of points of confusion
>>  around having so many alignment properties. I really feel it is better
>>  for an author to only every have to learn one set.
>>     http://lists.w3.org/Archives/**Public/www-style/2012Feb/0743.**html<http://lists.w3.org/Archives/Public/www-style/2012Feb/0743.html>
>> I think I am open minded to any naming changes, even though I am already
>> used to what we have. I have a couple of issues with what is being proposed
>> though:
>> 1) Switching to generic alignment properties pushes flexbox spec to
>> define generic functionality that is outside of its scope, or makes it
>> dependent on a generic alignment spec, which doesn't exist, and if it
>> existed it would not be anywhere close to LC. It may not be as scary as it
>> appears to me, but if we make this kind of change now we shouldn't even
>> have flexbox LC on the agenda for a while.
> I'm ok with Flexbox defining these properties and stating that behavior
> on other display types is undefined and will be defined in a future spec.
> I also think 'content-align' would be a killer feature for blocks, since
> we've had an open request to allow vertical alignment on blocks' content
> for *years*. But I'm ok deferring it if necessary. (The definition is
> pretty simple: non-auto values turn the block into a BFC, and other values
> shift the content just like in tables.)
>  2) The generic alignment properties and values come from good motivation
>> and have good ideas, but I have not yet seen a set that works smoothly
>> across blocks, flexbox and grid. Some properties get values that are not
>> applicable, some properties get renamed to something far less intuitive.
> I don't think any of the flexbox alignment names are intuitive. That is,
> they're all intuitive, but it's completely unclear to me which is which. :/
>  3) If flexbox uses properties that are meant to be applicable to blocks,
>> any UA implementing flexbox also has to implement box alignment etc. for
>> blocks, tables, etc. That would be awesome, but it won't make it faster
>> either.
> See above.
>  My preference is to keep layout specific properties with "flex-" and
>> "grid-" prefixes. If/when we have a good stable spec for generic alignment,
>> we can deprecate current properties or keep as synonyms. There is a
>> precedent already with "page-break-before:always" == "break-before:page",
>> that's not ideal, but I would rather have more of that make rush decisions
>> now on important features.
> Aliases are horrible, and we should avoid them. Certainly not knowingly
> walk into them.

I agree. The convincing thing for me here is that it's easy to see that we
want things like content-align/box-align on a bunch of other display types.
How they behave in certain edge cases may be open to some discussion, but
I'd be surprised if we needed to chang the name or values we'd want to

> ~fantasai
Received on Wednesday, 18 April 2012 19:26:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:57 UTC