[CSSWG] Virtual F2F 2021-04-08 Part I: CSS Pseudo, Color Adjust, Capitalization: "User Agent" or "user agent" [css-pseudo] [css-color-adjust]

  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 Pseudo

  - RESOLVED: Text decorations of highlight pseudos sort *outermost*
              by decoration category (per CSS2) then by highlight
              type. ::selection has an out to allow it to paint on top
              of everything else (Issue #6022: Questions about text
              decorations on highlight pseudos)
  - RESOLVED: Switch Highlights back to a maplike of (name)=>
              Highlight, add a Note about what happens if you register
              the same highlight with multiple names (Issue #5910:
              Highlight API collection, maplike vs setlike)
  - There is interest in having a requirement in the spec for browsers
      to provide sufficient contrast between background and foreground
      colors, even when the author has specified them as the same
      value (Issue #6150: Ensuring selection foreground/background
      - Spec text will have to be thought through carefully to ensure
          that all cases are appropriately handled.
      - It's currently unclear how much the group will be able to
          provide a specific algorithm vs a set of minimum
          requirements. Having an 'auto' value with required contrast
          would allow OSs to still have some custom behavior.

Color Adjust

  - RESOLVED: Normal and light are not synonymous, they will stay
              (Issue #5898: Are normal and light synonymous for
  - RESOLVED: No change, keep both forced-color-adjust and
              color-adjust (Issue #3880: Combine forced-color-adjust
              and color-adjust properties somehow?)

Capitalization: "User Agent" or "user agent"

  - RESOLVED: Match the style guide of lowercase for "user agent"
              (Issue #5200)


Agenda: https://github.com/w3c/csswg-drafts/projects/17

  Rossen Atanassov
  Tab Atkins-Bittner
  L. David Baron
  Christian Biesinger
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Daniel Holbert
  Sanket Joshi
  Brian Kardell
  Daniel Libby
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Myles Maxfield
  Cameron McCormick
  Tess O'Connor
  François Remy
  Morgan Reschenberg
  Melanie Richards
  Florian Rivoal
  Cassonda Roberts
  Alan Stearns
  Miriam Suzanne
  Lea Verou
  Greg Whitworth

Scribe: TabAtkins

CSS Pseudo

Questions about text decorations on highlight pseudos
  github: https://github.com/w3c/csswg-drafts/issues/6022

  fantasai: This is about painting order of text decorations on
            ::highlight pseudos
  fantasai: There is a stacking order of the highlights
  fantasai: Original text is bottom layer, and things stacked above
            that: spellcheck, grammar check, target text, selection,
            something like that
  fantasai: defined in spec
  fantasai: When you draw text, text and decorations are also layered
            separately: overline, underline, text, strikethru. So over/
            under are below text and strikethru is above
  fantasai: So what's the interaction between these two stacking
  fantasai: The proposal is that you maintain the same order between
            over/under, text, and strikethrus
  fantasai: highlight pseudos are defined by only the topmost pseudo
            painting the text, so it's not painted multiple times; in
            that topmost layer's color
  fantasai: but line decorations stack
  fantasai: If you have spelling, grammar error and are highlighting,
            you'll see all the different underlines
  fantasai: Suggestion is that we do all the underlines in z-index
            order, then overlines, then the topmost text, then all the
  fantasai: So CSS2 ordering is the "outer" ordering
  fantasai: This makes strikethru always on top, regardless of where
            it's from.
  fantasai: Thoughts?

  TabAtkins: Sounds reasonable to me, ignoring implementation
  dholbert: Do you know how browsers currently do?
  fantasai: I haven't tested who supports the various new highlight
            pseudos yet.
  fantasai: I know there is some weird behavior with regards to text

  smfr: Can you give the ordering again?
  fantasai: Custom highlights are between text and built-in
            highlights, with selection on top
  fantasai: under/overlines defined by non-selection highlights will
  fantasai: So proposal is all the overlines, then all underlines,
            then the text (only once), then all the strikethrus on top.
  fantasai: I think this generally makes sense; but selection has some
            trickiness on some platforms that I'm not sure about
  TabAtkins: I know iOS has a special ordering for ::selection, but
             not sure if they do text decorations there
  smfr: No, ::selection is drawn on top of the text, and doesn't allow
        text decoration
  fantasai: [gives example]
  smfr: So is it true that custom highlights can contribute text
        decorations? And they're sorted in that order with the
  fantasai: Yes
  smfr: Okay, now I understand
  fantasai: So we could draw the text decors for the lower layers
            below the text, and draw the text decorations for higher
            layers above the text
  fantasai: Problem is that strikethru on lower layers would be below
            the text
  fantasai: Maybe that's what we want, I dunno
  TabAtkins: I think the fact that any arbitrary layer can co-opt the
             text painting role means that having the underlayers draw
             their strikethrus under the text when necessary is a bad
             thing; it's not easy to predict what layer will actually
             draw the text. So we should do the full grouping instead
  smfr: Okay, as long as ::selection is on top, it's fine for us - the
        rest can sort their decorations together

  chrishtr: Before we resolve, I'd like to have the proposed
            resolution be written down and tested on impls, so I can
            double check that there aren't issues
  chrishtr: no interop or complexity issues
  fantasai: The person who raised the issue is implementing in Chrome

  fantasai: I wanna be clear, smfr, that the strikethrus of a custom
            highlight can paint atop a selection
  fantasai: What we could do is special-case ::selection and say that,
            *aside* from that, everything sorts as described, but
            ::selection text/etc can paint in a single layer on top of
            everything else
  fantasai: The point that Tab brought up - that the existence of
            another custom highlight shouldn't cause a previous custom
            highlight to have its strikethru go below - is correct,
            but due to the nature of ::selection, it's probably fine
            to treat it specially.
  fantasai: So like if spelling error used a strikethru, that should
            paint over the text
  fantasai: If you have ::text-target as well, we don't want this to
            cause the spellcheck strikethru to go under the text
  fantasai: But if you select the text, and we can say that it causes
            the text to come to the forefront and paint over the
            decorations, I think that's reasonable behavior and would
            solve your concerns on iOS.
  smfr: We don't paint the text itself on that top layer, but just the
        'blue wash' the highlights it. I'm fine with reordering the
        decorations, as long as the user selection is atop everything

  fantasai: So if you specify ::selection { color: yellow; background:
            blue; }, what happens?
  smfr: Text will be yellow, don't know if we support the background
  GameMaker: Let me check...
  florian: So you're proposing we *allow* ::selection to be on top, or
           *require* it?
  fantasai: I can go either way. I think ::selection overpainting all
            lower-level text decorations isn't unreasonable.
  florian: The iOS thing doesn't seem to be *only* on top, it just
           works differently than the other highlight pseudos.
           Background isn't 'background', it's a magic translucent
           thing, etc.
  smfr: Yes, it's special
  GameMaker: We already do something special with making even user
             colors slightly translucent
  GameMaker: It doesn't affect text, but if you have a red background
             and yellow selection, it'll be a little translucent [and
             look a little orange] - it's not solid color
  fantasai: Cool, we have another issue on that. So do you paint that
            translucent background over the text?
  GameMaker: Yes.
  fantasai: So you can't have yellow text if you have a blue
            background, it'll always be a little green?
  GameMaker: Yes, but it's a subtle effect, not as green an effect as
             you think.
  florian: So based on this I suggest we *allow* ::selection to be
           painted atop - don't need to clone iOS.
  fantasai: I'm fine with that.

  fantasai: Proposal is that the "outer" ordering is CSS2 ordering -
            what type of decoration it is.
  fantasai: "Inner" sort is what type of highlight you have.
  fantasai: And as an option, the impl *may* paint all the aspects of
            the ::selection as a topmost layer above the rest.
  Rossen: Objections?
  fantasai: Let's handle background in a separate issue though
  chrishtr: I'd just like to have some time to review
  [chatter about this being provisional for review or what]

  RESOLVED: Text decorations of highlight pseudos sort *outermost* by
            deco category (per CSS2) then by highlight type.
            ::selection has an out to allow it to paint on top of
            everything else

Highlight API collection, maplike vs setlike
  github: https://github.com/w3c/csswg-drafts/issues/5910

  florian: A custom highlight is made of three things: the Highlight
           object (a bunch of ranges), then a priority to know where
           it stacks, then a name so it's addressable from the
  florian: Question is how to group these
  florian: Could say priority is an attribute of the highlight object
  florian: But what about the name?
  florian: One option is a Map where key is name and value is Highlight
  florian: Another is a Set where name is a property of Highlight.
  florian: If you use a Map, you could potentially register the same
           highlight multiple times under multiple names.
  florian: Has some odd ergonomics for user.
  florian: You style ::custom-spelling and ::custom-grammar, but they
           have the same priority, it's got some odd stacking.
  florian: Not *hard* to explain or implement, just unintuitive. We
           consider it a footgun.
  florian: So we decided to make it impossible to set up the same
           highlight multiple times.
  florian: So we switched to a Set that throws if you register
           multiple times. We could also have a Set that just ignores
           if you set multiple.
  florian: Or a Map that throws if you register multiple.
  florian: Or we could just ignore it all and let it happen.
  florian: Currently the spec has it as a Set where name is an
           attribute, and it throws if you register the same thing
  florian: But that's unusual.
  florian: Simplest is a Map that doesn't throw, but that might not
           make sense. But maybe that's fine.

  hober: This came up in a TAG review
  hober: been several months so conversation is swapped out by now...
  hober: But I remember being surprised about, it would be common to
         write code that says "have I registered this yet? No? then
         add it"
  hober: Might have a few libraries that use highlights for various
         purposes, and they don't want to clobber themselves
  hober: With a Map that's super easy
  hober: just check the key
  hober: With a set you have to iterate
  hober: We thought that's weird, we expected checking to see if it's
         registered to be a common op
  hober: I think we saw the ergonomic downside as more of dev
         inconvenience than the dev registering the same thing
         multiple times
  hober: So I think we're inclined to just let the dev hurt themselves
         if they want to register things twice
  hober: Not a hill we want to die on, just want common operations to
         be easy.
  florian: With time that has passed since original decision, sounds
           good to me

  leaverou: Agree with hober, she said most of what I wanted to
  leaverou: I think using try/catch every time you register a
            highlight isn't ideal
  leaverou: I think there might even be use-cases for doing this -
            providing aliases for the same highlight
  leaverou: Sanket pointed out the problem is the priority (can't set
            it in that case), but that sounds like priority is
            associated with the name rather than the Highlight...
            maybe it's misplaced?
  florian: I thought about that, but then how would you set it?

  sanketj: Design I had in mind originally was every Highlight has one
           name and one priority, and that's reflected in the spec we
           have today.
  sanketj: You could say the priority is associated with the name
           rather than the highlight, but you'd need a different data
  <iank> sanketj: likely want an options arg for the ctor, e.g. "new
         Highlight({name: 'hi', priority: 2})"
  <iank> can't it be a maplike with an additional convenience function?
  <TabAtkins> Yeah, it'd take a sequence or options object instead, I
  <iank> e.g. ```interface Highlights { readonly maplike<string,
         Highlight>; addHighlight(Highlight or HightlightDictionary);

  Rossen: What's your position on the change to use Map?
  sanketj: hober and leaverou's arguments make sense. And I think
           associating priority with highlight is convenient; I'd
           prefer not to change that if there's not a big reason to
  sanketj: If we do allow a highlight to have multiple names, what's
           the messaging around it?
  sanketj: Lea mentioned a use-case; I always thought about this as
           making a separate Highlight object, then they can
           prioritize against each other properly
  sanketj: Sounds like you were suggesting having the same highlight
           be prioritized two different ways, which might be more
  florian: I think the proposal is to just do it the naive way - same
           highlight under two names would share priority
  florian: So painting order would use the fallback of registration
  florian: A bit limiting, but it's not there *because* of the
           use-case, it's just the natural fallout.
  florian: And if people find ways to make it nice for them, sure.
  <leaverou> +1 to florian
  florian: Probably it's a footgun, but possibly there's good things
           to come out of it

  sanketj: Do we want something in the spec warning against it?
  <leaverou> Yes, this would need to be a note in the spec
  sanketj: Seems could be unexpected results
  florian: Don't think we should have a normative thing, but a Note
           saying this would be odd if you did it would be appropriate
  leaverou: Agreed
  sanketj: We could just document the case from the issue
  sanketj: Seems fine
  Rossen: Sounds like we're approaching a resolution?

  iank: I left some IRC comments
  iank: You don't need to strictly make it a setlike - could add
        convenience functions
  iank: Dunno if this changes the discussion particularly
  florian: Not sure what's being proposed to help here
  iank: Could make it a readonly maplike, then provide an add() that
        takes a Highlight, plus a remove()
  florian: Does that bring us back to what we have today?
  sanketj: I think the impl is that the name would not live on the
           highlight, but be the key to the maplike
  TabAtkins: I don't think there's enough worth innovating in data
              structures, versus just letting authors do this

  Proposed resolution: Switch Highlights back to a maplike of (name)=>
      Highlight, add a Note about what happens if you register the
      same highlight with multiple names
  leaverou: Just want to make sure that if you register to an existing
            key, it doesn't throw - that was mentioned in the early
  florian: Right, normal Map behavior

  RESOLVED: Switch Highlights back to a maplike of (name)=> Highlight,
            add a Note about what happens if you register the same
            highlight with multiple names

Ensuring selection foreground/background contrast
  github: https://github.com/w3c/csswg-drafts/issues/6150

  chrishtr: ::selection can set foreground and background color. What
            happens if they're not contrasty enough?
  chrishtr: If they're the same, you can't read the text
  chrishtr: For that reason, wk/chrome has special code to invert one
            of them in that case
  chrishtr: There's at least one site reported as "can't see
            selections" in Gecko, because foreground and background
            were both white, and dev might not have noticed it in
            testing because wk/chrome intervene and fix it
  chrishtr: So should we remove the intervention, or require it?

  fantasai: So someone was using white ::selection 'background' and
            'color'. This works in wk/chrome because neither uses an
            opaque background
  fantasai: Gecko, following the spec, paints the color as specified
  fantasai: So that brings up an interesting question of - we need to
            decide whether the specified background is what's used, or
            the specified background is modified in some way
  fantasai: If UA's differ, you'll get these interop issues
  fantasai: They're either assuming the transparency is there, or
            assuming it's not, and it might not work in the other cases
  fantasai: So we need to have interop on the alpha of the background
            color in ::selection
  chrishtr: Our code is flipping the color, definitely - I checked
  <fantasai> WebKit is using semi-transparent white, though, and
             that's probably what the author was expecting

  <chris> CSS Color 4 "The following system color pairings are
          expected to form legible background-foreground colors ...
          Highlight background with HighlightText foreground. "
  chris: In Color 4, certain combos of system colors are required to
         be legible
  chris: One of those pairings is HighlightColor and
  TabAtkins: This is about author-chosen colors tho
  chris: Ah, sorry

  leaverou: I'm skeptical about UA intervening in author choices
  leaverou: Sounds like this issue happened because author was setting
            background and not text?
  fantasai: They were setting both
  <fantasai> This is a case where the author explicitly asked for
             white text and white background
  <fantasai> https://bugzilla.mozilla.org/show_bug.cgi?id=1589539#c5
  leaverou: Wonder if we could set better defaults? Set default
            background to always contrast with text color using Color
            5 colors
  myles: We think the spec should say *at least* that UAs should do
         something to make sure text is legible when highlighted
  myles: No opinion on how far the spec should go
  myles: If the spec had an algorithm, that's fine
  myles: If the spec just says "UA must do something", that's fine
         with us too

  florian: Gets interesting when foreground and background are coming
           from different pseudos
  florian: As an author you ought to set foreground and background
           together, but you can make this mistake
  florian: So having a requirement that the UA must ensure the topmost
           foreground and background colors must contrast...
  florian: Just making sure it's clear this can happen accidentally
           from different pseudos interacting, and that should be
  <leaverou> maybe we should adopt the previously proposed
             currentBackground keyword? Then UA default could be
             color: color-contrast(to 4.5 currentBackground vs white,
             black); (or appropriate system colors)

  fantasai: Cause of the bug:
  fantasai: Person filing was assuming a semi-transparent whitewash
            with white text
  fantasai: Chrome used to do that
  fantasai: In Mozilla, it was rendering as solid white on white
  <fantasai> https://bugzilla.mozilla.org/show_bug.cgi?id=1589539#c5
  fantasai: Author literally wrote ::selection { color: white;
            background: white; }
  fantasai: They were expecting a particular rendering, which they
            were getting in Chrome and WebKit, but not Gecko, because
            both were applying magic opacity
  fantasai: So I think it's harmful for some browsers to have magic
            opacity and some not
  <leaverou> agreed with fantasai that if author specifies both, they
             should be respected
  fantasai: So we need to align on some behavior here.
  florian: I agree the state we're in is bad. Your proposal is one
           possibility. Myles's too - require all browsers to require
           legibility, but not specify how
  florian: So if you're in a non-legible combo (for any reason,
           including the browser applying magic opacity or whatever),
           the UA must change something to make it legible.
  florian: Mandating one algorithm would be great, but not sure we can
           do that.

  fantasai: So example: authors chooses a semi-transparent color for
            the background. It's just enough to show a selection, but
            not enough to be problematic against the background
  fantasai: In WK browsers, they'll compound the opacity, so it's even
            more faint of a background. No legibility problem, but
            there's no longer a visible highlight, which is another
  fantasai: Now author has a problem despite making good choices
  fantasai: Whether we adjust or not is fine, but having it work
            differently across browsers is problem.

  florian: So from Apple pov, if we specify a particular transparency,
           is that a problem for y'all?
  smfr: Unsure if we have an answer to that. We want our selection to
        match the OS convention, so there's magical opacity
  smfr: Don't know if we'd be willing to turn off magic opacity in
        some cases, seems hard...
  florian: If we specify exactly *your* opacity, would that work? Or
           do you reserve the right to change the exact method?
  smfr: I don't think it's just opacity, there's a blend mode involved
  florian: So your behavior is too magic to spec?
  smfr: Could probably spec it, but not all platforms might want to
        match the Mac OS conventions
  fantasai: Don't think people have problems with matching OS
            conventions by default, just when the author says
            something specific, it should be predictable across
  <gregwhitworth> I agree with fantasai there
  smfr: Generally we solve this by adding a CSS property that lets
        authors opt out of the correction
  fantasai: We do have a long-standing request for a
            background-opacity property
  florian: So a default value of "auto" that can do magic things in
           some OSes?
  fantasai: Maybe.
  florian: I think we should explore more in this area.
  florian: We *will* get interop problems if we don't have something
           like this.

  Rossen: So should we take this back to the issue?
  hober: I think this action sounds reasonable.
  hober: Could we resolve on the direction to go in - to require UAs
         to ensure there be sufficient contrast, exact details TBD?
  hober: UAs do need to do something, right?
  florian: I think fantasai pointed out that if you do that, you can
           hit the opposite situation, where a good foreground/
           background contrast gets magicked into a lack of contrast
           between selection and page background?
  hober: I think we can word the resolution to avoid that
  hober: I hope we can end up with simple details

  hober: We just shouldn't punt on this, right?
  fantasai: Yes, shouldn't punt. I just think I can throw a lot of
            wrenches into this. ^_^
  fantasai: Example: author intended transparent selection background
            (so UA detection of no contrast between selection
            background and page would be a problem) and is using color
            change on the text to indicate the selection
  fantasai: So there will be a lot of thought needed for the details
  fantasai: And I think we should start be having an ability for
            authors to specify a more exact interop
  <gregwhitworth> if you do it post composite you could but it would
                  be a bad performance path but would ensure contrast
                  so the text scenario would result in no adjustment
                  by the UA
  florian: I think we overall agree, just resolving to "browsers must
           do X" is a little premature at the moment

  <br duration="15min">

  <gregwhitworth> we discussed having a smart focus rect to ensure
                  contrast and decided to not do it since to truly
                  ensure contrast you'd need to do it post composite

Color Adjust
  scribe: dlibby

Are normal and light synonymous for color-schemes?
  github: https://github.com/w3c/csswg-drafts/issues/5898

  TabAtkins: Answer is no, not the same, not all UAs display on a
             light background by default
  TabAtkins: Despite current browser that ship do this, this is not a
  emilio: Tons of things break if you use dark background by default
  TabAtkins: Indeed, but works reasonably
  florian: Users of console-based UAs tend to expect oddness, VR
           browsers might not assume this as well
  emilio: How many of these will implement color scheme, and
          prefers-color-scheme media feature?
  TabAtkins: More VR UAs will show up and assumptions they make are
             still valid to consider
  fantasai: Some UAs are not browsing the web, might be browsing
            books, requirements different from browsing the web in
  Rossen: Back to TabAtkins' short original answer: "no"
  Rossen: Perhaps a bit more is needed, proposed resolution is no, due
          to various requirements across UAs and devices
  Rossen: Other comments, objections?

  RESOLVED: Normal and light are not synonymous, they will stay

Combine forced-color-adjust and color-adjust properties somehow?
  github: https://github.com/w3c/csswg-drafts/issues/3880

  leaverou: I was in the breakout, there are many use cases where you
            want both. should be an easy way to enable both
  leaverou: Perhaps a shorthand would provide flexibility
  TabAtkins: I think these are sufficiently different that we
             shouldn't turn them off at once. Printing well is
             conceptually similar but different that color adjustment
             for forced colors
  TabAtkins: Wouldn't want to trigger one, but accidentally the other
             (i.e. if authors optimize for screen media, not print)
  TabAtkins: Suspect they shouldn't be done at the same time
  Rossen: In two environments, the properties have almost opposite
          effect (on-by-default vs. off-by-default)
  Rossen: Historically they have different usage as well, increasing
          adoption, I'm on the side of keeping these separate for the
          same reasons
  fantasai: Agree with reasons to keep them separate. Color swatches
            is the one use case I can think of for using them in both
  fantasai: Would be nice for authors be able to have something that
            works for future color adjustments, but currently
            color-adjust is specific to print

  Rossen: Proposed resolution no change - any objections?

  RESOLVED: No change, keep both forced-color-adjust and color-adjust

Capitalization: "User Agent" or "user agent"
  github: https://github.com/w3c/csswg-drafts/issues/5200

  florian: Writing some spec text and wanted consistency, but we're
           completely inconsistent everywhere. Using fully lowercase a
           bit more often
  florian: Hard to do this in an automated fashion. Uppercase can be
           done unconditionally. Maybe we don't care
  hober: I don't actually care, can't pretend. w3c style guide says
         lowercase so lets follow that
  hober: Should update the guide or follow
  florian: Hard to do in practice and hard to enforce. You might
           automate replacement by being sentence aware
  fremy: user agent at the start of a sentence would be User agent not
         User Agent, so User Agent is detectably wrong. Maybe we can
         put up a warning, think its doable
  florian: Yes sounds doable

  Rossen: Do we care enough to resolve one way or another?
  TabAtkins: I volunteer florian to implement the lowercasing

  RESOLVED: Match the style guide of lowercase for "user agent"

Received on Monday, 24 May 2021 22:52:25 UTC