[css-logical] flow-relative ordering

[jonathantneal]

From directly above and including https://drafts.csswg.org/css-logical/#example-368bde23

If four values are set, they apply to the block-start, inline-start, block-end, and inline-end sides in that order.

blockquote {
  margin: logical 1em 2em 3em 4em;
}
blockquote {
  margin-block-start:  1em;
  margin-inline-start: 2em;
  margin-block-end:    3em;
  margin-inline-end:   4em;
}

This ordering seems illogical, especially if the block-first wasn’t logical enough that it would be reconsidered, as opposed to merely swapping out top/right/bottom/left for bs/ie/be/is.

In existing web technology, graphic design, or plotting, the ordering is usually inline (width, X) before block (height, Y). This is found in most forms of printing or plotting design, 2D graphic applications like Photoshop or Gimp, 3D graphic applications Blender or Maya, existing web technology measurements like screen resolutions or DOM / Canvas / SVG offset coordinates. It’s colloquialism likely stems from the 14th century Cartesian coordinate system.

If my “six centuries standard” claim is not too bold, I would recommend the ordering be updated to place inline (width, X) first before block (height, Y), preserving start before end, and then continuing in that clockwise direction:

blockquote {
  margin: logical 1em 2em 3em 4em;
}
blockquote {
  margin-inline-start: 1em;
  margin-block-start:  2em;
  margin-inline-end:   3em;
  margin-block-end:    4em;
}

[tabatkins]

Every single 4-direction CSS property uses the t/r/b/l ordering. This is why we made the logical props do the same thing.

Most (all?) 2-direction CSS properties use x/y ordering. This is inconsistent with the 4-direction properties! In particular, it's inconsistent with what happens when you specify two of the four values in a 4-direction property: you then get y/x ordering! (And this means we can never expand a 2-direction syntax into a 4-direction syntax later, without using a more complicated grammar. 😞 )

So CSS has a single consistent ordering for when you specify 4 values, and an inconsistent ordering when you specify 2 values. 4-direction properties are also more common than 2-direction properties, I think, especially when weighted by usage. Being maximally self-consistent thus demands that we follow the 4-direction syntax, and start with the block axis.

[jonathantneal]

Thanks for the quick response, @tabatkins!

Do I understand correctly that the decision to start with block is because all existing 4-direction CSS properties start with top/block? That’s the way I make sense of “we made the logical props do the same thing”, because I understood the new logical order was not the same, but flipped counter-clockwise, e.g. t/r/b/l.

I really think the CSSWG should reconsider this ordering, due to pre-existent consensus around inline-first clockwise ordering; e.g. left, top, right, bottom. Search the web for this l/t/r/b ordering in other technologies; Android Layout and Windows Blend are examples. Similarly, review mathematical examples of x1,y1,x2,y2. Then, compare those to the same results for the adoption of the currently proposed t/l/b/r or y1,x1,y2,x2. The later is nearly non-existent.

Again, I recognize that the current “non-logical” directions start with block, but.. would you have any other concerns with Cartesian ordering?

[tabatkins]

Do I understand correctly that the decision to start with block is because all existing 4-direction CSS properties start with top/block?

because I understood the new logical order was not the same, but flipped counter-clockwise, e.g. t/r/b/l.

On English and other ltr pages only! In a Hebrew or Arabic page, physical and logical 4-direction properties work exactly the same. ^_^ (But for English, going clockwise would have introduced the bizarre-as-hell block-start inline-end block-end inline-start ordering, which is a no-go.)

I really think the CSSWG should reconsider this ordering, due to pre-existent consensus around inline-first clockwise ordering; e.g. left, top, right, bottom.

This would strongly break consensus with CSS itself, which is a stronger concern than consensus with analogous-but-unrelated technologies.

[bradkemper]

I am strongly in favor of maintaining the clockwise ordering when used in Latin-based languages. CSS has always maintained a Western bias (and American English bias), when such a choice needs to be made. For the majority of authors in the world, even in Asia, bs ie be is would be consistent with how authors write 4-direction-value shorthands already. That should be the most important consideration. I strongly disagree that it is bizarre-as-hell. It should not be dismissed out of hand.

[bradkemper]

My comment is based on not having a time machine to go back and make the original order as l r t b.

[bradkemper]

Optimizing the order for Hebrew or Arabic is bizarre-as-hell.

[tabatkins]

It's... not optimized for RTL languages. Stop trying to make that argument; you can argue without assuming false pretenses.

