[CSSWG] Minutes Tokyo F2F Thu 2017-04-20 Part III: Multi-color Borders and Outlines [css-backgrounds-4][css-ui-4]
(too old to reply)
2017-05-27 00:51:54 UTC
Raw Message
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.

CSS Backgrounds and Borders / CSS UI

- The following proposal was developed to address the feature
request for two-color outlines:
* Have multiple borders as list-valued border properties
* one corner radius for the whole thing
* corner join is atomic for the whole thing
* border-color controls the list length
* list repeats to fill, like background layers
* gaps can be specified via transparent borders
* border-style: none; kills the whole list, and can't be made
as a list item
- This was extended to supporting a list on border-color.
- 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


Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics

Scribe: fantasai

Two-color Outlines

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 color bands:
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.
<dbaron> Do we want 'outline-image' that's a parallel to
'border-image'... or does that get messy with
non-rectangular outlines?
<fremy> @ChrisL: can't we just add an option to have two outlines
with two outlines offset? one black, one white?
Florian: One of the other options, which is probably not such a
good option, is to have double borders take two different
ChrisL: I think that's less general and less useful, and would
prefer to shoot for the bigger one.
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 border-image for it
leaverou: But people don't want to use border-image because don't
want to link to images
leaverou: So best way forward is to make border and outline a list.

ChrisL: Also observed that people do all kinds of creative things
with list-valued properties.
ChrisL: So they're a good thing

shane: Spacing between borders?
fantasai: Use 'transparent'.
ChrisL: We wouldn't assume the same width, could have thick and
thin borders, one can be transparent.
leaverou: In the case of outline, offset exists.

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 should have been corner-radius, not border-radius
smfr: One thing that's hard with border-radius is getting a smooth
edge between two different colors without anti-aliasing
smfr: Can solve in single border and background case, but it's
[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.
ChrisL: Effectively that means that we should communicate this is
a single multi-colored border, rather than multiple

dbaron: I think we've just agreed to turn 25 properties into lists.
dbaron: There are some interesting questions as to how they all
dbaron: In particular we have [lists all the border properties]
<fantasai> See https://www.w3.org/TR/css3-background/#property-index
Rossen: Don't forget the logical ones!
<fantasai> also outlines
dbaron: So, 39 properties.
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 property 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 | <list>
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 none, should animate from zero-width
[leaverou agrees]

TabAtkins: Or maybe *-color should be controlling the list length.
dbaron: So making color controlling is interesting, that might be
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 definitely think we should have had front-padded backgrounds
instead of repeating.
fantasai: But for border, repeating might make more sense.

dbaron: Other point: corner joins! Corner joins are pretty hard
already, now have to figure out 2 borders joining for
dbaron: We already have a complicated spec for corner joins to
make them look nice.
dbaron: I think people are going to ask for it to be nicer.
[discussion of corner join niceties]

[SimonSapin draws]
SimonSapin: With just one border, if they are different widths, we
have this line whose angle varies depending on the
SimonSapin: If we have more borders, but not the same count, then
assume we can connect them like this? transition is
dbaron: Do you want a straight line or a zigzagline?
fantasai: You want a straight line.
<dbaron> myles and smfr also seem to want a straight line
surma: I would expect basically to have the same diagonal 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 composite as a single thing.

smfr: There's an amazing amount of code for border joins.
dbaron: A bunch of these cases throw you into really slow graphics
dbaron: At one point 30% of gmail load time was borders, because they
put border-radius: 1px on everything.
dbaron: Don't think this stuff is easy
SimonSapin: Someone said multiple borders are all the same width,
but then said border width is a list.
fantasai: It's a list, that repeats.
SimonSapin: OK

ChrisL: So, border-image. Will we allow multiple images?
ChrisL: Does the border-image blow off all the other borders?
TabAtkins: Yeah

ChrisL: iank 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.

* 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?
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 either way

fantasai: We could always make it a list item later, if we thought.
dbaron: Issue is implementation complexity.
fantasai: From implementation perspective, can just restrict it at
the parsing level.

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

plinss: What about using a gradient?

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.
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: iank says this should all be custom paint.
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.”
ChrisL: You repeat stuff, as if everything else was list-valued,
but they can't accept more than one value.

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.
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?
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.
plinss: Corner-radius changes the dash length and stuff.
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.

<fremy> @Rossen in particular how you can fallback in browsers
that do not support a list?
<fremy> @Rossen nvm you can use @supports I guess
<Rossen> @fremy that or the last color wins
<fremy> @Rossen was thinking what happens to the border width,
since that affects layout
<Rossen> @fremy the proposal is to add a list to border-color only
<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
<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

smfr: So we're allowing a list on border-color, are we allowing
list on border-width?
leaverou: no (not yet)
SimonSapin: If we talked about the marginal feature of everything
is a list, and then subsetting it.
SimonSapin: Width is implicitly repeated.
SimonSapin: So the border-width for layout is the specified width
multiplied by the color count.
SimonSapin: Could alternately have it be each stripe is divided by count.

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]

SimonSapin: What does the border shorthand look like?
TabAtkins: Can't take a list.

fantasai: The one concern I have is fallback if we make color
controlling the list
fantasai: and don't divide border-width by the count.
Florian: Use @supports
SimonSapin: That's unfortunate.
Florian: It doesn't break horrifyingly.
fantasai: It does if you do layouts with floats and stuff.
fantasai: Outline doesn't have the same layout problems.

<tantek> shorthand could take a list, sensible, e.g. the a11y use-case
<tantek> border: solid black, solid white
tantek: a11y use case

leaverou: I wanted 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]
<iank> https://codepen.io/anon/pen/gWPZVR
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 undefined 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