W3C home > Mailing lists > Public > www-style@w3.org > July 2019

[CSSWG] Minutes Toronto F2F 2019-06-05 Part III: CSS Color, CSS Text, Backgrounds and Borders [css-color] [css-text-4] [css-backgrounds-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 6 Jul 2019 18:51:47 -0400
Message-ID: <CADhPm3uDGVAUK1U0agvMvuHm7+WhsvCXB4SdRsXkP0Etp-H_Pw@mail.gmail.com>
To: www-style@w3.org
=========================================
  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 Color
---------

  - RESOLVED: Put all the proposals into css-color-5, ChrisL and
              future Una as editors
  - RESOLVED: Rename to put 'color' first, adjust-color -> color-mod()
  - RESOLVED: Add color-contrast() without currentBackground option
      - Question of "is computed value a color or a contrast-color()"?
  - RESOLVED: Add color-mix(), try to align syntax with cross-fade()
  - RESOLVED: Put both color adjustment proposals into css-color-5,
              with keywords instead of underscores for Lea's proposal
      - Proposal A: https://gist.github.com/una/edcfa0d3600e0b89b2ebf266bf549721
      - Proposal B: https://github.com/w3c/csswg-drafts/issues/3187
  - RESOLVED: Add Lea Verou as editor of css-color-5

CSS Text 4
----------

  - RESOLVED: Add Florian as editor of css-text-4

Backgrounds and Borders
-----------------------

  - RESOLVED: Drop the less useful values [notch & scoop], and rename
              [bevel -> angle] as proposed in the issue (Issue #3457:
              Borders with cut corners)

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

Agenda: https://wiki.csswg.org/planning/toronto-2019

Scribe: fantasai
Scribe's scribe: florian

CSS Color
=========

Color modification functions
----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3187

  <AmeliaBR> Una's proposal:
https://gist.github.com/una/edcfa0d3600e0b89b2ebf266bf549721
  una: Chatting with TabAtkins and my team about color modification
       because very highly requested
  una: Used a lot in preprocessors
  una: Very common pattern, so wanted to revisit as native CSS
  una: Here's a proposal for a more simplified proposal

  una: based on three functions
  una: adjust-color(), mix-color(), and contrast-color()
  una: color adjustment is basic modification via hcl values
  una: First argument is color to adjust, then list of modification
       functions
  una: mix-color mixes two colors
  una: contrast-color, submit a background color and then list of
       color values
  una: that you would place as text and background, and picks the
       highest contrasted color
  una: HCL would be default color space
  una: Can also have color space argument
  una: Lightness in LCH vs HSL
  una: If using lightness in a color space in e.g. cmyk, then do
       transformation in LCH and then clipped to CMYK range
  una: Wanted to make easy to use

  chris: Like picking LCH by default because it ... gamut
  chris: result will always be a color
  chris: like that it's explicit about color space
  chris: Does mix up in what color space doing calc and what you
         revert to
  chris: Gave some comments on this
  chris: Slightly concerned that people will believe that lightness =
         brightness and chroma = saturation
  chris: Need to understand that ...
  chris: Like that we have mixing colors, pretty convenient
  chris: I do this often by putting colors on a gradient to find a
         color in between
  chris: Unsure about mixing by component
  chris: Contrast color, I like that. Saw people asking for contrast
         things
  chris: But often they're asking for a 4.5:1 ratio to pass WCAG
  chris: Finding most contrasty color is nice
  chris: ....
  chris: I do like the idea of having a thing called
         currentBackgroundColor that we can use elsewhere
  chris: Lea points out that once you have opacity, you have ranges of
         contrasts

  leaverou: What do you do about ranges that are overlapping?
  una: Transparency issue is still unsolved by dev tools and a11y
  una: so don't know how best to handle that
  una: but still creating contrast checkers in devtools and other
       things, can re-use technology
  una: Pick best color
  una: up to author to make sure it contrasts enough
  leaverou: Not deal breaker, many ways to specify
  leaverou: just something that needs to be addressed to tweak their
            preferred color to meet minimum contrast requirements.
  una: Background with rgba have a difficulty
  leaverou: Can also have semitransparent text, though

  <myles> where is the term "colorFunctions" defined?

  chris: I think it's an interesting proposal
  chris: lots of details to tweak, but overall it's nice
  chris: also clamping needs to be defined
  chris: ...
  una: I think we could .. with filter now, brightness/saturation
  una: I like unclamped
  una: Can use value of 1000
  una: Creates interesting effects in CSS that wouldn't otherwise be
       possible
  chris: Clamping should be done at last possible moment
  leaverou: Let's discuss other proposal too so that we can compare.
            Might end up with blend of both

  heycam: Overall I like the idea of color adjustment things
  heycam: One comment about syntax for mix-color, for images we have
          the cross-fade function
  heycam: so if we only want one axis of interpolation, should align
          the syntax with that
  heycam: This kind of linear interpolation is something people want
          for other numeric types as well
  heycam: e.g. interpolation of lengths
  heycam: so maybe generic way for different types, or separate thing
          for color
  TabAtkins: We have outstanding resolution for generic interpolate()
             function
  TabAtkins: but mix-color can do more than simple interpolate
  TabAtkins: mix-color can mix different aspects of the color, pay
             attention to opacity or not, so much more complicated
             than other types
  AmeliaBR: For mix-color, heycam talking about comparison with
            cross-fade
  AmeliaBR: A comparison I think of is blend-modes
  AmeliaBR: The default mixture of two colors is equivalent to normal
            blend more
  AmeliaBR: to extent there's a % adjustment, that's adjusting opacity
            of the top blend layer
  AmeliaBR: Instead of talking about blending two colors using certain
            channels, maybe mixing using different blend modes is a
            way to go
  AmeliaBR: But general rule is re-use existing concepts in CSS as
            much as possible
  una: Really like idea of thinking as blend modes
  una: Agree that re-using concepts can be nice here

  fremy: I was wondering about the color-contrast function
  fremy: Mainly I'm trying to understand how to use in application
  una: Used for a11y if you have reusable elements
  una: or dark mode
  una: If you switch from light pink background to dark purple
       background
  una: need to ensure contrast
  una: Only have to specify colors one time
  una: it'll update the color on top of the background
  una: Common thing from SASS that people love
  TabAtkins: Crude example here: text is black or white depending on
             background in this color palette
  leaverou: Use case right there on github with labels, can give your
            labels custom background colors, and GH picks text color
            to contrast sufficiently -- automatically do that with
            contrast-color()
  fremy: Now I understand the use case, label use case is very clear

  AmeliaBR: One thing about the way una describe different from
            contrast function previously
  AmeliaBR: Previous contrast function, you gave a fixed color and a
            2nd color and then a desired contrast ratio
  AmeliaBR: and it adjusted 2nd color to meet the contrast ratio
  AmeliaBR: As I understand deciding the correct math for that wasn't
            satisfactory
  AmeliaBR: Una's proposal the website author has to give a palette
            list
  AmeliaBR: Would just select best contrast from list instead of
            calculating adjustments
  AmeliaBR: Could default to black/white
  chris: Advantage is end up with a color provided by author rather
         than random color

  [leaverou presents alternate proposal:
https://github.com/w3c/csswg-drafts/issues/3187#issuecomment-499126198
]
  leaverou: This is just about color adjustment
  leaverou: Problem with color-mod was it only worked in rgb
  leaverou: Nowadays people use wide gamut monitors
  leaverou: People use terrible hacks by putting things into different
            variables and stringing together and stuff
  leaverou: They've used colorMod() in PostCSS, implemented in custom
            scripts, etc.
  leaverou: Really need to settle on something whether this or Una's
            proposal
  <AmeliaBR> +100 to we need color modification functions (of some
             syntax)!!!

  leaverou: This proposal is based on fact that we have a number of
            color functions
  leaverou: besides rgb() and hsl(), also have lab() and lch()
  leaverou: Every color adjustment can be described as adjusting
            channels on one of those functions
  leaverou: Instead of creating colors, augment by introducing a
            coordinate argument on each of them
  leaverou: so either set coordinates specifically or use calc()
  leaverou: Could also use an underscore to say that this component
            stays the same
  leaverou: So making lighter, use lch, multiply lightness by 1.2
            would make it lighter
  leaverou: Benefit of this is that every color function gives us
            extra adjusters for free
  leaverou: Easy to understand b/c uses existing color functions
  leaverou: Let's say you have cmyk() space, comes with its own
            adjusters
  leaverou: also allows adjusting alpha
  leaverou: re-uses existing syntax, the adjustment just uses calc()
  leaverou: Obvious what the math is
  leaverou: Drawback is that it might give authors too much rope
  leaverou: they might just use hsl because familiar
  leaverou: Una's proposal uses lch(), which does the right thing by
            default
  leaverou: but worries me, e.g. doesn't have alpha
  leaverou: what more is it missing, that we need to add?
  leaverou: If we add 10 different keywords, then gets too big
  leaverou: the only benefit is very clear what the target color
            space is
  leaverou: Obvious when you convert colors
  leaverou: clear what's going on
  leaverou: but it's also more complex
  leaverou: Clarity comes at a cost

  chris: I like being explicit about the color space of computation
         and result
  chris: converting from starting not hard
  chris: _ is awkward, but might be familiar to people using SASS etc,
         where they construct the result bit by bit
  chris: Also like using calc()
  chris: You could do all sorts of interesting things with calc(), so
         that's a strength
  chris: If we do get on to cmyk and 7-color printing, hexachrome
  chris: we don't have to invent new things
  chris: we just get them for free because it's whatever position it
         is in the syntax already
  chris: but...
  chris: Una's proposal does 3 things and each function
  chris: Your proposal does only one thing, doesn't do the other two

  chris: The color functions become extremely complicated syntactically
  chris: First thought was I didn't like this because looked
         complicated
  chris: I would like to dive more into what serialization is
  chris: In general need to understand what serialization is and
         what's stored in DOM
  chris: Right now colors are stored as sRGB and that's it
  chris: Everyone that's seen the color spec, yeah this is good, have
         LCH and ICC colors
  chris: high dynamic range etc. solved problem, doing this the right
         way

  chris: But interested in how browsers are going to add this
  chris: So would like to hear comments from implementers
  chris: Both of these also depend on existing color functions, so
         need implementers to comment on that too
  leaverou: Both of these would require implementation of LCH
  AmeliaBR: Do any browsers have work on the way to implement more
            advanced color spaces?
  TabAtkins: Don't have work on it, but also LCH is only matrix-math
             different from sRGB, so not hard, just need some
             engineering time
  chris: All the matrix math is in the spec
  chris: also don't have to implement it like that, can also use ICC
         or color sync
  chris: Does all that as well
  AmeliaBR: Lea's syntax can be implemented in parallel, since still
            get adjustments on rgb and hcl, just that the best
            artistic results come from lab or lch
  leaverou: If HSL adjuster is implemented first and then LCH later,
            then more likely that existing designers will use HSL even
            though it's not as good
  fremy: Well it works for them
  <fremy> (to correct the notes, I just said that if designers end up
          using it, that means it worked for them, if the result isn't
          good enough, they can learn how to improve)
  chris: It works for them because it's the only tool they have
  TabAtkins: If you have both, there's no reason to use HSL, LCH is
             wayyyy better
  TabAtkins: Only reason to include older worse ones is compatibility
             with existing color systems
  TabAtkins: but want to make using the good function the easy path
  TabAtkins: so people use it and get happy results

  una: Problem with Lea's proposal is harder to understand what's
       going on
  una: Harder to follow what's happening
  una: Taking concepts of color space transform + set clipping space,
       transformation space, and output clipping
  una: then build on that
  leaverou: That's what I was wondering about as well
  leaverou: ? lightness and hue cover a large percentage of cases.
            Unsure about individual color channels
  leaverou: SASS has these, wondering if we can get usage stats
  leaverou: See how many people need them and what use cases are
  leaverou: most use cases I've come across are saturation and
            lightness
  chris: Making a color "more green" is a bit straightforward in rgb,
         but going towards blue-green... makes more sense to give a
         target color and go closer to that

  chris: Myles, you're building on top of ColorSync, would be
         interested in what would be hard to do easy to do etc.
  myles: Not prepared to answer that

  leaverou: Issue with 2nd one being underscores, could be some
            keyword or whatever.
  leaverou: Was an underscore only because avoids conflicts within
            color function

  astearns: Anyone from implementers with enough color experience?

  AmeliaBR: Reminder that use cases for color modification is
            increasing steadily
  AmeliaBR: First with custom properties
  AmeliaBR: You can't do it in the preprocessor, has to be in the
            browser to work with dynamic colors
  AmeliaBR: Going into dark mode and using system colors, don't have
            concrete color to manipulate
  AmeliaBR: need to do dynamically in the browser
  una: contrast-color important for dark mode especially
  una: These work hand in hand with changing technology being
       implemented in browsers now

  heycam: One other syntax comment -
  heycam: In 1st proposal, have adjust-color(), but we have a
          color-adjust property...
  AmeliaBR: Could go back to color-mod()
  TabAtkins: Also switch it to color-mix()
  heycam: And color-contrast() to match

  astearns: Comment about Una's proposal requiring LCH ...
  astearns: ...
  astearns: Want to reserve the default for LCH, require a color space
            until LCH is around, then allow that to be dropped
  TabAtkins: I object
  TabAtkins: I don't think the LCH part is the engineering blocker
  TabAtkins: They're both relatively easy thing that just need effort
  TabAtkins: getting it right the first time
  TabAtkins: If someone wants to implement adjust-color(), then doing
             LCH also isn't hard
  dbaron: Implementing color modification functions seems
          significantly more work than implementing LCH

  markus: ... Adjustment of image color
  chris: There's a long running FF bug about ICC and images, maybe
         just for raster images?
  Markus: ? is working on image color adjustment
  TabAtkins: Handling profiles but not anything else... so outputting
             rgb as monitor color space?
  chris: Can see the difference on my screen, Chrome really gives you
         the desaturation , Firefox ...
  heycam: Since we don't color adjust CSS colors, which aspects of
          these proposals would not be possible ?
  TabAtkins: None, just do the math
  TabAtkins: If you have badly-adjusted colors mixed with other
             colors, you have a problem, but
  TabAtkins: in a consistent color space, get better colors later
  Mmrkus: Nothing hard in the spec from my perspective
  markus: Hard part is Firefox doing color management in the first
          place
  markus: I don't know about parsing / serialization, but in terms of
          spec hard part is just finding the right syntax
  AmeliaBR: Rendering resulting color is a separate, but result of
            these functions is going to be another color function
            using existing color function syntax

  AmeliaBR: Question of what do we do about browsers trying to squish
            color functions into hex codes when requesting computed
            style
  AmeliaBR: but that's an issue with all advanced gamut color functions
  chris: It's even an issue with sRGB
  chris: If you go into wide gamut or high gamut, not enough storage

  leaverou: Tab, you said that colors mixed being in same color
            space... do you mean can't mix colors from different
            spaces?
  TabAtkins: When mixing colors from different spaces and no color
             managing
  TabAtkins: Then colors that look like they match won't later once
             you fix
  TabAtkins: but if define the mixing color space then it's OK
  [unsure if that was minuted correctly]
  AmeliaBR: If you have an image that uses a color properly calibrated
            red
  AmeliaBR: and you have an uncalibrated red in your CSS, then your
            color scheme will look bad
  TabAtkins: Used to be that RGB 255,0,0 in an image could look
             different from red in CSS
  dbaron: Depending on whether image had color profile data
  una: You can mix colors from different spaces, have to specify
       mixing color space
  leaverou: Would be nice to have defaults so that you don't have to
            specify if you don't want to
  leaverou: e.g. default to LAB if they're not in the same space

  TabAtkins: One aspect of mixing proposal is nice to mix a single
             channel
  TabAtkins: Not directly interpolation
  chris: That is an advantage of Una's proposal
  chris: You could have a ProPhoto RGB color and an adobe RGB color and
         mix the lightness of them, which neither color space has

  myles: In first proposal, contrast-color is different from first two
         options
  myles: contrast-color might be unimplementable depending on
         composting and how far back you have to go back through to
         find the background color
  myles: and if you don't punch through, kinda useless
  TabAtkins: I don't think punching layers is good, problematic for
             implementations
  TabAtkins: have to be in a reasonable situation like background
             color on your element
  myles: But is it good enough?
  una: Could require the first argument to be a solid color

  dbaron: What is the computed value if you do this contrast color
          thing?
  una: Result would be a color
  dbaron: In terms of CSS computed value, how is contrast-color going
          to inherit?
  chris: I think the computed value would be the winning color
  TabAtkins: It's a good question, need to figure that out

  AmeliaBR: Question of how we dealt with currentColor -- it inherits
            as a keyword, and also wanted to switch the system colors
            to do that also
  AmeliaBR: If we do that, then it would be awkward if the contrast
            selection is set at the body level but the actual element
            using that color has now the value of that variable or
            keyword has a different value
  chris: If computed value is as specified ...
  leaverou: Even if it's a CSS variable, it could have a different
            value on the child

  dbaron: Part of my concern here is that except for this thing, it
          seems like the computed value can be computed to a color
  dbaron: but this is the one thing in all this color adjustment stuff
          thats "layout"-dependent thing
  TabAtkins: I don't think so... but if one of the options s
             currentColor or currentBackground or whatever, then it's
             an issue
  fantasai: System colors also vary by element
  dbaron: When you're doing style computation, you know what the
          computed value of the color property is. So you can know
          what currentColor is as a color
  AmeliaBR: We choose to inherit it as a keyword rather than a color
  dbaron: Same for system colors. You can do the lookup
  TabAtkins: Then I don't understand why other color mods are different
  <chris> https://github.com/jonathantneal/postcss-color-mod-function
  dbaron: I think all of that can happen in computed value
  dbaron: The question is, is this definition of "what is the relevant
          background to contrast with", what does it depend on and is
          it something that can be resolved at computed value time
          locally?
  dbaron: Or do you need to do layout to find out?
  TabAtkins: Just being able to contrast with element's own background
             would be enough
  AmeliaBR: I think it's better to leave out idea of "current
            background" rather than having overly-simplistic definition
  <fantasai> AmeliaBR++
  una: We can leave out current background for now
  una: You don't need it because you can put currentColor in that slot
       and specify the background behind currentColor
  emilio: You can use -webkit-text-fill-color
  chris: If syntax is you put two colors in here, then new keyword

  myles: I brought up contrast-color in order to differentiate from
         other functions
  myles: picking between proposal A and B, contrast-color is distinct
         from either
  myles: Ignoring it for the moment
  myles: Both of these proposals are saying here's some syntax, take
         the color, do some math in a color space, and then put it back
         into a color space
  myles: But do designers think in that terms?
  myles: Amelia said about blend modes
  myles: Instead of describing as channels independently, maybe match
         ?? maybe match better how designer would think about it
  AmeliaBR: I don't think they're opposing concepts
  AmeliaBR: I think Una's proposal had an adjust color and a mix color
  AmeliaBR: I'm suggesting an adjust color using one of these syntaxes
  AmeliaBR: And a blend color
  AmeliaBR: Adjust color is lighten or brighten or dullen
  AmeliaBR: Mix is for people thinking more of combining two colors
  AmeliaBR: You can interpret lighten / darken as combine with white/
            black
  AmeliaBR: but you can't make saturation brighter or duller that way

  leaverou: Wrt proposal A and B
  leaverou: My proposal doesn't have mix color or contrast color
  leaverou: so it's really about picking how to do the adjustments
  leaverou: lighter / darker / more opaque / more translucent / etc

  TabAtkins: We have strong existence proof that people do think about
             this in terms of color adjusters, because every
             preprocessor has a variant of channel adjusters
  TabAtkins: Might not be ideal, but super common

  leaverou: Wrt blending modes
  leaverou: My experience is that designers don't really understand
            how blending modes work, they just try things until they
            get the desired result
  <astearns> +1 leaverou
  leaverou: Every time I give a talk about them
  leaverou: people come up to me, I didn't understand how these work,
            just tried different ones to see the result
  una: ...
  una: You can also click around in devtools to see what works for you
  una: A huge use case for color functions is to create palettes from
       a single source
  una: so you'll still need color adjustment and not just mixing

  mstange: Two existing ways to mix colors
  mstange: gradients
  mstange: and transitions
  mstange: Is the ? color function equivalent to what those do?
  mstange: or is that something we want?
  TabAtkins: We should offer one
  TabAtkins: Both of those interpolate in pre-multiplied sRGB space
  TabAtkins: not ideal space
  TabAtkins: but good to provide that so can match
  una: Could remove arguments of which manipulations, and then mix
       those two colors evenly by default in sRGB
  AmeliaBR: Agree that if we have a default it should match default
            for gradients and transitions
  AmeliaBR: I would also like to define gradients and transitions to
            one day use other color spaces
  AmeliaBR: e.g. color-interpolation from SVG which nobody
            implements :(
  AmeliaBR: want to say "mix in LCH"
  chris: Had that in spec 10 yrs ago, had to take out
  chris: Not that we control via CSS, but anti-aliasing of foreground
         shape and background shape, that also requires interpolation
  chris: and that's again different
  chris: but it's all linear interpolation and have to specify the
         color space

  leaverou: Drawback to interpolation in LCH?
  TabAtkins: Doesn't match
  leaverou: But result is same or better?
  TabAtkins: Probably
  <TabAtkins> what space does anti-aliasing basically take place in?
  <AmeliaBR> depends on the compositing color space of your system/
             browser
  <TabAtkins> ah, kk

  markus: So if I'm shifting from red to green, do I go around the
          circle or through to gray
  chris: L axis
  chris: black is zero
  chris: 100 is reflective white
  chris: on screen whatever native white is
  chris: 50% is visually midway between black and white
  chris: if you move 10% it is equal -looking steps
  chris: then have A and B axis which are cones from your eyes
  chris: ... opposite color through the L
  chris: ...
  chris: LCH is the polar form of that, you have a hue angle starting
         from A axis and going round
  chris: You have chroma which is like saturation but better
  chris: L axis is neutral axis
  chris: that's perception
  chris: moving by constant amount
  AmeliaBR: To answer your question, you're converting a color to a
            vector of 3-4 numbers, and then doing simple interpolation
            of the numbers
  chris: If you interpolate LAB you'll get a straight line
  chris: If you interpolate in LCH you'll also sweep through hue
         angle, see the rainbow
  chris: If you want to go through gray then you want LAB

  AmeliaBR: Can we make a resolution that we all agree color
            modification functions are a good idea and have them?
  chris: I would like us to do that, actually
  chris: People think we don't care, but we do
  TabAtkins: It's just that my previous proposal sucked

  fantasai: My suggestion would be: if we have a clear idea of which
            proposal we want, we should decide now, but otherwise, we
            can put both in the spec for now
  fantasai: Then it's not just a giant issue, we can work on it, we
            can iterate, and people can see what we're working on
  chris: I like that idea, but I'd rather do it in css-color-mod-1
         rather than css-color-5
  fantasai: I think we should finish color-4 quickly, and then color-5
            won't seem that far out
  AmeliaBR: If color mod and LCH come together can be in the spec
  <dbaron> the Color Modifications Level 1 not to be confused with
           Color Adjustment Level 1
  <TabAtkins> css-colormod
  AmeliaBR: We have two proposals right now
  AmeliaBR: Contrast function seem to all like that except for current
            bg, so maybe resolve on that?
  leaverou: and maybe mixing?
  AmeliaBR: And I recognize that blending is nice but confusing, stick
            with mix with color space option
  astearns: LCH is not currently in color 4?
  astearns: So could put this into color 4
  fantasai: I think we should put into color 5 and get color 4 into CR

  chris: Implementer interest???
  TabAtkins: We're done with the *spec*, we can put it into CR. Just
             can't go to REC because waiting for implementations.
  fantasai: We don't want to conflate REC and CR. Even if we don't
            have implementations, if we're done with the spec, it
            should go to CR
  fantasai: And then this new stuff needs design work, so it should go
            in different level because we'll file issues, make big
            changes, etc. So new level or new module
  fantasai: I'd prefer color level 5, because it really is the same
            scope as colors in general
  leaverou: One issue with putting in a separate module, if we go with
            proposal B, it modifies the grammar of the <color>
            functions
  AmeliaBR: That's a good argument for color level 5
  astearns: Chris, would you object to css-color-5?
  chris: No, and volunteer to edit
  TabAtkins: I don't want to, but maybe Una?
  una: sure
  astearns: So put some subset of these proposals into css-color-5
            with Chris and future Una as editors

  RESOLVED: Put all the proposals into css-color-5, ChrisL and future
            Una as editors

  myles: Please please please no underscores
  chris: Some languages are positional, others need to name them...
  TabAtkins: We have lucky thing that function name gives
             single-letter name of channels
  TabAtkins: Can use that
  leaverou: but what about alpha?
  TabAtkins: a
  leaverou: but LAB? It has a, plus alpha.
  TabAtkins: other a!
  ...
  <heycam> rbga(x, y, z, w) => rgb(calc(x + 20), 100, calc(z - 20))
  <heycam> to name the arguments you want to use
  <TabAtkins> rgba(from blue, r g calc(b * .5) a(.2))
  <leaverou> TabAtkins what does a(.2) do?
  <TabAtkins> sets alpha to .2
  <leaverou> TabAtkins: why not just .2?
  <TabAtkins> uh, yeah, right, that makes sense. Ignore me. ^_^
  <TabAtkins> or well I guess it would be `/ .2`
  <leaverou> TabAtkins so rgba(from blue, r g calc(b * .5) .2)

  astearns: let's resolve to put color-contrast in the spec
  una: Going to rename color-contrast, color-mod, color-mix

  RESOLVED: Rename to put 'color' first, adjust-color -> color-mod()
  RESOLVED: Add color-contrast() without currentbg

  fantasai: We should make sure we align it with the syntax for
            crossfade
  fantasai: ... to the extent possible

  RESOLVED: Add color-mix(), try to align with cross-fade()

  astearns: So two remaining option for color adjust
  astearns: Could put both in the draft and add an issue that we only
            need one of these
  astearns: or show why we need both
  astearns: or decide now on which to pursue
  astearns: anyone have a strong opinion which way to go?
  TabAtkins: I'm reasonably leaning towards Una's proposal because I
             helped work on it
  <AmeliaBR> And color-mix suggesting the name of mix() for the
             generic interpolation of numbers, etc.
  fremy: My perspective is, Lea's proposal is very useful but believe
         strongly we can do that with custom functions
  fremy: This is kind of math we can do with it
  leaverou: How does that work?
  AmeliaBR: It's a Houdini proposal
  astearns: I think that's true of all of these functions
  fremy: Arbitrary math it's not different from doing math in JS
  fremy: but Una's proposal translates to designer vocabulary
  fremy: I don't think there's value in creating a new function with
         special parsing etc. for math
  fremy: I would prefer to do a custom function, re-use in your JS
  chris: Are you arguing to remove calc()
  fremy: what???
  astearns: This is not a useful discussion.
  leaverou: They are equivalent modifications, just syntax is different
  fremy: Yes, but if I have to choose between them I prefer the one
         more scoped to what designers use
  una: My proposal is more simplified than Lea's, hers has more power
  una: You have to specify each channel even if blank
  una: but first proposal is simplified version, do by channel, but
       using keywords
  fantasai: I suggest putting both in the spec, issue at top, request
            feedback
  astearns: Useful to have both proposals in a spec where people can
            see them
  fantasai: And also file issues, improve them, and compare the
            improved versions as well
  <leaverou> basically to use the same example it's color-adjust(blue
             lightness(120%) chroma(.4)) vs lch(from blue, calc(120% *
             l) calc(.4 * c) h)

  astearns: Arguments against?
  AmeliaBR: It needs to be very clearly set out even if someone is
            jumping to heading in the document
  AmeliaBR: so people following along can follow the options
  <fantasai> Can also put the .annoying-warning there
  astearns: Also, I expect us to chose only one, but it might be that
            we end up with both
  astearns: if we have good justification have both
  una: Also might be able to combine them
  una: because same calculations, less explicitly laid out
  ...
  TabAtkins: lab vs alpha!
  leaverou: write out 'alpha'
  myles: But one is clearly more powerful than the other, it uses calc
         & you can put anything in there. The other only does
         multiplications
  <florian> +1 to putting both in color-5
  astearns: My proposal is to put both proposals into css-color-5 with
            keywords instead of underscores
  astearns: and start opening issues to discuss bits we want to modify

  RESOLVED: Put both color adjustment proposals into css-color-5, with
            keywords instead of css-color-5

  <florian> fantasai: are there other things we know we should put in
            color-5?

  RESOLVED: Add Lea Verou as editor of css-color-5

  Una: We're going to make it happen! As long as you make it happen,
       implementers :)

  <br type=5min>

