Csswg-drafts: [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.
  css .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

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

[DavidMacDonald]

Thanks for the update @tabatkins ...

[LeaVerou]

Not just sick, I'm at the hospital :)

I really care about this feature and want to spec it soon, but I'm not going to do it from the hospital, so I'd say an optimistic ETA would be mid November. Of course if another editor wants to do it instead, I can't possibly hold the feature back.

[HerrBertling]

Get well soon :)

[tabatkins]

I actually wrote that comment before I found out that you were at the hospital; I just knew that you'd gotten something flu-like the week prior. ^_^

I'll try and take some time to write up a proposal and run it past you, if you don't get to it first.

[DavidMacDonald]

Thanks so much @tabatkins @LeaVerou for getting back to me on this.

@LeaVerou I'm really sorry you haven't been feeling well. I hope you bounce back and are feeling well soon.

[DavidMacDonald]

Hi @LeaVerou
How are you feeling...?

[DavidMacDonald]

@tabatkins
What are your thoughts about this?

[DavidMacDonald]

Hi All
@tabatkins @LeaVerou @frivoal
Is there any movement on this? It seems like an agreement about what to add to CSS to allow two color outlines was reached with consensus, and it just needed to get written up.

[LeaVerou]

It seems like an agreement about what to add to CSS to allow two color outlines was reached with consensus, and it just needed to get written up.

That is correct. Sorry this is taking so long!

I looked into making the change a while ago. It's a fairly non-trivial edit. It requires these three changes:

1. We first need to define 1-dimensional images separately from everything else, in CSS Images 4.
2. Then the stripes() function (also in CSS Images 4) which produces a 1-dimensional image based on the syntax we resolved on.
3. Lastly, we need to allow 1-dimensional images in border-color and outline-color and provide some examples with stripes().

I'm up for doing 2 and 3 but I don't feel I'm experienced enough to do 1 properly, so I would feel more comfortable if @tabatkins or @fantasai did that one.