Re: [css-align][css-writing-modes][naming] Another suggestion for block-axis logical names

On Thu, Apr 11, 2013 at 1:57 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> fantasai and I were discussing the logical names today while revising
> Alignment, and we came up with a new idea for logical axis naming that
> we think will be a lot more palatable to people, and makes a ton of
> sense in a lot of different contexts.
>
> The idea is this:  use start/end for *both* axises.  When this would
> be ambiguous, call them block-start/end and inline-start/end.
>
> This has several benefits:
>
> 1. No new names - it keeps us within the existing set of logical
> names, which are already accepted as reasonable.
> 2. Context-sensitive - most properties that use logical directions
> only work in a single axis, so it's not really important whether it's
> block or inline axis.  This suggestion avoids the author having to
> think about it.
> 3. Context-neutral - some properties, such as the Alignment
> properties, can apply to either axis depending on context.  Using
> different names for the block and inline axises makes this hard to
> deal with, as you need to accept both of them in both properties, and
> just map one to the other.  Our suggestion avoids this  - they'll only
> accept start/end, and it'll be the appropriate axis.
> 4. Legacy-compatible - the only current logical properties are
> inline-axis, and they use start/end already, so they'd be unchanged.
> New properties would cleanly slot into this pre-established pattern.
> 5. This suggestion helps us establish a decent short name for the
> axises, so that logical properties can be named appropriately.  For
> example, margin-block and margin-inline would be the margin properties
> for the block and inline axis.
>
> There are only a few draft properties/values that would need naming
> changes.  The most obvious are in Grid - the
> grid-before/after/start/end properties would be renamed to
> grid-row-start/end and grid-column-start/end.  This is not only more
> obvious (I still have to think about which one I want when writing
> examples), but it also follows the shorthand/longhand naming strategy
> more closely, without being too long.
>
> Thoughts?  We're going to go ahead and edit Alignment accordingly
> today, but we can revert if necessary.
>

I would prefer staying with start/end before/after, but I can live with
start/end for both axes if that is the general consensus. However, if
start/end is to be introduced for some property that already has
before/after, then the latter should be retained as aliases for some time
before potential deprecation.