CSS Text 4
==========

  RESOLVED: Add Florian as editor of css-text-4

Backgrounds and Borders
=======================
  Scribe: fremy

Borders with cut corners
------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3457
  spec: https://drafts.csswg.org/css-backgrounds-4/#corner-shaping

  una: corner-shape is something that Google uses in the material
       design system
  una: It works on ios and android
  una: but not on the web
  una: I tried to write this in houdini
  una: but it's not super straightforward because you need a
       background, a mask, etc...
  una: but since this feature is very common, I don't think the custom
       approach is very practical
  una: so I'd like to revisit the spec to reintroduce the corner-shape
  una: For instance, angled and rounds border are very important

  jensimmons: Can somebody summarize what we have done in the past?
  leaverou: Sure
  leaverou: What we have right now:
https://drafts.csswg.org/css-backgrounds-4/#corner-shaping
  leaverou: One of the reason this hasn't moved much is that it's
            trying to do too much and is scaring away implementers
  leaverou: and it turns out every time people ask me about this,
            people want angled corners
  leaverou: So I think we could remove a lot of the complexity and
            keep most of the use cases

  <una> https://material.io/design/shape/about-shape.html#shape-customization-tool
  una: [showing a couple of buttons, and some options like angle,
       distance, rounding...]
  una: Now we have to implement with custom shapes, but that would be
       better as part of css, because we could reuse colors and not
       have to define the masking
  rachelandrew: I concur a lot of people want this
  rachelandrew: and asked me for it
  [we are talking about angled borders]
  AmeliaBR: The border should follow the shape

  myles: what is the specific proposal?
  <AmeliaBR> `corner-shape: round | angle`
  una: What is in the draft minus scoop and notch, and rename angle
       and bevel
  myles: So the proposal is to drop values?
  una: And rename one

  dbaron: Two comments
  dbaron: One is that one of the difficult thing about adding things
          to the web platform is that we have to articulate how these
          new things have to work with all the other things in this
          area of the platform
  dbaron: and it so happens that borders are one of the areas where we
          already have a lot of undefined corner cases
  dbaron: Maybe the spec is better now, but we are not very
          interoperable now
  leaverou: Didn't fantasai do a lot of work on this already?
  fantasai: Yes, the cases we would introduce here are similar to the
            things we had to define for rounded corners
  fantasai: so globally I don't think this would be too undefined
  <AmeliaBR> For rendering, this affects: drawing borders (dot/dash
             spacing, color or width changes at corners), clipping
             backgrounds, replaced content like images, and child
             content (if overflow is hidden), box shadow shape, hit
             testing.
  dbaron: But even then, there are so many weird things about borders,
          and each of these weird features have their own code paths
  dbaron: and even special codepaths for specific combinations
  dbaron: and I'm concerned about it
  astearns: For instance shape-outside, etc
  dbaron: And clip for instance
  fantasai: I think this would be manageable
  dbaron: An example I would want to mention is one time where we
          spent 30% of the time in rendering gmail in drawing border
  dbaron: and that is because border has a lot of cases, and all of
          them have to be fast
  myles: Sure, but we are trying to drop values, so this is better
         now, right?
  dbaron: Well there was also encouragement to implement, right?
  myles: Sure, encouragement received, but we could discuss the
         proposal
  <dbaron> Example 1 in
