[css-ui] Two different colours for a "double" style outline

[DavidMacDonald]

I'm on the WCAG team and we are discussing requirements for the next version 2.1 that would require focus contrast in interactive elements.

With different colours of buttons there is almost no one focus indicator colour that could be used across the site. However Apple addressed this issue with their VoiceOver screen reader, by providing two lines to indicate focus, one black and one white. So the indicator is always visible regardless of the colour of the button.

This could be done in CSS if there was the ability to make the outline style "double" where the inside line and outside lines were different colours. Then one CSS class with this two color double line on the focus indicator would be visible across the entire site, without a lot of CSS fuss and development time.

 *:focus{ outline: #000000[inside] #ffffff[outside] double 5px;}

[svgeesus]

double is already an allowed value for outline-style https://drafts.csswg.org/css2/box.html#value-def-border-style

But not with separate control of two colours. Although invert is supported https://drafts.csswg.org/css-ui/#propdef-outline-color

[SebastianZ]

For what it's worth, Mozilla has several -moz-border-*-colors properties allowing to define multiple colors for the borders, which only works with solid borders, though.

Sebastian

[DavidMacDonald]

@svgeesus yes I understand. It would be a huge accessibility win to have more flexibility in allowing the double to have an inner color different from the outer.

[svgeesus]

For what it's worth, Mozilla has several -moz-border-*-colors properties allowing to define multiple colors for the borders,

Is that something which could be proposed for standardization?

[DavidMacDonald]

Maybe.... do you have an example? The goal is a double outline, with two different colours inner/outer.

[DavidMacDonald]

However, I don't think if can be a "border" because they take up space, and when applied to a focus ring they cause the interface to jump and shake. The outline doesn't take any space and allows smooth looking interface when tabbing.

[svgeesus]

The reason I mentioned border is because outline styles are defined to take the same keywords that border does (see spec links above). Not because I thought border and outline were the same thing - they have important differences.

[DavidMacDonald]

Oh, OK, I understand.

@SebastianZ Is there an example of the Mozilla -moz-border-*-colors, that you can point me to? I Googled it but couldn't find anything useful? So I could say... "yes, this is exactly what we're looking for the outline in CSS."

[frivoal]

I suppose that in level 4, we could either:

• extend outline-color to take two values, the second of which is applied to the second line of outline-style:double
• extend all outline properties to take 1 or n values instead of 1, and when you supply several, you end up with several outlines.

  .rainbow {
  outline: solid red, solid orange 3px, dashed yellow 1px, dotted green 5px, blue double, indigo grove, solid violet;
  }

  The same logic could apply to borders (which would indeed consume more space).

The second solution is overkill if all you want is two solid outlines of different colors to maintain contrast, I think there's been quite some demand for multiple borders and outlines over the years, so maybe we should go that way.

[SebastianZ]

Oh, OK, I understand.

@SebastianZ Is there an example of the Mozilla -moz-border-*-colors, that you can point me to? I Googled it but couldn't find anything useful? So I could say... "yes, this is exactly what we're looking for the outline in CSS."

I've linked the -moz-border-*-colors with a related MDN page in my previous comment, but here it is again: https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-border-bottom-colors

This is not exactly what you'd like to have, because it doesn't work together with other border styles than solid, but it shows how this could be implemented.

Having said that, I think @frivoal's second proposed solution to extend the outline properties is a better approach, as it conforms to the syntax of the background-* properties for providing multiple backgrounds. But, this may really be overkill.

Sebastian

[DavidMacDonald]

@frivoal Yes, we totally support both your ideas. The second one is very interesting and could benefit more than just the disability community.

@SebastianZ OK I see... sorry I missed the linked text above. Actually the MOZ border idea is perhaps better than our double outline idea. But they will both accomplish the purpose. There are 3 ways I could see it working:

1. @frivoal second solution, my preference because you can do a white/black/white, which ensures the black outline is always visible against its surrounding white, but usually looks like just one colour (black)
2. @frivol first solution allowing double outlines to have 2 different colour (outer, inner)
3. allowing solid outlines to have multiple colours like MOZ.

1. Allowing 1 or n colors for outlines and borders.

.rainbow {
  outline: solid red, solid orange 3px, dashed yellow 1px, dotted green 5px, blue double, indigo grove, solid violet;
}

2. Using the double outline with two different colors (outer, inner)

  outline: 3px double;
  -double-outer-color: #00000  ;
 -double-inner-color: #ffffff  ;
}

