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

On 05/21/2012 10:02 AM, Sylvain Galineau wrote:
>
> [fantasai:]
>>
>> 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.

In CSS, before/start/after/end forms a set of directions in two axes the same way
top/right/bottom/left does. If these properties and their names were physical,
we wouldn't be having this argument because it wouldn't make sense to use left/right
in the vertical direction. But since the flow-relative terms are a fairly arbitrary
set using ambiguous names, from an English perspective, either pair of terms works
for either dimensions.

However, because we need a logical set of directions, and there are many places in
CSS where we need four distinct terms, we've established a convention for these four
terms: start/end works in one axis, and before/after works in the other. It's a
somewhat arbitrary distinction. For it to be usable, for it to become a convention
of four directions and not an arbitrary collection of two-directional keywords, we
must be consistent, and not use e.g. before/after in 'text-align', or use start/end
for the top/bottom equivalents of 'caption-side'.

If we use start/end/before/after consistently everywhere else in CSS, with start/end
in the inline direction and before/after in the block direction, but break that
convention here only for the alignment properties, we are not serving our users well.
Yes, start/end are nicer keywords... and for this particular situation, the property
gives enough context that we only need two terms, not four, so we can pick the nicer
keywords in both dimensions. But once you look at the *rest* of CSS, and have to
deal with 'float' (which needs all four), 'caption-side' (which also uses all four),
or consider adding logical properties, or logical values to 'background-position'
(which will require using all four), it breaks the convention. It becomes the one
place in CSS where "start" means "before", and not "start". It becomes the one place
where, to control things along the block axis, I have to use "start" vs. "end" rather
than "before" vs. "after".

It's not about existing properties. It's about the future. We don't have any
CR-released syntax that uses before/after. We could, in fact, change before/after
globally to something else at this point. But we can't change it globally to start/end,
so let's not start trying now, because that attempt will fail as soon as it hits any
2D controls.

~fantasai

Received on Thursday, 24 May 2012 04:34:16 UTC