- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 Apr 2020 06:36:30 -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 Adjust
----------------
- The definition of forced-color-adjust did not allow a granular
enough level of control (Issue #4176: Cascade within
forced-colors MQ). The need was to allow it to be set on a
specific property or maybe even declaration.
- On call the suggestion was to leverage the ! syntax and create a
value like !override-color-adjust to have the override set
without having to create a new property that overrides existing
properties. This idea was widely supported and is the direction
the group wanted to move in.
- There were two seemingly good ways to specify the behavior of the
! syntax and discussion will continue on the github issue to
work out which is better between the two. Options:
1. color: blue ! override always beats color: red, even if red
would normally win the cascade.
2. color blue ! override and color: red cascade normally, and if
red wins in the cascade, then there's no longer an override
and the blue just gets ignored.
- RESOLVED: Select Option B [Based on its resulting computed color
value, the [computed|used] background-color of an
element is forced by matching all channels other than
alpha to the appropriate forced background color; which
should be the corresponding system background color if
color is a system color, and Canvas otherwise.] (Issue
#4175: background-color in forced color modes needs more
than a simple unset)
- RESOLVED: Publish updated WD of css-color-adjust-1
CSS Lists
---------
- There were three potential solutions for issue #4891 (Should
collapsible space after inside ::marker be preserved?):
1. Keep white-space: pre. Firefox is correct, changing Chromium
will be trivial.
2. Keep white-space: pre but add some magic that if a text
::marker has a trailing space and is followed by collapsible
spaces, then these collapsible spaces are removed, even if
the ::marker space is not collapsible. This will keep
Chromium's behavior but implementing this magic would be
annoying.
3. Say that inside markers don't get assigned white-space: pre
in UA origin. This is close to what Chromium does right now.
But I guess doing this properly would need pseudo-classes
like ::marker:inside and ::marker:outside, even if just for
internal use, but that would create a circularity if in the
future we allow setting list-style-position in the ::marker
itself.
- On the call the group was inclined toward option 3 but needed to
define how to do it before resolving as there were concerns
about doing it with a pseudo-class.
- After the call discussion continued and those conversations lead
to support of option 2 by using ::marker { text-space-trim:
discard-after; } to achieve the behavior without magic.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Apr/0000.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Dean Jackson
Brian Kardell
Peter Linss
Cameron McCormack
Alan Stearns
Miriam Suzanne
Regrets:
Chris Lilley
Manuel Rego Casasnovas
Lea Verou
Scribe: dael
astearns: Let's get started. Any changes to the agenda? We will skip
item 4
chrishtr: Did hober request move to F2F?
astearns: Just next week.
CSS Color Adjust
================
Cascade within forced-colors MQ
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4178
Rossen: Is fantasai on?
Rossen: I'll introduce.
Rossen: Brought up by some framework devs when starting to adopt new
forced colors MQ and forced-color-adjust properties
Rossen: Feedback is in contrast to previous impl in IE and Edge when
used high-contrast and high-contrast-adjust the MQ and the
way properties inside MQ evaluate is significantly different
Rossen: Boils down to it's currently...ergonomics are such that if
you decide to adjust a single color property inside a forced
color MQ you have to take over entire styling of elements
astearns: Because the forced color wins for MQ declaration?
Rossen: No. Current way to do it is you have to set
forced-color-adjust to none inside the selector in the MQ.
Once selected your elements, set it to none. Means you're
taking the entire element and its subtree from forced color
being applied
astearns: Why need to say none?
Rossen: To change border color for example
astearns: Because forced color will otherwise override?
Rossen: Correct.
Rossen: We have a MQ that detects forced-color-adjust. Just like in
example. When forced colors evaluates active inside MQ you
do whatever you want. In this case select disabled = true
elements. Wants to set the color of those to gray
Rossen: To do this today you have to set forced-color-adjust to
none. Otherwise color would be window color
Rossen: Making sense?
astearns: Yes
Rossen: Previous to that high contrast impl we had we allowed
individual property to apply to individual elements. Color
for that one property would override.
Rossen: That's the proposal of this change when it started. Since
there was discussion between AmeliaBR, emilio, and fantasai.
Rossen: fantasai's proposal which I want to understand better is to
do it other way around. Spec properties except ones you want
to adjust. So forced colors except in this case border-stroke
Rossen: Some support to this, but not seeing it recorded
astearns: Not sure anyone is agreeing with fantasai proposal except
something like it needs to happen
dbaron: Was going to say I think a way to frame this is what we want
is more granular way to override forced colors. A property
that's everything or nothing isn't granular enough. People
care about properties or maybe declarations. Maybe makes
sense to re-title issue?
dbaron: I think there's a 3rd option, complex, but have it in value
of property rather than separate property. In hindsight when
we have a property that modifies how another works we end up
regretting. I think this is like box sizing in that way. But
that's a lot of syntaxes to modify. Not sure if there's a
more elegant way to do it.
heycam: I wanted to agree with emilio's initial comment finding it
confusing if we change depending on what properties are
inside. In favor of some option that makes it more explicit
be that fantasai proposed or something like dbaron
heycam: Question on the MQ itself. Does it respond to value of
[missed]. Forced color property determines if MQ matches?
chrishtr: I believe proposal is not MQ but another property or value
that overrides instead.
astearns: It's an alternative we're discussing but so far no one on
thread has liked proposal to having MQ allow override
<TabAtkins> So a possible "adjust the value" option is to finally
jump into using new ! options. Like
`!override-forced-color`, so that *if* this declaration
wins the cascade, it's allowed to override a forced
color.
<TabAtkins> Then we switch forced-colors mode to, rather than using
the cascade and UA-!important rules, instead just use
magic to win the cascade automatically, *unless* the
cascade-winning declaration has the appropriate ! on it.
<TabAtkins> (And because we're using magic, this allows us to handle
multiple such override modes in the future, if we
introduce them, by internally handling conflicts, rather
than trying to rely on the cascade to resolve them.)
heycam: Question is what determines if the MQ matches. Is it the
property that enables forced-color-adjusting on a subtree?
Rossen: Request is to enable single properties on selected items to
take precedence over forced color
Rossen: Target BG color which is set to canvas. If you select a
given element within forced color active MQ we would have
allowed background color to take precedence over forced
color.
Rossen: Now to do it you have to first set forced-color-adjust to
none and take over everything by your self
heycam: Property to turn it to none would that make MQ not match?
Rossen: Not really. Mode of browser is still active
heycam: MQ is the overall mode, not individual sub trees where you
set that property?
Rossen: Yeah.
heycam: Cool.
astearns: Anything else heycam?
heycam: No
chrishtr: When you enforce colors mode I think there is no defined
spec for what UA does. Right?
Rossen: Not correct. Spec defining this is css-color-adjustment
chrishtr: Spells out exact stylesheets applied?
<astearns> https://www.w3.org/TR/css-color-adjust-1/#forced
<Rossen> https://drafts.csswg.org/css-color-adjust-1/#forced-color-adjust-prop
Rossen: We have the exact stylsheet? Asking if we define UA
stylesheet?
Rossen: No, we define colors are reverted to system colors. System
colors are defined in Colors module
chrishtr: Different than heuristic darkening of page
Rossen: Yes
<dbaron> https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties
is somewhat well-defined, I think
chrishtr: Any override is predictable to dev
Rossen: Yep
chrishtr: Got it, thank you
TabAtkins: I wrote stuff in IRC.
TabAtkins: Revisiting dbaron's comment about building functionality
into property value space. We do have a spot to do that
in syntax with guaranteed compat. Using stuff after !
which we only use for one thing. Syntax specification
allows for more
TabAtkins: Possible way to address particular properties overriding
forced color and to simplify is first switch forced color
to magically win cascade regardless of author. Then allow
author spec after a ! they override forced color. Say
it's explicitly meant even if forced. If it wins cascade
it doesn't get overwritten
TabAtkins: Same as figuring out how to insert a new keyword but
allows completely consistent regardless of value space.
Auto-extensible to future things. As well having forced
colors apply magically gives more flexibility if we have
to add more things like this
TabAtkins: Then can have resolution rules based on whatever
arbitrary requirements we need. Without having to worry
about cascade we let ! and author cascade determine
Rossen: Question. Your proposal is !override after property?
TabAtkins: Yeah
Rossen: Like it. Pretty cool
TabAtkins: ! value space is allowed multi value so you can do
!important override so we're not limiting authors
astearns: Talking about a generic !override or
!override-forced-colors
TabAtkins: More specific one
florian: On one hand what TabAtkins description makes sense for this
and has future extensibility. Does feel a lot like
additional cascade origins. Not long ago had proposal from
Miriam about having control over these things. I wonder if
we shouldn't try harder to figure out that story. Various
levels of cascade origin feels like what we're doing here.
Worth exploring before being sure that's not it
TabAtkins: Don't believe it's similar. While UA provided forced
colors live on a high cascade, cascade-origins doesn't
allow selective override unless we allow opt into even
higher cascade. I like my proposal because doesn't have
author cascade finagling. They have existing rules and if
they happen to be rules that should apply even in case of
forced colors you add an indicator vs having a different
cascade that auto-wins over another cascade that auto-wins
TabAtkins: You have one instance auto-winning all the time in that
case and that may not be what you want
miriam: Agree with TabAtkins. Feels different use case. I'd be
willing to dig in further to see if overlap but offhand
seems not same problem
astearns: Other opinions?
dbaron: Reference to custom cascade brought an interesting question.
If an author has rules they want to override forced colors
and other rules that would normally override them what
happens? Do we want that to be possible? Maybe one argument
is if author says this overrides forced color it overrides
all the other rules.
dbaron: Maybe want authors to do that. Some of these have confusing
outcomes. Might think someone wants it, but may be 1 person
wants and 99 are confused. Makes me think maybe more like
custom-cascade origins. Maybe this is a little more like
cascade. Worth thinking about what we want to allow and
what's too confusing
florian: I think we can do 3 things. One is you set super override
and always wins. Another is super override doesn't win if
you've overwritten it with the normal cascade. Asking for
trouble b/c people won't test with forced colors
dbaron: 3 is horrible
TabAtkins: Writing down 1, 2, and 3 would be good
<dbaron> 1. color: blue ! override always beats color: red, even if
red would normally win the cascade
<dbaron> 2. color blue ! override and color: red cascade normally,
and if red wins in the cascade, then there's no longer an
override and the blue just gets ignored
florian: If you have blue in your normal cascade which wins then
!red with specificity that doesn't win it's still blue. The
red lost already. That's 1
florian: 2 is !override makes red more important than forced color
and more important than blue. Implicitly important
florian: 3 which is bad is if !override-red loses to blue in normal
and override to blue and system is forced.
TabAtkins: Agree. 1st is per declaration. 2nd is mega-important. 3rd
is bad
dbaron: I think first is mega important
TabAtkins: Do we want to take this with the two good options to the
issue? Or decide now?
astearns: Rossen?
<dbaron> Issue discussion, I think -- there's a ton of stuff to sort
out here.
<dbaron> This 1/2/3 thing is a discussion within a discussion.
Rossen: It's easy to discount option 3. Exploring 2 is interesting
but I'm hesitant on mega-important.
<TabAtkins> I mean, !mega-important is just Custom Cascade Origins
Rossen: If we can agree on 1 vs 2 that's a path forward to
experiment and see how it works
dbaron: Feel like 1 vs 2 is a discussion in a discussion and there's
large points to sort out. Better in the issue
astearns: Can resolve that we'll solve this issue in the value space
TabAtkins: As opposed to properties, yeah
dbaron: When I said value space I wouldn't have counted TabAtkins
proposal as there, but I like TabAtkins proposal
Rossen: I like it as well
astearns: Let's take it back to the issue for now since we have
alternatives and people like emilio and fremy with strong
opinions. Then we can hopefully resolve soon.
<heycam> if there are many properties to override to adapt to the
forced color mode I wonder if it will be onerous to write
an !override on every property declaration
<TabAtkins> (Given a time machine, I'd have proposed adding
`!border-box` to the sizing properties, rather than
box-sizing. ^_^)
astearns: Any last words?
background-color in forced color modes needs more than a simple unset
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4175#issuecomment-603965581
spec link: https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties
Option A
For elements that have a background specified in the UA style
sheet, the background color is forced via:
background-color: revert !important;
Whereas for all other elements, the background-color is
instead adjusted by forcing all channels other than alpha to
match Canvas.
Option B
Based on its resulting computed color value, the
[computed|used] background-color of an element is forced by
matching all channels other than alpha to the appropriate
forced background color; which should be the corresponding
system background color if color is a system color, and Canvas
otherwise.
astearns: fantasai put 2 options into the draft
astearns: She asked us to choose between option A and B. Opinions?
AmeliaBR: I realized looking at...one thing requested was examples
so I did just post a reply with an example.
<astearns> https://codepen.io/AmeliaBR/pen/dyoLMGd
AmeliaBR: There are screenshots in the issue of what this looks like
in a couple high contrast modes.
AmeliaBR: Including ones that look broken currently in Edge
AmeliaBR: Main issue comes up when you have paired colors in high
contrast mode for button. Designed to work together but
because cascade you get a bg from normal text used with
your button text color and contrast falls apart
AmeliaBR: Other complications are transparency. I've got examples of
where we need to say opaque and where we need transparent
because if opaque obscures things it shouldn't
AmeliaBR: There are cases where option B fixes and option A causes
problems
AmeliaBR: If we follow option A [reads]
AmeliaBR: In my example I have an svg element inside a button that
doesn't have a ua background color and I have a custom
style div in a button. These would not get reverted
colors...Option A forces to canvas color which would be
very bad for some schemes.
AmeliaBR: In option B bg color is calc after inheriting out
foreground and finding all elements have button foreground
and therefore if they get a bg it needs to be button. Also
extra magic about if author supplied foreground was opaque
or transparent
astearns: So one vote for option B.
AmeliaBR: Option B for me. Option A would cause problems
Rossen: Did you try with non-buttons?
AmeliaBR: No, but it's child elements inside. Child in link is only
other case where you'd see it.
astearns: Argument for option A Rossen?
Rossen: Just trying to understand more.
astearns: Any arguments for option A?
<TabAtkins> I'm thinking B.
Rossen: Curious if fantasai has caught up
fantasai: I think AmeliaBR's proposal gets better results where this
matters. It's up to WG. Interested in hearing from
implementors. That's main concern is how impl would
florian: Implicit argument for option A is simpler
AmeliaBR: Both are complex because neither described by cascade.
Both need to look at author stylesheet and then do fixup.
Just a case of if they factor in current color
heycam: Rossen was your question if previous issue could be a
mechanism to solve this?
Rossen: No....I agree complexity of one or the other is not deciding
factor.
Rossen: Trying to work through AmeliaBR test cases.
Rossen: Not opposed to B if WG feels it's better. We can implement
and see what it looks like
astearns: Not hearing clamoring for A so inclined to resolve on B
and see how it goes
astearns: Objections to resolve on option B?
RESOLVED: Select Option B [Based on its resulting computed color
value, the [computed|used] background-color of an element
is forced by matching all channels other than alpha to the
appropriate forced background color; which should be the
corresponding system background color if color is a system
color, and Canvas otherwise.]
[agenda wrangling]
fantasai: Can we publish an updated working draft?
<fantasai> https://drafts.csswg.org/css-color-adjust-1/#changes
astearns: Objections to publish update WD of css color-adjust-1?
AmeliaBR: Nice to do other issue before, but we're publishing often.
fantasai: We should publish early and often
AmeliaBR: 4883 changes are mostly in color so yeah. no objections
RESOLVED: Publish updated WD of css-color-adjust-1
CSS Lists
=========
Should collapsible space after inside ::marker be preserved?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4891
oriol: Follow up of #4448 where we resolved ::marker is
white-space:pre in user origin. Because outside markers are a
block constrain and we wanted to preserve these.
oriol: When tried to impl some tests failed.
oriol: Problem is that [missed] usually doesn't matter if you add
trailing or leading spaces
oriol: If you write open tag, text, closing tag or open tag, new
line, text, another line, close tag it should look same
oriol: If we assign white-space:pre to ::marker the spaces are no
longer at beginning. They collapse as a space but not
completely removed.
oriol: If no space at beginning of list item you get one space. If
there's additional space you get 2 spaces. There no interop.
In FF you get two spaces if there's space in the beginning.
Other browsers it doesn't matter
oriol: Not sure which we want. 3 options. 1) keep resolution and say
FF is right there should be 2 spaces. 2) Keep white-space:pre
and add some magic which says if you have sequence of
collapsible spaces just inside you remove the spaces even if
trailing space of marker is not collapsible. This is behavior
of non-FF but magic is annoying and error prone
oriol: 3) Only set white-space:pre to outside markers but not inside
ones. Closer to what Chromium is doing though how Chromium
assigns it kind of hacky. Proper way with selectors is
defining marker-outside and marker-inside. If in future we
say that the list style position property applies to ::marker
instead of originating list item we have a circularity.
oriol: Leaning option 1 which is do what FF is doing right now.
Maybe less intuitive to authors but more consistent
TabAtkins: Option 3 was discarded for circularity but I don't think
need to be concerned. Only reason to allow is set within
a single list some markers outside and some inside and I
don't know why we would make that easy. I don't think
that will ever be the case. Never be a circularity for
::marker so we could through magic or pseudo let you
style inside and outside different
<dbaron> +1 to TabAtkins
TabAtkins: I think that's reasonable because I don't like display FF
gives. I think Chrome behavior is good, but need to solve
it a good way
fantasai: I'm wondering if FF behavior is regression from earlier
FF. Switch between inside and outside is old feature. I
wonder if it has always been that you would get double
whitespace in past or if relatively new since re-write
marker code
astearns: Anyone know?
[several] no
dbaron: TabAtkins covered part of what I would say. Other thing is I
think having white-space in markup in block matter is bad so
I think option 1 is bad. Little surprised FF does that
<fantasai> +1 to option 1 being bad
<dbaron> I think my preferences are probably 3 > 1 > 2, but that's
not a very strong opinion.
florian: I agree with TabAtkins. I prefer 3 between 1 and 3. There's
also option 2 and I would like to not do this. CSS 3 text
is already sufficiently complicated. It's hard to spec and
complicated and I would prefer not to add
smfr: Compat question- make any difference what we choose for compat?
florian: If it's similar to chrome and safari even with different
logic it should be fine
smfr: Was this bugs on webpages or just seen in testing?
oriol: Me implementing ::marker. Currently Chromium sets it in style
adjuster. For outside it sets white-space to pre and for
inside it's the list item. When I tried to impl the previous
resolution some internal tests failed and I noticed this. I
don't know any webpages in wild
fantasai: Space between li and content is not uncommon. I do imagine
there's a number of web pages effected.
florian: But list inside is not common
fantasai: Yes, but it is used. Unlikely to break badly but won't
look as intended
astearns: Not hearing consensus except no not 2. Split between 1 and
3. Is that the case or can resolve on 3?
oriol: Fine with 3
astearns: Objections to resolve on option 3
heycam: Are those internal pseudo classes?
florian: Start there and bikeshed later
TabAtkins: Until a use case I don't think need to expose. But safe
to do so if someone is motivated to champion that
florian: Wondering if folks like glazou will be unhappy about things
happening that can't be replicated in an editor
astearns: We're out of time for the day.
astearns: I suggest we resolve on 3 so oriol can try and perhaps
come back with results. People can raise new objections if
they like
astearns: objections to option 3?
fantasai: I'm happy to put in spec there's a magic difference but
not sure we want to spec it's with pseudo classes. If we
want to say some kind of magic and UA can figure it out we
can. If we're doing a pseudo class we should draw that up
<dbaron> +1 to fantasai, no need to add pseudo-classes right now.
(Also, we'd had a totally different ::inside and ::outside
proposal!)
astearns: Not resolving on option 3 today but that's the direction
we want to head in.
florian: Is difference observable fantasai?
fantasai: I don't know. But don't want more detail in spec then
needed in case UA wants to think of a way to do it
TabAtkins: Agree. Should say it happens and have a note
astearns: Thanks everyone
astearns: We'll go back to the issue and add spec text there
[after meeting discussion]
fantasai: There was a proposal that eats whitespace. We could use
that.
astearns: whitespace-trim or something like that?
fantasai: Yeah. That's another option. We can re-use that and set it
on the marker and it's pretty normal.
<fantasai> https://www.w3.org/TR/css-text-4/#white-space-trim
astearns: Interesting
florian: Magic is bad but a generic system is fine
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/4891
fantasai: That's my recommendation. Use that property to do magic.
oriol: Is it implemented?
fantasai: No
TabAtkins: Not certain it works. We want to preserve whitespace but
we don't want whitespace from marker and content start to
both preserve.
dbaron: Don't think that's the case. Shouldn't have different mark
up depending on spaces after li. Not collapsing 2 things,
get rid of one
TabAtkins: How with trim?
fantasai: Set it on after ::marker
<fantasai> ::marker { text-space-trim: discard-after }
Scribe: fantasai
<florian> https://drafts.csswg.org/css-text-4/#white-space-trim
florian: Interesting approach to solving it, would also be useful
for other things
florian: My concern with option 2 was I didn't want a special
magical kind of white space, avoids having to define all
the weird cases like does it hang at the end of a line etc.
florian: Probably need to define how the discarding interacts with
bidi, but needs to be defined either way for the feature ...
<TabAtkins> florian: I believe that text-space-trim would collapse
away the space after re-ordering; I don't see how
anything else would make sense, right?
<TabAtkins> Its point is "if I end up with collapsible space before/
after me, kill it", and that decision can only be made
after bidi.
<aja> Unicode Character 'NO-BREAK SPACE' (U+00A0) isn't considered
collapsible, is it?
<TabAtkins> correct, it's non-collapsible (and has some complicated
rules for infecting surrounding spaces with
non-collapse-ness)
Received on Thursday, 2 April 2020 10:37:43 UTC