Minutes Telecon 2020-04-01
- 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:
- color: blue ! override always beats color: red, even if red would normally win the cascade.
- 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
- There were three potential solutions for issue #4891 (Should collapsible space after inside ::marker be preserved?):
- Keep white-space: pre. Firefox is correct, changing Chromium will be trivial.
- 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.
- 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 Meeting Minutes
« Previous article
Next article »