The two colours are next to each other.

3. Using the moz example:

  outline: 3px solid black;
  -top-colors:  #ffffff #00000 #ffffff ;
  -right-colors:   #ffffff #00000 #ffffff ;
  -bottom-colors:   #ffffff #00000 #ffffff;
  -left-colors:  #ffffff #00000 #ffffff;
}

This ensures if this outline is applied to the focus ring, the black border will ALWAYS have white around it, and will always be visible regardless of the colour of the control

You guys are masters at creating syntax so you'd probably do much better than I. But yes, this is what we're looking for.

[LeaVerou]

We do NOT need an additional property for multiple borders or outlines. There is an existing process for allowing multiple values on a given property: we just need to make border and outline a list, just like we did for background and friends.

Back in time, we had decided not to, because "people could always use border-image". However, in practice we've seen that people are very reluctant to use border-image for these things, and instead hack box-shadow or outline for a 2nd (3rd, 4th, ...) border.

Besides styling, you are making a very good accessibility case for multiple outlines, since there is no existing outline color that can always be guaranteed to be have sufficient contrast with its backdrop or even be visible at all. No, not even invert, as the inverse of 50% gray is 50% gray.

We can certainly discuss with the WG about adding this in Backgrounds 4 and UI 4.

[DavidMacDonald]

@LeaVerou

"you are making a very good accessibility case for multiple outlines, since there is no existing outline color that can always be guaranteed to be have sufficient contrast with its backdrop or even be visible at all. No, not even invert, as the inverse of 50% gray is 50% gray. We can certainly discuss with the WG about adding this in Backgrounds 4 and UI 4.

That would be great. It would really help us as we provide requirements on contrast ratio minimums for focus indicators. Providing two colours side by side on the outline would ensure its always visible. Providing 3 lines might even be better (i.e. white/black/white would ensure the black outline always can be seen because it will have white on each side of it.)

We'd be glad to be involved in any discussion about it, where we could explain the need for people with low vision and those who are color blind.

[css-meeting-bot]

The CSS Working Group just discussed 2 Different Colors for a Double Style Outline, and agreed to the following resolutions:

RESOLVED: Borders are listified per proposal above, but only border-color takes a list for now

RESOLVED: border list resolution applies to outlines, offset is not list-valued

The full IRC log of that discussion

