Re: [csswg-drafts] [css-ui] Two different colours for a "double" style outline

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
```

<details><summary>The full IRC log of that discussion</summary>

```
<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
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1172#issuecomment-295565255 using your GitHub account

Received on Thursday, 20 April 2017 03:25:49 UTC