[jonathantneal]

@tabatkins, hey, thanks so much for your earlier response. I’m still chewing on what you said, and seeing if anyone else has any further interest or insight to provide.

I appreciate you pointing out that 4-value shorthands are block first. I also agree that the current t,r,b,l is really odd when you think of it in the context of block/inline (block start, inline end?). That is a strong argument for block-first counter-clockwise ordering.

What I’m still trying to process is how inline-before-block “breaks consensus with CSS itself”. It seems split; 2-value shorthands are inline-first while 4 value-shorthands are block-first. If you have the time, would you be able to tell me if there are already exceptions to what I’ve just said in (Candidate) CSS? Thanks again for always responding to my weird questions, and I hope I’m not bordering on asking lmgtfy questions.

@bradkemper, I wasn’t suggesting anything was optimized for RTL, either. For me, it’s a matter of creating a consistent inline-first experience between 2-value and 4-value shorthands, and for preserving clockwise ordering. The counter argument is, as I understand it, to standardize on a block-first experience, at least for 4-value shorthands. Does this make sense?

[tabatkins]

What I’m still trying to process is how inline-before-block “breaks consensus with CSS itself”. It seems split; 2-value shorthands are inline-first while 4 value-shorthands are block-first.

Right, only 2-value shorthands are inline-first. The 4-value shorthands are block-first. You were proposing that we make 4-value logical shorthands inline-first, to match some outside technologies; that is inconsistent with CSS, which is clear on where 4-value shorthands start.

I then also noted that CSS is inconsistent with itself with respect to 2 values: properties that only take two values do inline-first, while 4-value properties that you only specify two values for take block-first. We can't fix this pattern in the physical properties, but we can at least make them work consistently in the logical properties.

(Making both 2-value and 4-value logical properties do inline-first would also keep them internally consistent, but the argument in my first paragraph suggests that this is the wrong answer for 4-value properties.)

[bradkemper]

"False pretenses"? I'm not trying to deceive or misrepresent anything. I think you must not be understanding what I am trying to say.

My point is that authors are used to writing those four values in clockwise order from the top. What you seem to want would put it in a different order for the majority of the world's authors, because for LTR authors margin: 1px 2px 3px 4px would yield very different results than margin: logical 1px 2px 3px 4px. I think that is a very bad thing, harder for everyone except RTL authors, and therefore bad for author adoption. I'm saying that we should optimize for author familiarity, and that writing four lengths that are still clockwise from the top for the vast majority of authors is a very, very important consideration that you are not giving enough weight to.

It just seems kind of crazy to me to do it in any other order. There is nothing false about my opinion as I have stated it, so perhaps you have take "optimize for" to mean something other than what I intended.

[tabatkins]

You've claimed in multiple conversations that this ordering is "optimized for Hebrew/Arabic", implying that we purposely chose to match with a particular language for some unstated reason. You know that we didn't do this, and claiming that we did harms the argument.

You can make you claim without resorting to false accusations, as you did in this latest comment. (Thank you for that.)

[jonathantneal]

harder for everyone except RTL authors

Hey @bradkemper, I’d love to understand you correctly. So, are you saying that when we take:

margin: logical 1px 2px 3px 4px;

Which effectively becomes:

margin-block-start: 1px; margin-inline-start: 2px; margin-block-end: 3px; margin-inline-end: 4px;

That RTL authors will experience no change, because those logical properties (in RTL environments) become:

margin-top: 1px; margin-right: 2px; margin-bottom: 3px; margin-left: 4px;

And that RTL authors will gain more benefit with less sacrifice than LTR authors, possibly harming adoption of logical properties?

Please let me know if I have falsely understood your case. I’m just trying to understand.

[frivoal]

introduced the bizarre-as-hell block-start inline-end block-end inline-start ordering, which is a no-go

I don't quite get why this is a no-go. This is no more bizarre than t/r/b/l is for people used to a ltr language, which is the majority of the world.

I know that the proposed order isn't meant to favor anyone over anyone else, but it is consistent with t/r/b/l for rtl language speakers, and inconsistent with it for ltr language speakers. Given than the later is more common, why not go with that?

[bradkemper]

implying that we purposely chose to match with a particular language

@tabatkins get a grip. You are reading too much into what I actually said. I only meant that it ends up being more optimized for LTR than for RTL. That's the end result. I didn't ever imply that this was due to some nefarious intent.