W3C home > Mailing lists > Public > www-style@w3.org > November 2020

[CSSWG] Minutes TPAC F2F 2020-10-22 Part II: CSS Text, CSS Fonts, & CSS Text Decor, CSS Fonts, CSS Lists, CSS Color, CSS Color Adjust [css-text] [css-fonts] [css-text-decor] [css-lists] [css-color] [css-color-adjust]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 4 Nov 2020 09:17:18 -0500
Message-ID: <CADhPm3s-zYm5CWS3602DaHDQTUhjv-YF=988d97Tr+D6QnJhLw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 4 November 2020 14:18:24 UTC