``` Topic: 2 Different Colors for a Double Style Outline github topic: https://github.com/w3c/csswg-drafts/issues/1172 ChrisL: There was an ask form one of the a11y groups, they noted on iOS or maybe OS? that focus highlight is two colors: black and white, so that whatever the background is, you can see it ChrisL: Black and white is always visible; invert e.g. doesn't work on gray ChrisL: They asked for this ChrisL: And I pointed out that outline uses the same keywords as border does. ChrisL: If we add multiple colored borders, which ppl have asked for, we would automatically get this on outline ChrisL: And that would be a nice extensible thing ChrisL: It would also give Web devs something they want, not just helping a11y, so more likely to be implemented and adopted ChrisL: Question is how do we add multiple color borders to things Florian: One of the other options, which isprobably not such a good option, is to have double borders take two different colors Do we want 'outline-image' that's a parallel to 'border-image'... or does that get messy with non-rectagular outlines? ChrisL: I think that's less general and less useful, and would prefer to shoot for the bigger one @ChrisL: can't we just add an option to have two outlines with two outlines offset? one black, one white? Florian: Comma-separated leaverou: Authors do it all the time with border+outline, or multiple box shadows leaverou: Back when we were listifying the properties, idea was ppl would use borde-rimage for it leaverou: But people don't want to use border-image bc don't want to link to images leaverou: So best way forward is to make border and outline a list q+ leaverou: It solves all these issues q+ ChrisL: Also observed that people do all kinds of creative things with list-valued properties present+ ChrisL: So theyr'e a good thing shane: spacing between borders? fantasai: transparent present+ ChrisL: We wouldn't assume the same width, could have thick and thin borders, one can be transparent q? q? leaverou: In the case of outline, offset exists q+ smfr: How does this interact with border radius smfr: Is there a single border radius or each one have its own? ChrisL: It should stack out nicely Florian: It's corner-radius, not border-radius smfr: One thing that's hard with border-radius is getting a smooth edge between two different colors without anit-aliasing artifacts q? smfr: Can solve in single border and background case, but it's expensive q- ChrisL describes the problem ChrisL: I suggest we say that the borders are all composited together off-screen, and then added on top of background smfr: That seems reasonable q? ChrisL: Effectively that means that we should communicate this is a single multi-coolored border, rather than multiple borders dbaron: I think we've just agreed to turn 25 properties into lists dbaron: There are some interesting questions as to how they all interact dbaron: IN particular we have [lists all the border properties] See https://www.w3.org/TR/css3-background/#property-index Rossen: Don't forget the logical ones! also outlines dbaron: So, 39 properties q+ to worry about multiple border images dbaron: Most of it is uninteresting except 2 things dbaron: One is, what is length of the list is different for style / width /color? Which controls? dbaron: We typically pick one authoritative dbaron: My intuition is style should be authoritative general agreement dbaron: Question is then whether you allow 'none' in the middle of the list dbaron: which would kill corresponding things in the list Florian: none | dbaron: We originally said that for animations, but then ppl wanted placeholders ChrisL: People might want to animate from none fantasai: They shouldn't use one, should animate from zero-width border q+ leaverou agrees TabAtkins: or maybe *-color should be controlling the list length dbaron: So making color controlling is interesting, that might b the most common thing to vary TabAtkins: Would need to repeat the other things ChrisL: Want to repeat the list, not just pad it? fantasai: I think we should have front-padded backgrounds instead of repeating. s/should have/shoudl have had/ q? fantasai: But for border, repeating might make more sense ack dbaron q- dbaron: Other point: corner joins! Corner joins are pretty hard already, now have to figure out 2 borders joining for three fantasai what was the thing that I said we needed? dbaron: We already have a complicated spec for corner joins to make them look nice [discussion of corner join niceties] dbaron: I think people are going to ask for it to be nicer. SimonSapin draws I'm looking forward to hacking arbitrary polygons with multi-borders: http://tantek.com/CSS/Examples/polygons.html SimonSapin: with just one border, if htey are different widths, we have this line whose angle varies depending on the widht SimonSapin: If we have more borders, but not the same count, then assume we can connect them like this? transition is weird dbaron: Do you want a straight line or a zigzagline? fantasai: You want a straight line myles and smfr also seem to want a straight line surma: I would expect basically to have the same diagnonal as one border, and you add up all the border widths surma: And separate the big border into individual ones general agreement ChrisL: Which allows you to composit as a single thing smfr: There's an amazing amount of code for border joins q? dbaron: A bunch of these cases throw you into really slow graphics paths dbaron: At one point 30% of gmail render time was borders dbaron: Don't thin kthis stuff is easy s/render time/load time/ SimonSapin: Someone said multiple borders are all the same width, but then said border widht is a list fantasai: It's a list, that repeats ack SimonSapin SimonSapin: OK ChrisL: So, border-image. Will we allow multiple images? (BTW, I hate implementing list-valued properties!) ChrisL: Does the border-image blow off all the other borders? tantek: Yeah s/tantek/TabAtkins/ ChrisL, you wanted to worry about multiple border images q? ChrisL: ian asked didn't Mozilla have something like this, yes, it was a list of 1px color stripes that was weird ChrisL: This is better going forward dbaron: This was the realization that the Mozilla Suite UI's buttons, which were composed of 9 images in an XBL binding, could be made massively faster by having this hack for multi-colored borders Proposal: * Have multiple borders as list-valued border properties * one corner radius for the whole thing * corner join is one for the whole thing * border-color controls the list length * list repeats to fill [discussion of border-style: none] * gaps can be specified via transparent borders * border-style: none; kills the whole list, and can't be made as a list item dbaron: If style: none make the width zero, does it result in border-width: 0, 0, 0; or just 0;? ChrisL: 0; dbaron: Does it kill the color list so you can't inherit it? fantasai: Who inherits borders anyway? http://w3cmemes.tumblr.com/post/121697381917/one-of-the-reasons-standardization-takes-a-while ChrisL: We should also cover outline properties dbaron: A bit concerned about 'none' being special, might be simpler to just make it a placeholder value leaverou: As an author that's what I'd expect, even though it's not useful Florian_: Which is simpler for implementation? dbaron: Makes style processing easier, but layout harder? dbaron: probably okay eithe rway fantasai: We could always make it a list item later, if we thought dbaron: Issue is implementation complexity q+ fantasai: From implementation perspective, can just restrict it at the parsing level. q- TabAtkins: This is getting complex, why not just go back and do two-color double borders? shane: This would be pretty low on our priority list, but the a11y use case would be nice to address quickly leaverou: What if we had a list with two colors, so that the syntax stayed the same? fantasai: double border isn't two colors, it's two stripes and a gap leaverou: if it's more than 2px shane: Maybe just have a list for colors? Rossen: Can we start there? Everything else is additive Rossen: Don't need all this extra complexity then, if it solves all the use cases ChrisL: I wanted to have something that has an upgrade path, not just "you can have two colors, which could be either white or black" leaverou, shane, and ChrisL: this seems to cover most of the use cases plinss: What about using a gradient? ... [confusion] shane: we're speccing that you can have a list of colors, and it behaves as described above ChrisL: We subsetted the larger feature, basically smfr: so if you have multiple colors, you'd get rainbow dots? fantasai: No, one row of dots per color smfr: I think rainbow dots might be better plinss: That sounds like using a gradient astearns: 😱😭😨😰😓😪😢😥😳 fantasai: I agree with Peter that if we want to do rainbow-colored dots, you use a linear gradient as a border color and it draws outward smfr: Okay, I'm okay with border-style applying to each layer dino: Dean says this should all be custom paint q+ s/Dean/Ian/ iank_: Other complexity here is what happens with all the weird groove / ridge / inset / outset / double smfr: I think you just paint them as if independent borders Florian: dashed and solids are possible common dbaron: Getting dashes to line up would be problematic Rossen: so most recent proposal was colors list, leaving room for improvement later smfr: Can you detail that proposal? iank_: “The rest is left as an exercise for the reader.” @Rossen in particular how you can fallback in browsers that do not support a list ChrisL: You repeat stuff, as if everything else was list-valued, but they can't accept more than one value @Rossen nvm you can use @supports I guess q+ ChrisL: We don't really want to say if there are multiple colors, you can only have solid shane: If we want the dashes to line up eventually, better to say that you can't use dash now @fremy that or the last color wins @Rossen was thinking what happens to the border width, since that affects layout fantasai: We can't syntactically restrict that combination shane: make the border invisible at this point Florian_: Do we need the dots to line up? @fremy the proposal is to add a list to border-color only Florian_: Spaced out borders with dots don't really seem like they have to line up, just if they touch each other and don't line up they look ugly q? q+ plinss: Corner-radius changes the dash length and stuff @Rossen sure, but do you divide the border-width between the colors, or do you have the border be twice as big, one border-width per color fantasai: just make it ugly, paint random static :p shane: Just say that dashes never line up, if ppl want that use case we can improve later smfr: So we're allowing a list on border-color, are we allowing list o nborder-width? leaverou: no (not yet) SimonSapin: If we talked about the marginal feature of everything is a list, and hten subsetting it @Rossen because if the latter, then you can't fallback easily, you would need one border-width for the browsers that support list, one for the other SimonSapin: width is implicitly rpeated SimonSapin: So the border-width for layout is the specified width multiplied by the color count SimonSapin: Could have it be each stripe is divided by count q? plinss: This makes color the controlling one, but we said style? TabAtkins: No, we decided color should control Rossen shows off amazing abstract art of Chrome attempting dotted borders q? SimonSapin: What does the border shorthand look like? ack SimonSapin TabAtkins: Can't take a list fantasai: the one concern I have is fallback if we make color controlling the list q? fantasai: and don't divide border-width by the count Florian_: Use @supports SimonSapin: That's unfortunate Florian_: It doesn't break horrifyingly shorthand could take a list, sensible, e.g. the a11y use-case border: solid black, solid white fantasai: It does if you do layouts with floats and stuff tantek: a11y use case fantasai: outline doesn't have the same layout problems q? ack leaverou q+ leaverou: I wnated to reply to shane about, even if we don't drawn anything for dashed borders, people will depend on it e.g. with content property on elements leaverou: where enabling that started breaking sites leaverou: So have to paint something iank_ and Rossen competing for best picture Rossen: Proposed resolution, extend border-color as a list, behavior as if border-color/style/width were list-valued per proposal above RESOLVED: Borders are listified per proposal above, but only border-color takes a list for now Rossen: Outline? Florian_: Same as applying to border, only open question is if offset repeats or not Florian_: I would suggest not fantasai: I agree ChrisL: What does that mean Florian_: Offset the first one, and go from there dbaron: One other issue with outlines, which is that they can have inner corners in addition to outer corners discussion of corner radius Florian_: There's always interesting problems with outlines Florian_: Outline can be disconnected Florian_: Different behaviors if they just collide Florian_: Given outline is already undef about this... Florian_: Using fancy borders instead of trying to use outline for them should give UAs more freedom dbaron: OK to extend to outline, but probably want to clean up the outline spec RESOLVED: border list resolution applies to outlines, offset is not list-valued https://codepen.io/anon/pen/gWPZVR ```

