- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Apr 2025 19:57:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-backgrounds-4][css-borders-4] Should initial value of border-color be sensitive to border-area?`, and agreed to the following: * `RESOLVED: Close no change.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: we added 'background-clip:border-area' to clip out the backgroudn and just show what's under the element<br> <TabAtkins> fantasai: in almost all cases, you want the border color to be transparent<br> <TabAtkins> fantasai: and you want it set possibly conditionally based on whether border-area is supported or not<br> <oriol> q+<br> <TabAtkins> fantasai: currently the initial value is currentcolor; my suggestion was change it to 'auto' and ahve it compute to currentcolor or transparent based on 'background-clip:border-area', so the author doesn't need to worry about it<br> <TabAtkins> jensimmons: this came up when i was making a lot of demos<br> <TabAtkins> jensimmons: it was very easy to forget to change the color<br> <TabAtkins> jensimmons: so there's a question of if css should just be simple and consistent. but it was a consistent stumbling block to remember to change it every time.<br> <TabAtkins> jensimmons: so i think this would really help devs use this feature<br> <astearns> ack oriol<br> <fantasai> jensimmons: would make it more streamlined and easy to use<br> <TabAtkins> oriol: I'd prefer not to. it seems unexpected.<br> <TabAtkins> oriol: also, background-clip has multiple values, a list of backgrounds<br> <jensimmons> Developer experience wins over theoretical purity.<br> <TabAtkins> oriol: not clear if some layers have the clip and others clip differently, if it should happen<br> <florian_irc> q+<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to reply to that<br> <TabAtkins> oriol: i don't think it's a big problem for authors, especially if they can just specify #0000<br> <TabAtkins> fantasai: for multiple layers, i think it would be if any of the layers have border-area clip<br> <TabAtkins> fantasai: it demonstrates the author *is* thinking about the border area<br> <astearns> ack florian_irc<br> <TabAtkins> fantasai: if they *do* want a specific border, they almost always set the color explicitly anyway<br> <TabAtkins> florian_irc: reason it's confusing when you don't have it?<br> <TabAtkins> jensimmons: if the border has a color, it's probably opaque<br> <TabAtkins> jensimmons: if you use 'border-area' you're putting an image there, you expect it to show<br> <TabAtkins> jensimmons: but the border paints over it<br> <TabAtkins> jensimmons: a lot of authors might not expect that the border always exists and always has a color<br> <TabAtkins> jensimmons: so as soon as you use this property, you set a 10px border and set a background-image with border-area clip<br> <TabAtkins> jensimmons: but it doesn't work, it's all black or something<br> <florian_irc> I'm convinced<br> <lea> same<br> <TabAtkins> jensimmons: i get the theoretical purity argument, but i also believe in teh priority of constituencies<br> <fantasai> TabAtkins: when you're setting these up, Jen, if I'm correct about this the initial border style is 'none'.<br> <fantasai> TabAtkins: you already have to set width and style<br> <fantasai> TabAtkins: having to say 'border: solid 10px #000' adding the color doesn't seem that big of a deal<br> <dbaron> "5px solid transparent" works too<br> <lea> q?<br> <lea> q+<br> <fantasai> TabAtkins: If you could get the desired result with just the width... but you already have to say the style<br> <jensimmons> Demo of this for reference: https://codepen.io/jensimmons/pen/rNXZvQG<br> <fantasai> jensimmons: Different people write differently<br> <astearns> ack lea<br> <fantasai> lea: There's two core use cases here.<br> <fantasai> lea: one is adding a border that's an image to something that doesn't have a border<br> <fantasai> lea: second is when you change styling of something that already has a border<br> <fantasai> lea: in the first case, yeah, no big deal to add transparent<br> <fantasai> lea: but if you're restyling something that already has a border<br> <fantasai> lea: the only thing you want to change is border color<br> <fantasai> lea: although... this would help anything there because about initial color<br> <fantasai> TabAtkins: if you're setting border, already setting color<br> <astearns> ack dbaron<br> <fantasai> dbaron: I was just thinking what would we do if we did want to do this<br> <fantasai> dbaron: We'd need to introduce a new keyword for border-color that computes to currentColor sometimes and transparent sometimes<br> <fantasai> dbaron: and make that the initial value<br> <lea> q+<br> <fantasai> dbaron: and decide how to reflect in getComputedStyle<br> <fantasai> fantasai: colors return as resolved color<br> <fantasai> dbaron: but then specified style, might create values that aren't expected in the OM<br> <fantasai> dbaron: Not insurmountable, but if we want to do that there are some risks<br> <lea> q-<br> <fantasai> dbaron: so that's another thing against it<br> <lea> q+<br> <TabAtkins> The other argument against that was raised in the thread is we don't default text color to 'transparent' when using 'background-clip:text' today, so there's another argument for consistency there.<br> <fantasai> ntim: I don't think that's a significant risk, because if you're using background-clip: border-area, you can likely deal with the border-color being a new keyword<br> <fantasai> dbaron: that keyword would be the initial value, so would show up in OM<br> <fantasai> astearns: For the specified value which is much less accessed than the computed value<br> <TabAtkins> (Tho it was pointed out that we really *couldn't* do that, since 'color' affects more than just text.)<br> <lea> q-<br> <fantasai> dbaron: yes, but still exists<br> <fantasai> lea: I see the appeal of being able to say `border: 2px solid; background-clip: border-area` it just works<br> <kizu> q+<br> <fantasai> lea: though in that case `solid` is a bit redundant, people almost never want other styles<br> <TabAtkins> lol, yeah, the 'border-*' initial values are kinda badly designed<br> <TabAtkins> we've run into this beforee<br> <dbaron> "border: 5px" is the same as "border: 5px none" !<br> <fantasai> lea: but the complexity dbaron mentioned seems not worth the small improvement in UX<br> <astearns> ack kizu<br> <fantasai> kizu: I also wanted to add a bad idea.<br> <fantasai> kizu: What if border had a value that enables background-clip?<br> <fantasai> lea: what if border-shorthand could turn on background-clip: border-area. But not a good idea.<br> <fantasai> lea: border shorthand shouldn't set background properties<br> <fantasai> lea: and also you usually want to set multiple things, not just image<br> <fantasai> ntim: Could have border-style: auto; and auto would be invisible border<br> <fantasai> TabAtkins: having border-style have a new value, since you have to set it anyway<br> <fantasai> TabAtkins: border-style: auto; if any background colors are border-area, set color to transparent, otherwise set to solid<br> <fantasai> florian_irc: but you can't make that the initial value<br> <fantasai> florian_irc: if you could, might be interesting<br> <kizu> `border: 5px auto`<br> <fantasai> TabAtkins: Interesting because you have to set the border-style. Jen is trying to avoid setting border-width, border-style, *and* border-color<br> <oriol> +1 to floarian<br> <fantasai> florian_irc: yes, but you have to *remember* to set this value -- and in that case, you might as well remember to set it to transparent<br> <astearns> +1 to florian_irc<br> <fantasai> florian_irc: The problem she wants to solve ins't typing transparent, it's having to remember to set transparent<br> <fantasai> astearns: so seems too risky to do, even though maybe nice<br> <fantasai> ntim: not sure it's too late, e.g. we changed initial value of border-color<br> <fantasai> dbaron: yes, but from magic that's the same as currentColor to the actual currentColor keyword<br> <fantasai> kizu: Useful for ??<br> <fantasai> kizu: E.g. using transparent border when making a border that later becomes visible<br> <fantasai> kizu: just having that in the shorthand would be useful<br> <TabAtkins> TabAtkins: so not a conditional transparency, jsut a value that gives the border geometry but always paints transparent<br> <fantasai> astearns: shall we resolve no change?<br> <TabAtkins> fantasai: but i think that doesn't help us, when you do want to paint it you'll have to change the color *and* the style<br> <fantasai> jensimmons: seems we have no choice<br> <fantasai> astearns: objections?<br> <fantasai> RESOLVED: Close no change.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10907#issuecomment-2776788031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 April 2025 19:57:19 UTC