[css-logical] Should the mapping for logical values depend on the element or containing block?

[Loirooriol]

https://drafts.csswg.org/css-logical/#float-clear says

The mapping on these properties uses the writing mode of the element’s containing block.

However, on Firefox the mapping depends on the writing mode of the element itself. I didn't read the spec carefully when implementing logical values in Blink, so I ended up copying the Firefox behavior. web-platform-tests/wpt#12326 tests the implemented behavior and not the spec one.

Instead of fixing both implementations and WPT, maybe consider changing the spec?

This would be consistent with the previous change that made the mapping for logical properties depend on the writing mode of the element instead of the one of the parent element.

csswg-drafts/css-logical-1/Overview.bs

Line 731 in 206498e

<li>Making all properties cascade using the <a>writing mode</a> specified on the element, not on its parent.

[emilio]

The containing block is a layout concept, so the style engine doesn't necessarily have that information. I'd prefer not to teach the style system about containing blocks, I think the spec should be changed here.

[fantasai]

We have an outstanding resolution on this, I guess it just didn't make it into the spec (which is has in general been quite neglected). I'll be spending some time on it the next few days, though, so outstanding resolutions should get edited in soonish. :)

[fantasai]

Oh, sorry, thought this was about the logical properties. Those compute against the element's own writing mode always, for simplicity during cascading and style computation and because it wasn't entirely clear where to draw the boundary between “this is best computed against the CB writing mode” and “this is best computed against the element's own writing mode”: at the border edge? the padding edge? the content edge?

For logical values, it does depend on the property whether the containing block or the element itself is referenced. For example, the start and end keywords on align-self (which aligns the element in its containing block) use the containing block, so that when you set alignment on a bunch of items they are consistently aligned regardless of writing mode. The self-start and self-end values allow to reference the element itself. However, text-align and align-content, which align an element’s content within itself, reference the element's own writing mode, since the containing block's writing mode would be irrelevant.

Floats are more similar to align-self and justify-self, so I think they should compute against the CB. Typically you don't want the float to float differently based on its own contents, but rather on the writing mode of its context.

@emilio Logical values don't compute through to physical ones, so the style system doesn't need to know about it.

[Loirooriol]

Logical values don't compute through to physical ones

That's not clear: #2821

[fantasai]

@Loirooriol Yes it is, the propdef tables for those properties say “Computed value: as specified”. That means the values do not compute through. This is important because (as you point out) it would break inherited properties to do otherwise.

[FremyCompany]

I agree with @fantasai here:

1. if you specify "start" your children should inherit "start", as the style system doesn't care about containing block
2. however what "start" means sometimes can only be understood in the context of the containing block when you are doing layout, so its value should be preserved untouched until then.

It is kinda unfortunate implementations did something else here.

[Loirooriol]

the propdef tables for those properties say “Computed value: as specified”

@fantasai But the propdef tables for those properties don't include the logical values, so it's not clear. The partial propdef table in CSS Logical with the new values should repeat “Computed value: as specified”

[fantasai]

@Loirooriol Fair, fixed in f3953ed for #2821.

[css-meeting-bot]

The Working Group just discussed Should the mapping for logical values depend on the element or containing block?, and agreed to the following:

• RESOLVED: Accept proposal

The full IRC log of that discussion

<dael> topic: Should the mapping for logical values depend on the element or containing block?
<dael> github: https://github.com//issues/3013
<dael> fantasai: Question was about should hte mapping for logical values depend on element or containing block. Not about logical properties, but values like float inline start or text-inline-start
<dael> fantasai: First thing is currently the spec...it was stated values compute to themselves. That's first question. Second is do you map against containing block or element.
<dael> fantasai: Supposed to depend on kind of element. test-align:start needs to map against element. For alignment we use containing block so makes sense to do same for float b/c you don't want element to move based on content, but rahter context
<dael> fantasai: Proposed is no change to spec but clarify the values map to themselves
<dael> fantasai: I copied that in. Does anyone else have comment?
<dael> Rossen: Question. There are...all properties in box model, are they defined to resolve against own writing mode?
<dael> fantasai: Yes own. It was sometimes correct and because you have to do computation of writing mode with cascade it's much easier computation.
<dael> fantasai: It's unfortunate that's t he case because there's a lot of cases to use containing block writing mode for something like margins but we did element's own writing mode for simplicity.
<dael> fantasai: Don't have same problem for values as they resolve at layout time
<dael> fantasai: We should have down issue 3 first as it talks about computed
<dael> [logical properties issue 3, not agenda issue 3]
<dael> Rossen: Other opinions?
<fantasai> #2821
<dael> Rossen: I asked about box model props because they are used for aligning box and sometimes used to align content inside. Align self and content align properties and values are very similar in layout impact so one doing self and the other containing block is weird.
<dael> fantasai: align self:start you use containing block, align-self:self-start you use your own writing mode
<dael> fantasai: text-align:start your children is what's being aligned.
<dael> Rossen: Get it. Not making case against it. In same virtue you can say position left and right can be used to align self and padding start and end can align content box. Fromm that PoV they are similar.
<dael> Rossen: For box model all properites and values compute to writing mode of element itself
<dael> Rossen: There is discontinuity here
<dael> Rossen: Can live with it.
<dael> Rossen: Other opinions or resolve on proposal to have values that effect alignment compute in containing block. Value effect alignment of content of a box o f an element are computed in writing mode of element itself
<dael> fantasai: That's what's spec in grid, flexbox, and alignment
<bradk> +1
<dael> RESOLVED: Accept proposal