[DavidMacDonald]

I've read through the log. Am I right that it will be possible to have multiple colour borders and that applies to outlines also?

That would be amazing.

For focus indicators it's all about "outline" because they don't make the page jitter the way borders do.

[frivoal]

I've read through the log. Am I right that it will be possible to have multiple colour borders and that applies to outlines also?

Yes.

That would be amazing.

Yes :-)

[DavidMacDonald]

Great, I will inform the committee.

[frivoal]

@LeaVerou Are you supposed to making the edit to css-background, or is that on someone else? I'd like to update css-ui to point to this new capability in backgrounds, but as far as I can see it is not there yet.

[DavidMacDonald]

+1

[LeaVerou]

@frivoal It's either me or @fantasai AFAIK. I'm currently crazy busy with both work and family visiting, but if you're willing to wait 2 weeks or so, I could make the edit.

[frivoal]

if you're willing to wait 2 weeks or so, I could make the edit.

Two weeks is fine. Thanks for taking care of it.

[DavidMacDonald]

Hi @frivoal We have an active discussion on WCAG about this. Could you update on the status? When might it be introduced into a recommendation and supported by browsers so that authors can do it... just wondering if you have a crystal ball. https://github.com/w3c/wcag21/issues/490#issuecomment-337245265

WCAG 2.1 will be out mid next year.

