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


[fantasai:]
> 
> On 04/17/2012 07:31 PM, Alex Mogilevsky wrote:
> > From: fantasai [mailto: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

> >
> > 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.

In other words, Flexbox would define a set of general properties that specs we 
haven't yet written will then define for other display types. How much work have 
we done to establish these properties can in fact be usefully generalized and 
implemented? Is it necessary or beneficial to hold up flexbox until we've done so?

> 
> 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.)

I'd rather have the flexbox module define flexbox, grid define grids etc.
Then, based on both implementation and real-world usage experience, derive 
those common properties and values that do in fact matter in practice. The 
premature definition of generic types and functionality can also create problems 
down the road, however a good idea it may seem at the time.
> 
> > 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. :/

Fair enough. But I think we need to pay attention to naming much earlier in our
design process. Significantly renaming an API late into its design is not good 
practice; that we would do so to ensure future alignments that have yet to be 
defined is riskier as well. In general, the later we change names for 'consistency' 
or 'readability' the more likely we are to end up with 2-3 'experimental' 
implementations using the old names and/or syntax, then 1-2 experimental or 
standard implementations using the new names/syntax and developers stuck in the 
crossfire until everyone is in sync again. Which may take a while if the first 
iteration achieved traction (e.g. Gradients). Alternatively, implementors may find 
themselves shipping both prefixed and unprefixed variants of the same feature to 
cope with the confusion (as will likely happen for gradients in IE10). This is not
sustainable.

Thankfully, flexbox is not gradients and we're not calling the feature unreadable 
despite its successful deployment on thousands of web sites. But the current naming 
has been around for quite some time; for some of us, it is not only implemented but 
large numbers of developers are successfully using it to lay out UI every day. 

Naming and terminology are *very* important. So important it's something we need to
stabilize as early as practical so as to build on it and leave it alone thereafter. 
Around LC or even 3 months before it is just too late for bulk-renaming an entire
set of closely related properties imo. At the very least, a strong case must be made
to prove the benefits worth the costs. The potential for future consistency with
specs no one is writing yet should not be sufficient.

> 
> > 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'd like to avoid aliases too. I'd also like to avoid the kind of feature creep 
that could result from over-generalizing from two display types.

Received on Wednesday, 18 April 2012 22:50:26 UTC