- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 6 Jul 2019 18:51:47 -0400
- 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