[frivoal]

The status that that the CSSWG resolved to add multiple borders and multiple outlines, but that the edits have not yet happened. I'm waiting for the edits on border before replicating the same thing on outline.

@LeaVerou or @fantasai, any chance of these edits happening soon?

If not, I suppose I could take the lead, but I am not particularly keep on encouraging implementations to support multiple outlines before they support multiple borders, and risk encouraging authors to use outline when they should have been using borders.

[LeaVerou]

Sorry I haven't done them yet. Do keep in mind that any spec work I do has to be done outside my full time job, which makes it harder to find time to edit specs. I'm currently travelling, but I will try to do the week before TPAC. Does that work?

[frivoal]

Thanks @LeaVerou. I totally realize that you're doing this on the side. Don't worry about delays, and thanks for doing it at all. I think this is a really cool feature, so the sooner we spec and implement it, the better, but there's absolutely no deadline (at least not from me). Before TPAC would be great.

[LeaVerou]

A bit later than I promised, but I finally got around to it. Done!

[frivoal]

The css-ui part of this has not been done yet. Reopening.

[simevidas]

@LeaVerou Should it be <color>+ instead of <color># in the Value row of the border-*-color definition box, since in a multicolor border, the color values are not comma-separated (according to the spec example)?

border-color: black white; /* multicolor border */
border-color: black, white; /* black on the top/bottom, white on the sides */

