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