https://drafts.csswg.org/css-backgrounds-4/#the-border-color
           looks hard to do in reality...
  <fantasai> dbaron, that's not even what we're discussing, though
  <AmeliaBR> That's a separate issue, dbaron!
  <dbaron> I think it's not a separate issue, because we're talking
           about dropping two of the four values from a feature that
           was optimistically put in the spec without clear
           implementor interest

  bkardell: You mentioned that Houdini was difficult to use?
  bkardell: Could we have done anything better to make this easier, or
            is the problem just hard in general?
  bkardell: (asking because this has been around for a very long time,
            and didn't get traction, so it might never happen)
  una: I think the main reason I want to standardize is that this is
       very common
  una: Houdini is great for custom things, but it's complex here, and
       this problem is common, so I think this should be a default
       provided feature
  una: To get this right I have to mask the corners
  una: Having to define both a background, a border, a mask, so in the
       end it's very heavy on the usage side
  una: in the end it works, but it's not great
  iank: Also, you can't easily incorporate the clipping effect of the
        border-radius in various other properties, painting is just
        part of the story
  iank: Also need to handle hit-testing
  florian: The spec notes that the outline should follow corner-shape
           but no browser does, except sometimes for auto
  bkardell: But border does, so people sometimes use borders for
            outlines because they are so powerful

  leaverou: An interesting thing I was wondering is that maybe we
            could we could use a new better name for border-radius to
            define the radius to have a fallback to sharp corners
            instead of to rounded corners?
  fantasai: Yes, but it's a worse name, and we can already use
            @supports
  leaverou: Ah, true, then I guess we prefer to stick with the best
            name

  astearns: Anything else on this topic?
  fantasai: we need a resolution to drop the two values
  astearns: yes, and I think it's a good idea
  astearns: I however I want to point out that the border-radius took
            so long to implement that by the time it shipped people
            moved to other designs
  astearns: So do we know that material design is not going to switch
            to another type of border by the time we ship?
  una: People still use border-radius a lot actually
  fantasai: Also, there are a lot of other cases where we need special
            shapes and polygons
  AmeliaBR: For instance parallelograms are useful, and difficult to
            make in css
  <tantek> clip-path solves the BSG use-case:
https://css-tricks.com/notched-boxes/
  astearns: Okay, let's move to the resolution, does anyone object to
            that?

  RESOLVED: Drop the less useful values, and rename as proposed in the
            issue

  astearns: Anything else on this topic?
  una: No, thanks
  [discussion about implementer interest]
  iank: That's a lot of work, and we didn't see enough use cases yet
        to change our prioritization, but we would be happy to adjust
        based on more data
Received on Saturday, 6 July 2019 22:52:40 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 6 July 2019 22:52:41 UTC