[LeaVerou]

@simevidas No, it's definitely comma-separated, just like all list-valued properties. Space-separated sets color for different sides, comma separated means multiple border colors per side.

Where did you see that example? The one you're linking to is different.

[simevidas]

@LeaVerou Ah, I read the spec example wrong and got it backwards. So, this should be correct:

border-color: black, white; /* multicolor border */
border-color: black white; /* black on the top/bottom, white on the sides */

In that case, should it be <color>{1,4} instead of <color>{1,4}# in the border-color definition box (same section)? If I’m reading the spec correctly, # means comma-separated.

[LeaVerou]

So, this should be correct:

Yup.

In that case, should it be <color>{1,4} instead of <color>{1,4}# in the border-color definition box (same section)?

It's 1-4 space separated colors (for each side), then that is comma separated. Look at the spec example, it uses both.

[simevidas]

I think, I understand now. I was confused about the difference between <color>{1,4}# and <color>#{1,4} (I didn’t even notice that they have different meanings).

The value definition syntax is quite confusing in this aspect. For example, in <color>{1,4}#, there are two distinct multipliers (first space-separated 1–4 times, then comma-separated 1 or more times), but in <color>#{1,4}, there is only one multiplier (comma-separated 1–4 times).

In other words, if {1,4} doesn’t have # to its left, it defaults to space-separated, and if # doesn’t have {…} to its right, it defaults to one or more times. Uh, I barely understand it as I write this. 😔

[LeaVerou]

Would parentheses help clarify? i.e. (<color>{1,4})#

Also, is the issue with the grammar declaration, or do you find the actual syntax confusing?

TBH I don't think it's great from a usability perspective. People don't think in chunks like "outer colors for all sides, inner colors for all sides, innermost colors for all sides", instead they think in terms of "colors for top side, colors for right side, colors for bottom side, colors for left side", unless they're the same for every side. However, we can't really translate that to syntax, because then we'd need to have comma-separated and then space-separated. But since the commas have lower precedence than spaces, we'd need parentheses to do that, which we don't have.

What we have now is consistent with how other CSS properties are listified, but not ideal from a UX perspective. So, I suspect the longhands would probably be favored if the colors are different on each side, instead of using the space-separated and then comma-separated syntax.

[simevidas]

My issue was with the value definition syntax, sorry. Parentheses would help, I think.

[LeaVerou]

Parentheses would help, I think.

Done!

[frivoal]

@LeaVerou I don't think what you specified is what we resolved on. In your spec, if you have border-width: 20px; border-color: blue, green; you get a 10px blue border and a 10px green border. But my understanding of the resolution was that we'd get a 20px blue border and a 20px green border. The resolution is

Borders are listified per proposal above, but only border-color takes a list for now

Which means that when you get more than 1 color, the border-width behave as it if was a list, and since the border-width list is shorter (1 item) than the border-color list (2 items) the item gets repeated.

Also, you made an example using 2 colors and border-style: dotted, and you have large dots with two colors in them, but by the same logic of listification, since border-style has 1 item rather than 2, the 1 is replicated, and we should get two series of dots, not one series of polychrome dots.

[LeaVerou]

Oof, that seems correct, though rather unintuitive. It's very weird that setting border-color can change the width of the border. We don't have any other listified properties where this issue arises.

@fantasai any thoughts before I change it?

[tabatkins]

We don't have any other list-valued sets of properties that "stack" in this sort of way; all the rest run in parallel.

Regardless, if we went with "divide the border-width between the stripes", it would then be impossible to cleanly extend border-width into being list-valued as well - what would that even mean?

Also, is the issue with the grammar declaration, or do you find the actual syntax confusing?

I find the actual grammar quite problematic, unfortunately - it inverts the relative power of space and comma to the exact opposite of how it works in every single other property. It's always the case that commas separate the outermost repetitions, and spaces separate the individual values.

In particular, the fact that border-color: red, green white, black creates a border where the top and bottom are red/green and the left and right are white/black is terribly confusing.

