[css-backgrounds][css-grid][css-logical] 2-axis positions vs. 4-direction shorthands

So Tab and I keep on mixing up which axis goes first whenever we're working
with the 2-axis properties (like background-position, grid-template, etc.).

Our initial assumption is that the block axis is first, and the inline
axis is second, because that's what the margin/padding/border properties
do. But actually, background-position (and border-spacing) specify the
x coordinate first and the y coordinate second, and so we made e.g.
grid-template specify columns first, then rows, by mapping through English.

But this gets us to the very confusing situation of

   grid-template: <grid-template-columns>/<grid-template-rows>
   grid-area: <grid-row>/<grid-column>

We're also working on a 2-axis alignment property (and logical bgpos)
which take (simplified)
   [ start | end | center ]{1,2}
and it seems more natural to expect the block axis first.

If we could go back in time, I think we'd argue to Bert and Håkon that
2-value background-position should match 2-value margin shorthands, but
failing that, we have some awkward inconsistencies in CSS no matter what
we do.

The question before us now is, what's the worse inconsistency? :)
A. Splitting the bucket so that
   block/inline => grid-area, margin, padding, border, offset, [ other 4-value ]
   inline/block => grid-template, background-position, scroll-snap-align, [ other 2-value ]

B. Or making logical coordinates always block, then inline, even though
physical coordinates in background-position are horizontal, vertical?
   background-position: start end; /* block, inline */
   margin: 1em 2em relative;       /* block, inline */

[Personally, I think I prefer the second solution, because it's easier
for me to remember whether I'm in logical space or physical space than
to remember that certain 2-value declarations are inline/block while
others are block/inline. But I'm not sure what other people might think.]

~fantasai

Received on Sunday, 25 October 2015 03:53:43 UTC