Re: [csswg-drafts] [css-logical] Interpretation of two values in logical border-X-Y-radius properties for vertical writing-mode is illogical (#9217)

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`

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9217#issuecomment-2770652825 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 1 April 2025 20:50:08 UTC