W3C home > Mailing lists > Public > www-style@w3.org > May 2017

[CSSWG] Minutes Tokyo F2F Thu 2017-04-20 Part III: Multi-color Borders and Outlines [css-backgrounds-4][css-ui-4]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 26 May 2017 20:51:54 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <75be35be-37fa-d762-7dce-4f5541712f1e@inkedblade.net>
=========================================
   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

===== FULL MINUTES BELOW ======

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
            colors.
   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
         artifacts.
   smfr: Can solve in single border and background case, but it's
         expensive.
   [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
           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]
   <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
             border.
   [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
           three.
   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
               width.
   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.
   <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
           paths.
   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.

   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?
   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
             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.
   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
Received on Saturday, 27 May 2017 00:52:30 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 27 May 2017 00:52:31 UTC