- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Jul 2018 00:22:24 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Issues for listifying border-color`, and agreed to the following: * `RESOLVED: Add stripes() to border-color and outline-color` <details><summary>The full IRC log of that discussion</summary> <myles> Topic: Issues for listifying border-color<br> <myles> Github: https://github.com/w3c/csswg-drafts/issues/2532<br> <myles> leaverou: There’s a very detailed write up in the issue of everything I’m going to say<br> <myles> leaverou: Do people remember the issues with listifying border-color? A few meetings ago, we resolved to listifying border-colors, because 1) Authors wanted multiple borders, but primarily a11y needed borders that are both white and black so that they are visible over any background. So we listifying border-color with the goal of listifying alt he border properties<br> <myles> leaverou: BUt when I actually tried to listifying border-color, there were several issues.<br> <myles> leaverou: 1) Because of the way listified properties work, if the lists are mismatched, the shorter lists are padded with the last term, which means if you have a border-width of 10px, and say 3 border colors, then 10px becomes 10px, 10px, 10px, which gives you a width of 30px. So setting border-color has the effect of tripling your border width. Weird, and this is the first time<br> <myles> heycam: Wouldn’t this happen with any other listified properties?<br> <myles> leaverou: Others don’t stack. Backgrounds and animations are independent. But border-width, they stack, they aren’t independent.<br> <myles> tantek: Or you have to do weird math, which is worse.<br> <myles> leaverou: Other issue: based on how other properties were listified, the property got almost the same syntax it already had, but you could add more with commas. So, previously it accepted 4 colors, you could have 1-4 colors, then commas, then 1-4 colors, etc. This inverts the relative power of white space and commas, which is not how authors think<br> <myles> leaverou: You can see an example in the issue<br> <myles> leaverou: It’s quite unexpected.<br> <myles> leaverou: For those reasons, fantasai and I were thinking of an alternative way to do multiple border colors, because there aren’t many use cases of multiple colors with different styles. All use cases for multiple borders are essentially cases for multiple colors on a solid border. So we were thinking how can we have multiple colors on existing borders. The idea is to define a function, we called<br> <myles> it stripes(), which lets people define a 1-dimensional image which is weird but we already have 0-dimensional images, and it can be used in border-color, and it has to be 1-dimensional image because otherwise it would be difficult to define how it works around border-radius. To cover the most prominent use cases it would include lengths and percentages, and would work with fr values<br> <tantek> Lea's proposal looks like an improvement to me<br> <myles> leaverou: I have a list of the use cases we tried to cover in the issue, and a table of what the different syntaxes would look like. We also considered letting border-color accept a sequence of color stops, but that’s not convenient, because with borders, people usually wants stripes not gradients, and it’s hard to make stripes with the gradient syntax<br> <myles> fantasai: You don’t want absolute positions<br> <fantasai> s/positions the way gradient stops do them, but rather widths that stack/<br> <myles> leaverou: We also considered using a new border-stripes property. But it has weird affects. It combines with border-color in a confusing way, because unless there are transparent stripes, you dont’ see border-color. In general, having properties that disable other properties is some fo the most confusing parts of css<br> <myles> emilio: Firefox used to have multicolor border support, by using a new property<br> <myles> leaverou: Yep, and it was confusing<br> <myles> chris: We decided not to do it the Firefox way<br> <myles> dbaron: It was a hack to create a certain button style without making extra dives<br> <myles> leaverou: I used it 10 years ago to simulate box shadow<br> <myles> TabAtkins: I like it<br> <myles> astearns: What happens when the total sum of the width exceeds the border width?<br> <myles> TabAtkins: You just only render the border-width of the stripes<br> <myles> leaverou: We can just scale it down. We do it with border-radius, if the total radii overlap, then it gets clamped<br> <myles> S/clamped/scaled equally across the entire box/<br> <myles> astearns: That could work, but what about fractional widths? Those go to 0? So you have a 2px white fractional black, 2px white<br> <myles> TabAtkins: *describes another example*<br> <myles> fantasai: It’s better than clamping.<br> <myles> fantasai: It gives you reasonable behavior when you grow and when you shrink<br> <myles> TabAtkins: We already have mechanisms (percentages) to do this.<br> <myles> TabAtkins: This allows you from putting in more stripes than you need<br> <myles> TabAtkins: So if you alternating 1px stripes, you just make a super long one, and no matter how wide the border happens to be, it will just work (in the clamping situation)<br> <myles> frremy: Animations work better too<br> <myles> leaverou: If you want to reveal stripes, you could always animate them from 0<br> <myles> TabAtkins: Not if we scale the values<br> <myles> leaverou: Non-zero lengths will be scaled down, but if you want to progressively animate,<br> <myles> TabAtkins: You can alreadya chive accordian effect<br> <myles> fantasai: What if you want 2px red, 2px white, 2px red. If the border grows, you want the white to grow<br> <astearns> s/alreadya chive/already achieve/<br> <myles> fantasai: When you scale up, you want red on the outside, you preserve the red, white, red<br> <myles> TabAtkins: use min() and max() instead.<br> <myles> leaverou: What do we do if we want a thinner width than what we have? In fantasai, what if our border is 10px<br> <myles> TabAtkins: We follow gradients. The last color continues<br> <myles> fantasai: Or the last color could be transparent<br> <myles> TabAtkins: But then the border doesn’t look thick<br> <myles> fantasai: If you want it to be thick, put 1fr at the end<br> <myles> TabAtkins: When this is used in a 2 dimensional context, then this should be a gradient in some arbitrary direction<br> <myles> fantasai: I don’t think he testing and implementation effort of making stripes in 2d only for an arbitrary direction makes any sense<br> <myles> TabAtkins: Here we’re just talking about stretching and scaling<br> <myles> Rossen: What if we repeat the pattern?<br> <myles> leaverou: We can introduce that later. Let’s keep it simple.<br> <myles> fantasai: It answers the question of what to do if you dont’ have enough stripes<br> <myles> TabAtkins: Don’t be arbitrarily different. Do what gradients do<br> <myles> fantasai: no<br> <myles> TabAtkins: no<br> <myles> TabAtkins: be consistent<br> <myles> fantasai: this isn’t gradients<br> <myles> TabAtkins: this is gradients<br> <myles> fantasai: this is stripes<br> <myles> leaverou: Gradient color stops are defined absolutely, and there is no fr<br> <myles> Rossen: stop. Are we trying to add this to backgrounds-4?<br> <myles> All: yes<br> <myles> Rossen: We can work this out later<br> <myles> Rossen: Was there anything else you wanted to go over technically as part of the proposal?<br> <myles> leaverou: no<br> <myles> Rossen: Should we add this? Are there still too many open issues for it to be added?<br> <myles> TabAtkins: Using the stripes functions as a border color and not listifying border color makes more sense than what we already have<br> <tantek> agreed<br> <myles> fantasai: This is a better solution. My question: whether to use border stripes or to add this to border color. In general, colors cannot take a 1d image. Any property that ends in -color takes a color. This is not a color, it accepts a 1d image<br> <myles> astearns: border-color-stripes?<br> <myles> fantasai: border-stripes is okay<br> <myles> leaverou: What about the confusing interactions?<br> <myles> fantasai: its okay.<br> <myles> astearns: The behaviors fall out of the description<br> <fantasai> s/The/Some/<br> <fantasai> astearns: e.g. might answer question of what to do when you run out of stripes<br> <myles> frremy: That isn’t great because if you pad a border stripes with the border color, the issue is that the border color by default is non transparent, but your stripes may be transparent, then should you display the border-color under the stripes? If you do, you lose the whole point of having transparent stripes<br> <myles> fantasai: You should show border underneath this property<br> <myles> leaverou: You often want them to stack, to have a fallback that you don’t have to repeat it in your gradient<br> <myles> xidorn: I dont’ understand the integration here<br> <myles> fantasai: border stripes and border color will disappear when you use border-image<br> <myles> chris: This will need some good examples<br> <myles> TabAtkins: Or we just do stripes() and we don’t have to deal with this stuff<br> <myles> leaverou: yep<br> <myles> fantasai: yep<br> <myles> leaverou: If we do it with a stripes function and not a separate property, we can extend this to other properties<br> <myles> fantasai: The other properties need a 0-dimensional color, or a 2-dimensional image. If you applied stripes to those other places, you would need to also specify a direction and turn it into a 2-d thing<br> <myles> leaverou: i said “if it’s needed” and it may not be needed<br> <myles> fantasai: We could re-use the syntax. It doesn’t have to be a functional notation<br> <myles> leaverou: We would have to add a new property for each of those cases<br> <myles> fantasai: That’s okay<br> <myles> Rossen: Do we prefer the stripes functions? Or a new property<br> <myles> fantasai: border-stripe<br> <myles> TabAtkins: stripes function<br> <leaverou> stripes function<br> <tantek> stripes function<br> <myles> astearns: One reason to have the function is that we noted that listifying properties is confusing. Stripes() makes specifying these stripes more comprehensible. If we use a property, we’re back to a list.<br> <myles> leaverou: yes<br> <tantek> s/all a/allow a<br> <myles> Rossen: Another benefit is you can have the border color and the stripes in the same definition, so you can have your border color as defined green, but you can also define the stripes on top that may or not have green<br> <myles> leaverou: So you can do them both in the same property<br> <myles> Rossen: Yes.<br> <myles> TabAtkins: Why do you need that?<br> <myles> Rossen: So you can have the last value be transparent, and the default shows through<br> <tantek> Is stripes a subset of gradients?<br> <myles> fantasai: The main benefit of the border color being separate is so that they can cascade independently. If theyr’e not cascading independently, then there’s no point<br> <myles> chris: The original reason for this was because a11y wanted to have a black and a white outline, and outline is defined in term of border. With this syntax, you say “black white” and you’re done.<br> <myles> chris: Let’s not make a new property.<br> <myles> tantek: Is stripes just a subset of gradients?<br> <leaverou> tantek: No, gradients are 2D images. Also, gradient color stops define positions, not widths.<br> <myles> Rossen: Proposal: adding stripes() to border-color and outline-color<br> <myles> Rossen: Any additional concerns? Comments that would change this resolution, or objections?<br> <myles> florian: How does it interact with border-style: double<br> <myles> fantasai: You clip out the border shape.<br> <myles> Rossen: Just like it would work with gradients<br> <myles> leaverou: I think he’s asking about double borders ,not dotted and dashed.<br> <myles> chris: It’s a clip mask effectively.<br> <myles> leaverou: Double has two different colors, and inside and an outside<br> <myles> florian: nope, that’s something else<br> <myles> leaverou: You’re right<br> <myles> dbaron: We could say that inset outset groove and ridge would just get treated as solid because you’re picking your colors yourself now and that overrides those styles.<br> <myles> florian: You can use it as fallback.<br> <myles> leaverou: right!<br> <myles> leaverou: I like that<br> <myles> chris: yeah.<br> <myles> Rossen: Any objections?<br> <myles> RESOLVED: Add stripes() to border-color and outline-color<br> <TabAtkins> tantek: It's *substantially* more work, yes, *and* it doesn't work well with border-radius either.<br> <myles> Rossen: Do we now publish a new working draft?<br> <myles> fantasai: I don’t know what state the rest of the draft is in<br> <myles> leaverou: we’ve published a working draft before, right?<br> <myles> fantasai: nope<br> <TabAtkins> (You can't supply separate images for each border, just a single border-image that's 9-sliced to supply all the border regions.)<br> <myles> Rossen: This is level 4, right?<br> <myles> leaverou: yes, that needs lots of cleanup<br> <TabAtkins> And yeah, probably so, which is fine with em.<br> <myles> Rossen: Let’s not publish<br> <TabAtkins> Just "gradient(...)"<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2532#issuecomment-402327492 using your GitHub account
Received on Wednesday, 4 July 2018 00:22:27 UTC