- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Nov 2020 09:17:18 -0500
- 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 Text, CSS Fonts, & CSS Text Decor
-------------------------------------
- RESOLVED: Inheritable properties that apply to inlines also apply
to text (Issue #5303: Distinguish applying to text vs
applying to boxes)
CSS Fonts
---------
- The proposed solution for issue #5533 (Reduce layout shift via
@font-face descriptor(s) overriding inline) is going in the
right direction but there is a need to reconsider it in light of
some of the comments in issue #450 (
https://github.com/w3c/csswg-drafts/issues/450#issuecomment-245485065
)
around using properties instead of descriptions.
CSS Lists
---------
- RESOLVED: Change CSS Lists to make all CSS counters behave
as needed to support HTML (Issue #5477: CSS counter
scope/inheritance is incompatible with HTML ordinals)
CSS Color
---------
- RESOLVED: Accept the mappings in
https://github.com/w3c/csswg-drafts/issues/3873#issuecomment-713658800
(Issue #3873: Prevent fingerprinting with deprecated
system colors)
- RESOLVED: Add note to the spec [regarding history of the color
names and discouraging their use], close issue (Issue
#5284: Change three color names)
CSS Color Adjust
----------------
- RESOLVED: Auto-adjustment of colors for non-forced colors may
happen, exact syntax to avoid it tbd (Issue #5089:
Re-add `only` to mean “don't auto-adjust me”, per
WebKit's behavior)
- RESOLVED: Forced colors happens at used value time. Add a note to
the spec about implementation (Issue #4915: Is forced
color computed or used value?)
- RESOLVED: Republish WD with the edits
- This includes the edits for issue #4178: More granular
overriding of forced colors mode than per-element
( https://github.com/w3c/csswg-drafts/commit/588ce6183bc25e62b61ec723f700b2c356d8a89a#diff-8974d243f99b24bfbefbf89dee6dc5d4a06890610cb205535e0d8d279db1d587
)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule
Scribe: fremy
CSS Text, CSS Fonts, & CSS Text Decor
=====================================
Distinguish applying to text vs applying to boxes
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5303
fantasai: It's not super clear which properties apply to text, and
which apply only to inline boxes
fantasai: the specs say 'inline boxes' when they mean text
fantasai: but for some effects we need a clearer distinction
<TabAtkins> testcase from oriol showing off the distinction:
<TabAtkins> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Asection%20%7B%20border%3A%201px%20solid%20%7D%0Adiv%20%7B%20line-height%3A%204%3B%20display%3A%20contents%20%7D%0A%3C%2Fstyle%3E%0A%3Csection%3E%3Cdiv%3Eline-height%20inherited%20by%20text%3C%2Fdiv%3E%3C%2Fsection%3E%0A%3Csection%3E%3Cdiv%3E%3Cspan%3Eline-height%20inherited%20by%20inline%20box%3C%2Fspan%3E%3C%2Fdiv%3E%3C%2Fsection%3E
<TabAtkins> chrome renders the two boxes the same, firefox doesn't
apply line-height to the first (where there is no box to
apply to, only text)
fantasai: I propose to make a mass update to clarify "text" vs
"inline boxes" vs "inline boxes and text"
fantasai: for the most part, inheritable properties that apply
to inline boxes apply to text
fantasai: e.g. text decoration, color, etc...
fantasai: This will require some auditing of the existing propdef
tables
<chris> seems good to me, I think it is clearer
florian: I initially agreed
florian: but oriol made a test case and it confused me
florian: because content makes an anonymous inline
florian: So what's the difference between the two concepts, I am not
sure
fantasai: Is there an anonymous inline? really?
TabAtkins: As far as I know, there is not
florian: ah ok, then we need to specify
emilio: webkit allows display:contents on text, but we don't in gecko
TabAtkins: Do you think this makes a different except line-height?
emilio: No, apart from that, I don't think there is a difference
florian: And the whitespace property?
florian: If there is no inline box? how would that work?
emilio: I would have to test
emilio: I remember we used to apply only the closest inline container
emilio: and we changed this, but I don't recall the specifics
oriol: One of the principles we should try to follow is to use
inheritance as a rule
oriol: Otherwise there could be differences if you have or not the
inline
TabAtkins: That sounds like a reasonable rule to me
TabAtkins: and whitespace works in firefox
Rossen: So could line-height be a bug in gecko?
florian: Did the list you made match oriol rule?
fantasai: I think so, but the list was very rough I didn't take a
detailed look
fantasai: There might be issues with alignment
fantasai: but we can take a look later
florian: I support resolving oriol rule then
florian: and we can revisit if needed later
Rossen: And we need to add this rule?
florian: Yes, we should indeed do that, there is no text now
Rossen: ok, sounds go
Rossen: Who will do that?
florian: It could be me, but it doesn't have to
fantasai: ok I will take this
Rossen: ok, thanks
Rossen: Do we need a resolution for oriol's rule?
fantasai: Yes, if we need exceptions we will revisit?
Rossen: ok, any objections to add this rule?
fantasai: And update the propdef tables
RESOLVED: Inheritable properties that apply to inlines also apply to
text, audit and update all propdef tables
@font-face descriptor(s) overriding inline spacing
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5533
TabAtkins: We talked about this in the past, we have some updates
chris: The idea was that to avoid layout shift, you would put values
that would update the advance value of the font
chris: that shift however only works if you have a monospace font
chris: A multiplier could work for proportional
chris: but that would not work visually
chris: because the glyphs will overlap each other
chris: So my thought is that we should instead scale the glyphs
xiaochengh: There are 3 proposals in the issue
xiaochengh: 1 add fixed value to the advance
xiaochengh: 2 scale the advances
xiaochengh: 3 scale the font-size by some percentage
xiaochengh: I tested all the 3
xiaochengh: and I don't have a strong opinion
xiaochengh: I think 3 > 2 >> 1
<fantasai> +1 to everything jfkthame said in the thread
florian: Is this meant to be tied to font-display?
florian: So this only applies after the fallback resolves?
xiaochengh: We put that in the font descriptor
xiaochengh: so if we fail to load the web font, we use the distorted
version of the fallback font
TabAtkins: Based on jfkthame comments
TabAtkins: Based on the comment scaling the whole thing is similar
to the font-size change
TabAtkins: What was comment?
florian: I think that was his preferred option
TabAtkins: yeah, then let's agree with his preferred outcome
TabAtkins: especially since we have similar things already
xiaochengh: I agree with that
<fantasai> Clearly nobody tried this with Arabic. Doing anything
other than scaling that would be seriously broken
<florian> xiaocheng did try arabic
<myles> See also: https://github.com/w3c/csswg-drafts/issues/450
<myles> specifically:
https://github.com/w3c/csswg-drafts/issues/450#issuecomment-245485065
myles: There is an issue I linked to
myles: and there is one comment in it which I think is useful
myles: Jason listed 5 adjustments he would be interested in making
myles: Most of properties not descriptors
myles: so I think the correct solution would not include a descriptor
myles: so this is one quick fix, but a proper solution would be
different I think
myles: and interact with the 5 properties he mentioned
myles: And since we probably don't want 2 ways of fixing this
myles: I would rather not add this as a stop-gap switch
fantasai: There are other use cases for this descriptor though:
because glyphs are often drawn at different actual sizes
for the same nominal size, a scale factor could be useful
in other cases
fantasai: so we could look into this use case as well
Rossen: Do you think adding this fix is a step in the wrong
direction?
myles: I think the answer is yes
myles: because this problem is not urgent
myles: So given that, the value of solving one little part is less
than the cost of having two competing solutions in the long
term
Rossen: So, back to the folks who opened this
Rossen: Any comment?
chris: I agree with myles I think
<chris> btw we have been trying to solve this since 1997
<chris> https://www.w3.org/TR/WD-font-970721#widths
myles: but I want to encourage xiaochengh to look into this more
myles: There is a solution here, but it's not yet there
xiaochengh: ok, I think I agree with myles
chris: We had stuff in 1997 about this
chris: I pasted the link in the chat
jfkthame: We could use the font data and use a data url as the
source ^_^
<Break>
CSS Lists
=========
scribe: emilio
scribe's scribe: fantasai
CSS counter scope/inheritance is incompatible with HTML ordinals
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5477
TabAtkins: When I was writing the counter rules I was working from
css 2.1 and my testing
TabAtkins: I knew HTML <ol> didn't match CSS counters in invalid
markup
TabAtkins: Gecko tried to switch to counters for CSS lists
TabAtkins: and found out that they were not web compatible
TabAtkins: See the example in the issue with a nested <ol> directly
under another
TabAtkins: html renders that as you'd probably expect
TabAtkins: that's also what editors generate for some reason
TabAtkins: In order to fix it we can specify that either html is
magic
TabAtkins: that the list-item counter is magic
TabAtkins: or switch counter behavior
TabAtkins: mats is going for the latter
TabAtkins: and is proposing to do an ancestor-only check and only if
that fails we look for a previous sibling counter
TabAtkins: That's probably fine and would still work with the main
sibling use case which is numbering headers
TabAtkins: so I'm ok with making that change
Rossen: You're referring to the third approach in the comment?
TabAtkins: no, number 1
<dbaron> seems like a reasonable way to fix this without breaking
use of counter numbering for headers
fantasai: If you look at the example and replace <list> with
<section> and <item> with <h1>, it will end up giving a
better result
fantasai: So I'm in favor of this change as being better overall
fantasai: if we can pull it off
<astearns> and you’re OK with this, faceless2?
<faceless2> yes. everything I had to say on the topic before was
wrong :-)
emilio: We actually have made this change, unsure if released yet
emilio: but haven't heard of any breakage
Rossen: cool
Rossen: Objections?
<fantasai> strong +1 given emilio's report :)
<oriol> The change is in Firefox 82, which seems it was released on
2020-10-20 (but I still don't have it)
RESOLVED: change CSS Lists to make all CSS counters behave
differently for this case
[... discussion about republishing CSS2 ...]
CSS Color
=========
Prevent fingerprinting with deprecated system colors
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3873
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/3873#issuecomment-713658800
<TabAtkins> ^^^ his mapping
<astearns> need a resolution on all of
https://github.com/w3c/csswg-drafts/issues/3873#issuecomment-713658800
chris: I made specific mappings from deprecated to non-deprecated
system colors
chris: so I think that's enough to close the issue
Rossen: Do we need resolution?
<chris> These mappings
https://drafts.csswg.org/css-color/#deprecated-system-colors
RESOLVED: Accept the mappings in
https://github.com/w3c/csswg-drafts/issues/3873#issuecomment-713658800
CSS Color Adjust
================
Re-add `only` to mean “don't auto-adjust me”, per WebKit's behavior
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5089
TabAtkins: Safari implemented color-adjust, but did a lot of weird
things that it didn't document
TabAtkins: and our reverse-engineered spec doesn't match it
TabAtkins: so we need to decide whether we need to match
TabAtkins: So if you specify `only` it won't auto-adjust colors
TabAtkins: Let me step back
TabAtkins: Safari in the mail app, if you didn't declare
color-adjust, it'd do auto-adjustments, similar to forced
colors
TabAtkins: If you set `only light` it'll leave your colors as they
were
TabAtkins: Do we want to do this? We removed 'only' because it didn't
do anything
TabAtkins: and if we want this, we need to clarify it is different
from forced-colors
TabAtkins: Is there any clarification from Safari?
smfr: I think your description is accurate
smfr: I think no browser has shipped auto-darkening
smfr: but if somebody does it then we may want to use `only` to let
authors signal this
TabAtkins: I think android webview does auto-darkening but we only
do it if the color-scheme doesn't contain dark
TabAtkins: I think I'm happy to do something with this
TabAtkins: I don't want to resolve on the syntax without Rune or
other relevant implementor here
TabAtkins: but we should resolve that auto-adjustment of colors in a
non-forced-colors mode may happen
<fremy> lgtm
RESOLVED: Auto-adjustment of colors for non-forced colors may
happen, exact syntax to avoid it tbd
Is forced color computed or used value?
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4915#issuecomment-701674628
fantasai: I reopened in light on the resolutions we took to adopt
fremy's proposal in the previous issue
fantasai: We decided that rather than a cascade-time revert to
consider non-system colors as out-of-gamut
fantasai: which is a different technique
fantasai: But out-of-gamut mapping is normally a used-time operation,
not computed-time
fantasai: Also, by doing it at computed-value time we got weird
behavior wrt inheritance
fantasai: when you do it at computed value then it'll change it to
system color and then inherit
fantasai: If you have a `forced-color-adjust: none` section down the
page
fantasai: expecting a particular inherited color
fantasai: but instead you get a random system color which might be
unreadable
fantasai: If we do this mapping at used value time
fantasai: then it inherits the color properly as specified
fantasai: but the ancestor with forced colors will get the system
color at used value time
TabAtkins: I strongly agree on this, makes much more sense
Rossen: It also avoids the dependency with color-mix()
fantasai: Yeah prevents all the interpolation / transitions issues
fremy: I think it does make a lot of sense but I want to make sure
something is recorded
fremy: If you have a disabled button, the default style will have
some color
fremy: Let's say `text` -> `disabledtext`
fremy: so it can be made at used value time
fremy: but for children you need to walk the parent chain to know
which color to reset
fremy: Basically what you map to depends on the UA stylesheets
fremy: So you kinda need to remember this in a way
florian: [restates the issue]
TabAtkins: It is indeed a separate concern
florian: If we were doing it at computed value time you wouldn't
have this issue so it's the same issue, not separate
fremy: I wanted to make sure it's mentioned because it's an
important impl detail
fantasai: Yeah we should note that in the spec
emilio: Wanted to mention related point
emilio: this is a problem, even if you don't account for children
emilio: If you specify color on the button
emilio: in order to know what to revert to, need to do the cascade
again
emilio: to find the original value to revert to
emilio: That would be my main concern
emilio: I think it could be addressed with something like an
internal CSS property
emilio: but different from what browsers currently do
fremy: Similar to :visited
emilio: Similar, but different
fremy: this is what Edge did, we tracked a separate value for
:visited
Rossen: We had a cascaded value alongside, for anything that was
overridden, so that we didn't have to go and recascade
Rossen: We would have it at hand, ready to use as needed.
Rossen: Added a little bit of memory, but relatively insignificant
Rossen: So from impl pov, this is very doable, not much additional
context needed
Rossen: but fremy's point that it's not automatic is relevant
RESOLVED: Forced colors happens at used value time. Add a note to
the spec about handling descendants correctly.
More granular overriding of forced colors mode than per-element
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4178#issuecomment-700481333
fantasai: I had a few follow-up questions, one of them we just
resolved on
fantasai: We said that reverted colors should try to match the user
stylesheet
fantasai: I added that as a SHOULD
fantasai: This would override explicit UA/User values, is that what
we want?
<fantasai> https://github.com/w3c/csswg-drafts/commit/588ce6183bc25e62b61ec723f700b2c356d8a89a#diff-8974d243f99b24bfbefbf89dee6dc5d4a06890610cb205535e0d8d279db1d587
TabAtkins: Third bullet point in ^ is the relevant one
TabAtkins: before we had no details other than it should be an
"appropriate" system color
fremy: Yeah I assume it'd be the one in the UA sheet by default
fremy: As an author you can override it using system colors
TabAtkins: Are we looking for a resolution or just review?
fantasai: Yeah I wanted to check those requirements and whether
SHOULD is appropriate
RESOLVED: Republish WD with the edits
fantasai: We don't have that many issues left in color-adjust
fantasai: I think the other major issue is `only`
CSS Color
=========
Change three color names
------------------------
github: https://github.com/w3c/csswg-drafts/issues/5284
[chris summarizes the issue]
chris: I've put a section on the spec explaining the origin of these
names
chris: I hope that'd avoid people asking to add colors
chris: I didn't go ahead with deprecating, just recommending them
not being used
chris: Do we want to do this?
chris: I'm ok-ish with that but I don't think that'd bring much
benefit
chris: There's also navajowhite, which includes `DEAD` in the hex
code
<fantasai> I'm in favor of accepting Chris's note and closing the
issue
https://github.com/w3c/csswg-drafts/issues/5284#issuecomment-713546559
chris: leaverou was concerned about us deprecating all named colors
including the popular ones
chris: but I don't think that'd happen
<leaverou> That wasn't what I said lol. I just said "as if the other
X11 colors represent what they claim to" (regarding
navajowhite not actually looking like the navajo flag)
<leaverou> but yeah, we have data that white and black are *very*
popular
<TabAtkins> lol good point lea
<TabAtkins> the fact that "orange" wasn't in the original HTML
colors is such a weird historical wrinkle
RESOLVED: Add note to the spec, close issue
Received on Wednesday, 4 November 2020 14:18:23 UTC