[css-logical] Interpretation of two values in logical border-X-Y-radius properties for vertical writing-mode is illogical

[Rolf-B]

When I specify something like border-start-start-radius: 1em 2em; in horizontal-tb writing-mode, the first value is used for the horizontal axis. That is: the inline axis.

When I switch to a vertical writing-mode, I would expect that the first value is still applied to the inline axis. But that is not the case, it is still applied to the horizontal axis. This seems illogical to me. I find no comment about that behaviour in the spec.

I am an European, not Chinese, Japanese or Korean, so I don't know if this is really an issue for these writing-modes. But it seems illogical to me that the two value syntax of a logical property maps its values to physical directions, not to logical directions. If this is intentional, maybe the spec should list the reasons for that.

[Loirooriol]

It's like that because logical and physical properties share a computed value.

Now it may be too late to change the behavior, but some ideas:

• Turn these into shorthands, so e.g. border-start-start-radius: 1em 2em would expand to border-start-start-radius-inline: 1em; border-start-start-radius-block: 2em, and then in a ltr vertical-lr wm map these to border-top-left-radius-y: 1em; border-top-left-radius-x: 2em, equivalent to border-top-left-radius: 2em 1em.
• Make the computed value more complicated, e.g. <length-percentage> <length-percentage> logical?. The logical keyword would not be part of the grammar, it would just be an internal flag set when the value came from a declaration for a logical property. Depending on this flag, layout would treat the values as horizontal and vertical, or inline and block. Serializing the computed value could produce empty string if the property doesn't match the flag, or check the wm to reorder the values.

[css-meeting-bot]

The CSS Working Group just discussed [css-logical] Interpretation of two values in logical border-X-Y-radius properties for vertical writing-mode is illogical, and agreed to the following:

• RESOLVED: Adopt option 2 (an internal flag to track whether the value was set by the logical property or the physical one, and use that serialize propertly)
• ACTION: Check for use of elliptical border-radius in logical longhands

The full IRC log of that discussion