We need to either invert the order of things, like border-color: red white, green black (where each comma-separated value is a single border "layer"), or use a grouping mechanism like border-color: stripes(red, green) stripes(green, black);. (Note that plain parens are out - we avoided using them in grid-template to avoid clashing with Sass, and the same would apply here.) I like the first one much better - it matches up well with how other list-valued shorthands decompose into list-valued longhands.

[frivoal]

@LeaVerou I think you should fix the spec, or remove it. Keeping a known-to-be-wrong addition in the spec creates a risk that someone will implement it, and then we may be stuck.

[DavidMacDonald]

If I understand correctly border takes up physical space in the UI while outline does not. If we rely on the border aren't focus indicators going to cause the UI to jump up and down as the user hits the tab key. I'm hoping this will be on the outline

[LeaVerou]

@frivoal The entire spec has a huge red "do not implement" notice, so I'm not sure the risk you're assessing is realistic. Nevertheless, I added an issue that links here to make it even more clear that the syntax is still under active discussion.

I don't see a clear way forward with this, I think it needs to be discussed further. I agree with @tabatkins's concerns about usability (in fact, I raised them myself earlier in the thread). However, grouping with stripes() or a similar mechanism does not actually listify border-color. Listification typically extends the current syntax into multiples of the current syntax, and the current syntax accepts 1-4 space-separated values.

Furthermore, aside from the grouping issue, it's insanely confusing that setting border-color can affect border width, and I'm not sure we'd make that resolution if we knew that. If we listified border-width too, we could make that one the property that determines the number of layers, and this issue wouldn't exist.

In any case, more discussion is needed because this is not as simple as it seemed back when we resolved on it, and I think we need to bring it to the group again.

@DavidMacDonald Not necessarily, you can always have transparent borders with the same properties when not focused, to avoid such jumps. However, any change we make to border will also be made to outline (per resolution), so you can use outline as well!

[DavidMacDonald]

Hi All @frivoal @LeaVerou As per the original premise of this issue, which was to allow an easy way for authors create a visible focus ring that could be used across the site without having to measure the contrast of every button, WCAG 2.1 is now an active recommendation of the W3C.

https://www.w3.org/TR/WCAG21/

Success criteria 1.4.11 requires "user interface components and states", to have "a contrast ratio of at least 3:1 against adjacent color(s)"

The Understanding document for the Success criteria further states

Also, the visual effects which indicate state, such as whether a component is selected or focused, must also provide the minimum 3:1 contrast with the background adjacent to the component...Regardless of the whether or not there is a visible boundary for the button, the focus indicator for the component must have sufficient contrast when the component is focused.

Please, I think its time. I don't care how its implemented, but please provide an easy CSS way for authors to create a two colour focus indicator. As long as the two colours have sufficient colour with each other, there will never be a failure of this Success Criteria by authors who implement this solution across their site.

[frivoal]

This was revisited at the last CSSWG F2F, and we've found what we think is a good solution.

https://logs.csswg.org/irc.w3.org/css/2018-07-03/#e1043903

Stay tuned for edits.

[DavidMacDonald]

Add stripes() to border-color and outline-color

Sounds very interesting. I hope it gets in, then gets Browser Support, and authors can start using it.

[DavidMacDonald]

@frivoal Any follow up on this? ... WCAG 2.1 is going mainstream. https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

[DavidMacDonald]

WCAG 2.1 has just been adopted for the European Standard EN 301 549. https://www.w3.org/blog/2018/09/wcag-2-1-adoption-in-europe/ Success Criteria 1.4.11 requires contrast of focus indicators to be 3:1. Currently, this can be hacked with a box shadow behind an outline, but its hacky and clunky. It would be great to have just one line of CSS to cover all colors of interactive elements (links, buttons etc.) on the site.

[LeaVerou]

I will try to spec stripes() before TPAC, but I can only do it in the last few days before TPAC, I'm crazy busy until Oct 19.

[DavidMacDonald]

Thanks @LeaVerou I'll be a TPAC in the WCAG meetings, would love to be able to make that announcement.

[DavidMacDonald]

@LeaVerou I'm here in Lyon at TPAC. I'm wondering if stripes() has been written.

[tabatkins]

@LeaVerou's been sick coming up to and during TPAC, so she hasn't had the time/energy to write it yet.