- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 Mar 2021 19:04:07 -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.
=========================================
Cascade / Pseudo-elements / Values / Fragmentation
--------------------------------------------------
- RESOLVED: The return value of getComputedStyle to match Firefox
behavior that first-line is ignored in getComputedStyle
(Issue #1510: currentColor when fragments have different
colors)
Color
-----
- RESOLVED: Clamp values between 0-100, all other values are invalid
(Issue #6047: How should negative percentages behave in
color-mix()?)
- RESOLVED: Highlight color represents selected text color which is
what you'd use for ::selection (Issue #6008: Consider
clarifying Highlight system color, and maybe adding a
new system color for control background)
- RESOLVED: Add keyword to represent selected item with name TBD
(Issue #6008)
Flexbox & Sizing
----------------
- There were some complex questions which need to be discussed in
order to resolve issue #6069 (Interaction of flexbox minimum
height and aspect-ratio minimum height) and the group ran out of
time on the call to cover them all. Discussion will continue on
github.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Mar/0029.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Christian Biesinger
Mike Bremford
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Sanket Joshi
Jonathan Kew
Daniel Libby
Chris Lilley
Peter Linss
Myles Maxfield
Morgan Reschenberg
Jen Simmons
Miriam Suzanne
Lea Verou
Scribe: dael
Reminders
=========
Rossen: Let's get started
Rossen: Couple of reminders
Rossen: Next week is our extended call time
<Rossen> https://wiki.csswg.org/planning/virtual-april-2021
Rossen: I would encourage you to put your name on the wiki if you
are going to be present during next week's extended call
hours
Rossen: Tuesday and Thursday pacific time
Rossen: We have 9 issues marked. We'll need at least that many to
fill the days. Please mark issues needing discussion and
good for F2F
Rossen: When you put yourself on wiki we can manage the schedule
Rossen: I wanted to also remind you, last week astearns talked about
longstanding PRs. Made a bit of progress, thank you to those
that engaged. We have more, so please pay attention to those
Rossen: I think we have a few documents ready for publishing, but
not yet published. It would be good to push through
Rossen: Any last minute agenda items or anything you want changed in
current?
Cascade / Pseudo-elements / Values / Fragmentation
==================================================
currentColor when fragments have different colors
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1510
<fantasai> https://github.com/w3c/csswg-drafts/issues/1510#issuecomment-803203212
fantasai: We discussed what to do when an element is fragmented so
it has different parentage. Span split between first and
second line and there's a first-line pseudo. Decided on
inheritance and a bunch. Resolved currentColor or em or
resolved per fragment
fantasai: Firefox has implemented this based on test cases in issue.
Edited in
fantasai: Don't have answer when you call API like getComputedStyle
on the element. Has one style per element. Proposal is
define the API which assume single value per box must
ignore effect of non-tree abiding elements
fantasai: Means span split across 2 lines pretends first-line pseudo
is not there. You don't have to compute differently if
have broken across lines. Seems to be what Firefox is doing
fantasai: Want to run past working group
Rossen: Proposed behavior is similar to that of first-line for
getComputedStyle?
fantasai: Talking about defining the case of first-line for
getComputedStyle
Rossen: Rephrase: if you have an inline item that has a spec
line-height and you do getComputedStyle and that line item
has a number of fragments, one if first and one in second.
getComputedStyle will return the first. Perhaps line-height
isn't good example. What returns used values
TabAtkins: Color
Rossen: What would color return?
fantasai: Color it will ignore the first-line style. First line is
blue, span on second line and it's black. Span splits it
returns black. Span on the first-line still returns black.
That way browser doesn't have to take into effect if the
span breaks. We ignore first-line styles
fantasai: Could say take style of first box fragment. That's another
possibility
Rossen: Okay, makes sense. Thank you
Rossen: Any feedback?
Rossen: If not we can call for objections
oriol: Concern is usually cascade is in element tree and this is in
fragment tree. Given display:contents you can have elements
without fragments in fragment tree. Not clear it's well
defined. Might be outside of scope of the issue. It may need
extra work in the future in another issue
Rossen: Thanks oriol
fantasai: Either way we need an answer for what getComputedStyle
returns
Rossen: Proposal here is have the same behavior as Firefox and as
you described for color?
fantasai: Yep
fantasai: 2 things that could make sense. Return the styles ignoring
first-line. Other is return style of first fragment.
Firefox has implemented first option so we propose that.
Rossen: Implementation point of view this is easier. User point of
view these are equally wrong since you don't have per
fragment access. For consistency sake with current impl I'm
in favor of that proposed behavior
Rossen: Not hearing other proposals. Objections to resolve return
value of getComputedStyle to match FF behavior that
first-line is ignored in getComputedStyle
RESOLVED: The return value of getComputedStyle to match Firefox
behavior that first-line is ignored in getComputedStyle
Rossen: Anything else on this?
fantasai: Just need to fold in edit
CSS Color
=========
How should negative percentages behave in color-mix()?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6047
Rossen: Do we have right people to proceed?
many: yes
TabAtkins: chris, leaverou feel free to jump in
TabAtkins: A few weeks ago talked about color-mix and grammar.
Matching so each color has a percent and normalize to
100% if don't sum
TabAtkins: Further question about what should allowed range be.
cross-fade only allows 0-100 and if you exceed it's
invalid. leaverou and chris argue allowing other values
make sense. Have justification for it that I can't parse.
una and I on side of not doing that and matching
cross-fade
TabAtkins: Argument is that negative percent and greater percent
don't accord with mixing colors we're trying to define.
Not intuitive, though mathematical, and would confuse.
Also, when normalize to 100%, that is extraordinarily
weird with negative percent
TabAtkins: You have to grow values to sum to 100% and get very
strange large results. red 100 and blue -100 there's no
way to resolve. Sometimes you get sum but multiply by
negative to get it. Even if it's well defined the edge
cases are very weird.
TabAtkins: leaverou and chris have added explanations, but I think
they contradict
leaverou: Not sure we should base on cross-fade which is something
not widely implemented. Only 1 or 2 implementations and at
least webkit is not per spec. Not sure why design based on
that.
leaverou: Main point is there is a place in css where we color
interpolate and allow wider range. In transitions. You can
have cubic bezier that's out of range and it does what
chris and I advocate
leaverou: Can look in issue for results, don't think it's
unintuitive. If you mix with blue -% you get a less blue
color. Blue coordinates in sRGB is less but hue is less
blue which is what matters
leaverou: If you mix -100% something it's weird, but edge cases that
are weird in everything
TabAtkins: What you said is wrong. It doesn't make it less blue.
It's dependent on other color. I have an example where
-blue + green is more green
chris: We need to avoid saying you are wrong in these discussions.
chris: We're talking about a hue angle. Not gamma encoded.
TabAtkins: Agree you don't get a hue. I have green + negative blue
and you get more green channel
chris: You're looking at gamma encoded channels. Can't do it like
that. Look at actual color
TabAtkins: Would you like me to show you color and you can tell me
hues
chris: Not going to do calculations on the fly
chris: You can't present as leaverou and chris have weird idea,
color science has this idea. There is a positive case. You
get ringing artifacts on the transition. We're not saying
great use case for -300%. We're saying sometimes you have
slightly over or under. You have line extend out past the 2
colors on chromatics.
chris: I get it could be unintuitive, but possible to spec and
reasonably useful. I'm fine with clampping 0-100, just
suboptimal
leaverou: If we end up not allow they should be invalid. Silent
clamp there's no feedback to authors and can't change
Rossen: Point of order. Conversation is lively. chris I appreciate
working with tone. I want to discourage blaming and direct
language. Let's focus on issue here.
TabAtkins: Real quick, I'm talking about facts here. Casting me as
saying this is technically wrong is being heated is
disappointing. I don't want this as TabAtkins is angry
because I'm saying the math doesn't back up what you're
saying. As far as I can tell my examples show that the
math is wrong. I want to focus on that
Rossen: Let's continue to focus on that math. Leave personal out of
discussion
Rossen: There's 3 folks on the queue. leaverou and chris you had
taken turns. Are you done?
chris: Let's let miriam speak
miriam: Reading this from mental model I liked in TabAtkins last
comment the suggestion if we want allow negative mix better
framed as color interpolation. If we want extending past the
mix that would get a new name and syntax. For mixing we
would clamp or make invalid numbers above or below 100 or 0
Rossen: Hearing 2 folks suggesting clamping between 0 and 100 is
fine as long as rest of range is handled as invalid
chris: Agree. Silent clamp we're struck so if restrict have to
invalid
TabAtkins: Agree
florian: chris said he won't do color math on fly. Reasonable. If he
would do it offline it will show where the math mistake is.
Based on that if he disproves one math there's no reason to
continue.
TabAtkins: Happy to do that. Have a trivial example with single
numbers we can look at and talk about
florian: I would suggest we do it offline. Make sure everyone has
math right
chris: If we agree we're on 0-100 only we don't have to care about
math for others. We could get a decision. Would be okay with
it. We can extend later if needed
Rossen: I want us to get to a decision. leaverou is on queue
leaverou: Silent clamp or invalid, cubic bezier used to be invalid
outside 0-100. I suppose it wasn't deemed useful, realized
authors wanted it, and we did it. Making it invalid would
allow a similar path
Rossen: More support to making invalid
Rossen: I heard support from a few folks and TabAtkins saying it's
fine, I think
TabAtkins: That's my ideal result. Happy
leaverou: I'm not suggesting we make it invalid. suboptimal. but
invalid is less evil than clamp
<fantasai> +1 to leaverou
Rossen: And gives a path to make better when we're ready. Instead of
continuing to argue on what we're not ready to agree on, we
have something we are ready to agree on which gives us path
to extend
Rossen: Proposal: clamp values between 0-100, all other values are
invalid
Rossen: Other comments on proposal or objections?
RESOLVED: Clamp values between 0-100, all other values are invalid
Rossen: Rest of discussion is important. Recommend we continue to
have this, by way of examples, in the issue when people have
time for math
Consider clarifying Highlight system color, and maybe adding a new
system color for control background
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6008
emilio: We defined highlight system color as highlights. MacOS has 2
kinds, one for selection and one for stronger color
emilio: The question is, webkit exposes it and blink exposes via
webkit focus ring. Both colors are exposed, one with wk
prefix. Question is, should highlight be the selection color
or the other color?
emilio: Should we define a non-prefix of -wk-focus-ring?
fantasai: Reason we have system color is so authors can use forced
colors in a meaningful way. If I recall there's a handful
of colors in windows UI and took handful of colors in that
and added a few more that were missing. I don't remember
what highlight-color was supposer to represent, but should
clarify for that.
emilio: On windows only 1 highlight color. Selection color is same
as selected in styling
emilio: My point is that UA stylesheets should use system colors
exclusively for this. Respect dark mode, forced colors works
correctly. That can be magic
emilio: Ideally we would have 2 colors and I can remove prefixed
version. We don't have one exposed in macOS accent color. If
we say highlight should be selection I need a prefix for the
other. Ideally we would avoid it. Id rather come up with a
name for it and spec it
<chris> It was originally defined on Windows 95 and Java; it was
already out of date by Windows 98
<fantasai> chris, the non-deprecated system colors are the set that
matches Win10 forced colors mode
<fantasai> chris, that's what we need to align with
fantasai: First question is do we want to add separate keywords and
second is what do we call them. Let's do first question
first
emilio: Chris mentioned he wouldn't like to expose a system color
but they're doing it.
<chrishtr> The comments were not from me. :)
emilio: Someone mentioned it on the last call
emilio: I wanted to make sure if there is concern we can address that
Rossen: I'm unclear if this system color can be backed by actual
system colors
emilio: Browsers do different things. FF in some situations nervous
about fingerprint. Webkit doesn't do highlight, but does the
others.
Rossen: System colors make sense across all systems as they exist
now. This makes sense on some systems, not others
emilio: I think makes sense in all, but in some systems they're the
same
emilio: On windows when you have select multiple color of
highlighted item is same as selection color. Doesn't have to
be
Rossen: Weird to provide system colors from css and not other way.
System colors up till now were things in all systems and
drive enough need to expose and uniform enough across
platforms
Rossen: This is slightly opposite to me. We want to impose there's 2
colors and hope in some systems they'll add a different
color. To me is backwards requirements and we can't expect
platforms to take that and make the system color.
Rossen: Certainly not backwards into OSs in use
emilio: Not sure I agree. You're right windows won't have separate
color soon or ever. But that doesn't mean having 2 colors
doesn't make sense. They're conceptually different, even if
shown in the same color on windows
Rossen: I think I made my point here. I can't add anything to make
it clearer. Want to hear from others
fantasai: Agree with emilio they can map to the same color. Question
is do we add the value so systems that do distinguish have
ability to do so
florian: A little confused by your point. If trying to add colors
that don't make sense because on some systems you cannot
currently answer what is the system color because there's
2. If we add one and it's teal on both you can answer teal
on both. But if we add a section value it lets the other
system answer truthfully one is teal and one is blue
Rossen: Where is this conversation going?
fantasai: Two options. First define that the highlight color matches
either text selection or the select box color. Have to
pick because can be different on some platforms. That
leaves open do we define a keyword to represent other
fantasai: For Windows this question doesn't matter. For Mac it does.
If you ask for highlight, which color are you getting?
Rossen: Can anyone from apple answer this?
smfr: Currently it's the selection color. Not opposed to exposing
value to capture darker blue
florian: Given it's exposed already aren't you saying you need to
expose both and you're okay picking one because you have
both exposed?
smfr: I didn't follow.
fantasai: Highlight color represents selected text color. What you'd
use for ::selection
smfr: Which is what we do now
fantasai: Resolve on that, then talk about adding new color?
smfr: Fine
Rossen: What's the proposal?
fantasai: Highlight color represents selected text color which is
what you'd use for ::selection
Rossen: Objections?
RESOLVED: Highlight color represents selected text color which is
what you'd use for ::selection
fantasai: Do we want to add a keyword to represent selected item in
a list-box? That color.
fantasai: If we don't when you're in forced-color you cannot match
that color
Rossen: I'm not sure if silence is...I'll take it as agreement we
want the keyword
florian: Given it has a wk name I'd say yes
Rossen: Is there a name?
fantasai: Not yet
Rossen: Proposal: Add keyword with name TBD
Rossen: Objections?
RESOLVED: Add keyword to represent selected item with name TBD
fantasai: No great ideas on name
Rossen: Bikeshed in the issue
Flexbox & Sizing
================
Interaction of flexbox minimum height and aspect-ratio minimum height
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6069
<fantasai> https://github.com/w3c/csswg-drafts/issues/6069#issuecomment-790046695
<fantasai> https://github.com/w3c/csswg-drafts/issues/6069#issuecomment-797028657
Rossen: Summary ^
Rossen: Can you repeat it?
fantasai: Proposal is a non-replaced element ignores transfered
sizes for auto min sizing
fantasai: Auto min sizing in flex and grid where initial value is
auto. You take size of min-content so you don't shrink
flex item too much. On images with aspect ratio if you set
for a row flexbox a height on the image we transfer that
through aspect-ratio and modifies minimum
fantasai: Makes sense for images and that's what it was designed
for. For non-replaced boxes this makes less sense. When we
thought through we considered don't do this. Make this
behavior restricted to replaced elements. Don't apply to
non-replaced elements that have aspect-ratio added by
aspect-ratio property
florian: You're left with min prior to aspect-ratio being used?
iank: min-content or intrinsic
fantasai: For replaced element natural and min-content size is same.
fantasai: For replaced if you spec a size on the axis we clamp
auto-min by that size.
fantasai: Other than that we transfer that and other content and min
that.
fantasai: Non-replaced we don't transfer
florian: If the transfer aspect-ratio would have made min size
smaller clearly good to not do. If transfer aspect-ratio
makes min-size bigger is it not good to honor it?
fantasai: Trying to remember the logic
fantasai: This was because on items with an aspect-ratio...consider
a block with aspect-ratio. min-height: auto. Decided that
means element with an aspect-ratio will ignore
aspect-ratio if content is larger than height it would
have imposed by aspect-ratio. 1:1 aspect-ratio block.
100px width which gives 100h. 500px content so I have to
block 500px
fantasai: When you turn it into a column flexbox we want same. But
if we transfer size we can't get same behavior because
made auto-min dictated by aspect-ratio. To have same
behavior of the content blowing out the aspect-ratio in
both blocks we can't use same transfer behavior we have
for replaced
florian: Makes sense, thank you
fantasai: More like thanks cbiesinger
<cbiesinger> you're welcome
iank: This means a min-content size will ignore transfered min and
max heights. But min-content contribution will respect them?
fantasai: min-content contribution will have to take into
account...[thinks]...something complicated about this but
I don't remember
fantasai: I think min-content contribution needs to take it into
account. I remember complicity on how defined in a
different issue and I'm not sure if it was relevant there
cbiesinger: min-content contribution doesn't matter in flexbox?
cbiesinger: flexbox intrinsic sizes are defined in flexbox spec.
Rossen: Got it
iank: I asked about it to make sure it is applied there. grid spec
does use the min-content contributions directly
iank: In certain circumstances
fantasai: yeah
cbiesinger: I don't think we can use that in content contribution
because don't know content-height. We would create
circular
Rossen: Yes
Rossen: We're getting to top of hour. Doesn't sound like we're ready
to resolve on this. Not quite.
Rossen: Perhaps I would suggest we take it back to the issue and
answer the questions there and then resolve during the F2F.
Let's make sure we're not missing any of the points raised
here
Rossen: Let's end here
Rossen: Please add agenda F2F items and add yourself to the wiki
Rossen: I wish you a great rest of the week and we'll chat more next
week
Received on Wednesday, 31 March 2021 23:04:51 UTC