<fantasai> oriol: Wrt border-radius properties
<fantasai> oriol: They accept 2 values, the horizontal and vertical components
<fantasai> oriol: This works well for physical properties
<fantasai> oriol: But then we added the logical longhands that share a computed value with them
<fantasai> oriol: Since the logical and physical properties share a computed value, the ordering needs to be the same
<fantasai> oriol: Which implies that the logical properties use physical ordering, which is quite nonsensical
<fantasai> oriol: In the issue I proposed 2 possible ideas
<fantasai> oriol: one would be turning each one of these longhands into a shorthand
<fantasai> oriol: then we could map in the right way
<fantasai> oriol: though we would be adding 8 new physical longhands and 8 new logical longhands, so a lot of properties
<fantasai> oriol: another idea would be to make the computed value more complex
<fantasai> oriol: Instead of just 2 length-percentages, we could add an optional flag
<fantasai> oriol: this wouldn't be in the grammar of the properties, so authors wouldn't be able to specify it
<miriam> q+
<fantasai> oriol: but we would store this flag based on whether the value came from logical or physical properties
<fantasai> oriol: And then the browser could serialize accordingly as well
<fantasai> oriol: this would avoid adding new properties
<fantasai> oriol: of course both of these ideas may suffer from web-compat
<fantasai> oriol: so we may need to check
<fantasai> oriol: If we say that for the logical ones the first component is inline and second is block, then that matches what happens with a horizontal writing mode
<fantasai> oriol: even though it wouldn't match other properties like grid properties, which are block component first
<fantasai> oriol: but that might be better for web-compat
<fantasai> oriol: if we do it this way, in cases where authors specify two values that differ in vertical writing mode, may change
<astearns> ack miriam
<fantasai> oriol: could do a counter
<fantasai> miriam: I want to solve this.
<fantasai> miriam: we have a bigger issue about all logical shorthands and how to solve those
<fantasai> miriam: current plan on that issue which is stalled for years
<fantasai> miriam: but also to start with making sure we have all the longhands, and solve some shorthands for logical properties across the board
<fantasai> miriam: I would like to see this solved along with the others
<fantasai> miriam: if this is the one that starts it, great, let's move it forward
<astearns> ack fantasai
<TabAtkins> fantasai: i think adding 16 new longhands to control the individual components of each corner is overkill
<TabAtkins> fantasai: i dont'; think anyone wants to cascade those independently
<TabAtkins> fantasai: so preference is second option, an internal flag
<TabAtkins> fantasai: i don't think this does anything to solve the larger problem of merging physical and logical shorthands, that's independent
<TabAtkins> fantasai: tho i'd like to sovle that too
<miriam> q+
<TabAtkins> fantasai: so i think having an internal flag and having UA use the flag to reorder for serialization is good
<TabAtkins> astearns: more detail on why it's a seaprate problem?
<oriol> I agree they are different problems
<TabAtkins> fantasai: the thing we're stuck on the most is how do you have a shorthand syntax like 'margin' that sets both physical and logical longhands
<TabAtkins> fantasai: what syntax will tell you whether you're setting physical or logical
<TabAtkins> fantasai: but we're not tackling that here
<TabAtkins> fantasai: each of the properties here are either physical or logical
<TabAtkins> fantasai: there's a confusing bit internally, we're storing physical pairing in a logical proeprty, that's what's causing the problem
<TabAtkins> fantasai: so i think the second option is the correct one
<astearns> ack miriam
<TabAtkins> miriam: i understadn the distinctions
<TabAtkins> miriam: don't know there's a dsitinction in the solutions
<TabAtkins> miriam: some of the other proposals also involve a logical flag in some way
<TabAtkins> miriam: i'm curious if these will interfere
<TabAtkins> fantasai: i don't think they would
<TabAtkins> fantasai: one of th ekey blockers is figuring out the syntactic flag and where it might occur
<TabAtkins> fantasai: but the author, at some point, has to indicate they're doing logical instead
<TabAtkins> fantasai: this isn't a case of that, we already know what the author is setting (it's in the name)
<TabAtkins> fantasai: we just need the browser to internally store the correct info
<TabAtkins> fantasai: and just to be clear, this is a magic flag not exposed to the author. can't read or write it, just an internal browser accounting mechanism
<TabAtkins> astearns: so Oriol's proposal is to make the computed valu emore complicated, but this isn't exposed?
<TabAtkins> fantasai: yes, not getCpomputedStyle() value, that's the serialization
<TabAtkins> fantasai: we just use this flag to know how we should serialize
<TabAtkins> astearns: do we have other instances where we have details not represented in the property
<fantasai> fantasai: I believe we do, I feel that we have discussed this kind of thing before
<TabAtkins> oriol: in webkit, i did something like this for -webkit-border-image
<TabAtkins> oriol: when i made it a shorthand it sets one fo the standard longhands into a value that can't be represented by its grammar
<TabAtkins> oriol: it has some special layout behavior, and in serialization you produce the empty string
<TabAtkins> oriol: not sure about other browsers
<TabAtkins> astearns: so proposed reoslution is to go with option 2?
<TabAtkins> fantasai: yes
<TabAtkins> astearns: objections
<TabAtkins> RESOLVED: Adopt option 2 (an internal flag to track whether the value was set by the logical property or the physical one, and use that serialize propertly)
<TabAtkins> fantasai: Oriol mentioned that because the current behavior is a physicla mapping in a logical property, in most of our logical properties we have block axis first, inline second. but in physical properties we ahve horizontal first and vertical second
<TabAtkins> fantasai: so in horizontal writing mode, if you write `A B`, depending on whether it's physical or logical it'll map to opposite axises
<TabAtkins> fantasai: because we've been using the physical ordering in these logical properties, it means currnetly for English they match.
<TabAtkins> fantasai: aka it's "inline block" order
<TabAtkins> fantasai: so there's a bit of compat issue. if we want to match existing behavior as closely as possible, with the understanding that these proeprties are super rarely used in a way that exposes this (elliptical corners)
<TabAtkins> fantasai: if it's used widely enough (enough people doing elliptical radiuses using logical properties), we'd have to make an exception for the border-radius proeprties and have them take this inline-block ordering
<fantasai> TabAtkins: We're trying to get logical ones to match our normal block-then-inline ordering
<fantasai> TabAtkins: but chance that compat might restrict
<fantasai> astearns: another archive query?
<fantasai> TabAtkins: counter?
<fantasai> fantasai: Could do archive query. Because vertical text x elliptical curves is so rare we can ignore
<fantasai> ACTION: Check for use of elliptical border-radius in logical longhands
<dbaron> are they implemented
<TabAtkins> oriol: they're implemented, chrome metricss say 11%
<fantasai> TabAtkins: no way, that's impossible
<fantasai> TabAtkins: those things also get triggered by feature tests so... need to look into it
<oriol> https://chromestatus.com/metrics/css/popularity#border-start-start-radius