RE: [css3-flexbox][css3-align] start/end vs. before/after


[fantasai:]
> 
> On 05/19/2012 01:44 PM, Chris Jones wrote:
> > I think this is where the root of the issue lies - from my perspective,
> it doesn't make sense to say that the Grid has a main or secondary axis.
> AFAIK, there's nothing in the spec that specifies one or the other as
> being primary vs. secondary, and there's nothing in the functionality of
> the grid that suggests one is any different than the other.
> >
> > If someone can point to something that illustrates how Grid column
> alignment is functionally different from row alignment, that might be the
> basis for an argument that they should have different terminology. Absent
> that, however, I think François' argument about minimizing the syntax a
> developer or author has to remember is what we should follow.
> 
> While the Grid spec might treat alignment in both dimensions equally,
> there is still an "inline" dimension and a "block"
> dimension that both Grid and Block layout pay attention to.
> It's imho a Very Bad Idea for Grid to use different terminology than block
> layout for its alignment values.
> 
> You can argue that "because Grid's layout is dimension-agnostic, its
> alignment keywords should be equivalent in both dimensions"
> but then you'd either have to diverge from the alignment properties in
> block layout, or insist that alignment keywords in block layout should be
> inconsistent with 'float', 'caption-side', etc.
> 
I agree that it is not a good idea for CSS specs to use different terminology
to control the same type of operation. (And, like you, I'm not that concerned
about XSL-FO either).

Given the choice though, I prefer a model where the alignment axis is defined 
by the property name, with identical values for both directions. I just do not 
see the benefit of also having a different set of values. If I tell you 'this 
paragraph comes after this one' and 'this word comes before that one in the 
sentence' you know where to look in both cases. That's true with start end as 
well i.e. 'The word at the end of this sentence' and 'The paragraph at the start
of the page' are not ambiguous because the context is explicitly stated. The 
property name should imo be sufficient to establish that context. I believe this 
would be much easier to learn and use, at the least.

That this might be inconsistent with a few existing properties is never fun but it
shouldn't be a goal to just be consistent with the past. I'd rather move future
properties to a new, more usable consistency with some legacy exceptions (which we
could add aliased values to) rather than keep a confusing historical convention. 

And a convention that remains confusing to people who follow this list should be
a concern and candidate for change.

Received on Monday, 21 May 2012 17:03:24 UTC