[CSSWG] Minutes Cupertino F2F 2023-07-19 Part I: CSS Pseudo Elements [css-pseudo]

  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: Attempt to make this work for ::marker as well as
              ::before/after, come back with a specific proposal that
              allows it while respecting platform conventions (Issue
              #8892: Allow user-select on ::marker pseudoelements)
  - Clarify spec that custom props can be set on highlight pseudos.
  - RESOLVED: Highlight pseudos inherit across the highlight tree, and
              the root highlight inherits custom props from the root
              element (Issue #6641: Custom properties on :root)
  - RESOLVED: If a unit (or similar value) relies on the value of a
              property that's not applicable to highlights to resolve
              itself, it uses the value from the originating element
              (Issue #7591: Highlight pseudos and non-applicable
  - RESOLVED: Do not support them until unprefixed (Issue #7580:
              Highlight pseudos and compat stroke/fill properties)


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

  Rachel Andrew, Google
  Tab Atkins, Google
  David Baron, Google
  Oriol Brufau, Igalia
  Federico Bucchi, Apple
  Stephen Chenney, Igalia
  Mu-An Chiou, Ministry of Digital Affairs, Taiwan
  Emilio Cobos, Mozilla
  Yehonatan Daniv, Wix
  Matthieu Dubet, Apple
  Elika Etemad, Apple
  Rob Flack, Google
  Megan Gardner, Apple
  Sammy Gill, Apple
  Daniel Holbert, Mozilla
  Brian Kardell, Igalia
  Jonathan Kew, Mozilla
  Ian Kilpatrick, Google
  Una Kravets, Google
  Vladimir Levin, Google
  Peter Linss, Invited Expert
  Theresa O'Connor, Apple
  ChangSeok Oh, ByteDance
  Fran├žois Remy, Invited Expert
  Florian Rivoal, Invited Expert
  Cassondra Roberts, Adobe
  Vitor Roriz, Apple
  Noam Rosenthal, Google
  Khushal Sagar, Google
  Jen Simmons, Apple
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Bramus Van Damme, Google
  Sebastian Zartner, Invited Expert

Scribe: TabAtkins

CSS Pseudo

Allow user-select on ::marker pseudoelements
  github: https://github.com/w3c/csswg-drafts/issues/8892

  fantasai: Someone's trying to copy out a list, and not getting the
            ::marker numbers
  fantasai: So this brings up, what do we do with ::marker when
  fantasai: There's 4 things we could do
  fantasai: 1) never output gencon
  fantasai: 2) always output gencon
  fantasai: 3) output ::marker gencon but not others
  fantasai: 4) output only html-derived content (ignore css, only
               markup-based list markers)
  fantasai: In terms of controlling whether you want to copy out
            gencon, user-select might help manage that
  fantasai: That was the commenter's original impression of how it
            should work when they filed
  fantasai: Then if we use CSS content, do we use the primary string,
            or the alt text if present?
  fantasai: So the question is, again, what part of gencon should be
            part of plaintext copying

  florian: We touched on a related topic before, it's tricky
  florian: user-select says it may optionally apply to ::before/after
  florian: Gives some advice on what to do
  florian: Trick here is that if we think about css and html only it's
           not that hard
  florian: I think the options Elika listed are what's on the menu
  florian: But this also relates to the Selection API
  florian: You expect to get a match between selection and what you
  florian: As it exists, I believe Selection is not capable of
           describing pseudos
  florian: I think it would be good to allow this to work, but to make
           it coherent we need to make Selection API capable of
           describing pseudos in its range

  emilio: Is there a pre-existing difference between the output of
          Range.toString and the clipboard?
  emilio: The clipboard use-case seems fixable without the selection
  emilio: I don't think we should include gencon in the text/html
          clipboard, but maybe in the text/plain one
  emilio: I just think we might be able to fix clipboard without
          having to touch Selection
  florian: I believe there's no current difference between them, but I
           think you're right - we can either introduce a difference
           or complexity the Selection API
  <fantasai> +1 to emilio

  Rossen: We're assuming there's only one thing on the clipboard,
          that's usually not the case for rich editing cases
  Rossen: Also, I'd expect whatever ends up in the clipboard isn't
          what we serialize to a11y tools. So if they today get the
          gencon or lose the gencon, I'd expect the same from copy/

  hober: I'm not an expert on this apart of webkit but we have people
         elsewhere who are, I've asked Wenson to come over and express
         an opinion. I'd prefer not to resolve until we have an expert
         on our side weigh in.

  myles: When you said multiple things on the clipboard did you mean
         multiple mime types?
  Rossen: Yes, sorry

  Rossen: So what do we want to do with this?
  Rossen: For me, one of the stronger goals is to make sure we're not
          degrading a11y tools and experience
  Rossen: But if we're waiting for input we can postpone this issue
          a bit.
  TabAtkins: I think it's fine to wait a little bit

  florian: In general for ::marker I think it's at least as desirable
           as ::before/after.
  florian: So wanting to do something seems reasonable.
  florian: The spec says it *may* work for ::before/after but not how,
           so we should consider these together.
  florian: Selection API, clipboard, etc. We should circle back to see
           what's feasible.
  florian: So I think the use-case makes sense but it's about how to
           make it work.
  florian: I don't think it's reasonable to resolve quite yet until

  hober: Other thing to keep in mind is that different native
         platforms have diff behavior
  hober: It's usually the case that a browser wants to match that
         platform's behavior for cut/paste interop
  hober: Myles is trying to figure out what our platform behavior
         even is
  hober: But just noting if the spec requires us to violate platform
         behavior we'd probably violate spec
  florian: I think it's probably not an issue
  florian: The broader conventions outside the browser don't have
           anything to say about web platform pseudos
  hober: Right but they do have lists, so there's at least an analogy
  <emilio> Browsers diverge even on `data:text/html,<p style="display:
           inline">foo</p><p style="display: inline">bar</p>` :)

  fremy: I just tried out of curiosity multiple browsers, and they
         don't copy the same formatting now anyway
  fremy: So not sure if it makes much sense to specify this behavior
         if browsers don't have interop on simpler things
  fremy: But they are at least consistent that they don't copy gencon
  fremy: So I'm just not sure it makes sense to specify behavior on
         ::marker if we don't specify copy/paste in general
  <fremy> test case: https://wptest.center/#/4ff743

  fantasai: I'm fine to defer the discussion if we're asking for more
            info, just don't think we should close and forget about it
  fantasai: To Francois' point, if the default is to not copy out,
            yeah it should keep being the default
  fantasai: But think there should be a way to copy it, it's confusing
            when you copy out and the numbers disappear
  fantasai: You lose a lot of important context
  Rossen: Agree, just wanting to narrow down the issues in a while
          that'll help

  myles: Our platform behavior isn't just that the marker text isn't
         put on the clipboard
  myles: We *also* put tab characters in the clipboard so the list
         looks indented
  <fremy> @myles, what you describe seems to match Firefox, not Chrome
  myles: So our resolution shouldn't be that it only takes the gencon,
         it should allow for matching platform behavior

  florian: I suggest we take a resolution that we try to make this
           work, take an action item to check in with people already
           working in this area with Selection. We should know if they
           have plans or have already rejected in this space.
  florian: Also to check in with the a11y api. That might rescope the
           problem a bit.
  florian: And based on that, trying to define in a way that wouldn't
           conflict with the constraint that Myles expressed
  florian: So I think we should try to add ::marker to that list and
           then figure out what it means

  emilio: Just looked at our code, we do have different serialization
          for Selection API vs clipboard
  emilio: There's a weird mix where for some things we serialize based
          on DOM, and others based on CSS, and there's probably a
          bigger meta question
  emilio: so if you copy a <p style=display:table> are you copying a
          table or a paragraph
  emilio: In general it probably makes sense to look at CSS
  emilio: But then the html clipboard and plaintext clipboard will be
          rather different.
  Rossen: That's good

  Rossen: So first two options are opposite ends of the spectrum,
          don't do anything, yes do everything
  Rossen: Sounds like we're aiming at a nuanced approach between these
  Rossen: Would it make sense to eliminate these two, and make
          progress navigating something like the other two, designing
          and refining what gets output and when?
  fantasai: I mean what if you actually want to copy everything?
  florian: As a reminder, and we can change if it's wrong, the way
           user-select is currently defined is that initial value is
           auto, and auto computes to none on pseudos
  emilio: Used value
  florian: It resolves to none
  florian: But authors can explicitly opt into saying yes. Whether
           that works or not is fuzzy
  florian: So default is to not copy the content. Whether that still
           affects something with lists, that's up to us
  fantasai: So if we wanted to copy lists by default we could make
            ::marker have non-none behavior
  florian: Sure
  Rossen: So can we eliminate those two extreme options to make
  fantasai: Do other browsers need info?
  fantasai: If I'm working on this issue what do I need besides
            talking to Tess and Myles?
  florian: So first ask for existing standards people on Selection or
           editing to see if they're already working in this area.
  fremy: Maybe an action on browser vendors to describe what they're
         doing today?
  florian: Selection is edited by rniwa
  fantasai: So that makes it easy

  myles: Because our primary concern is platform consistency, the
         result of this investigation shouldn't be "write down exactly
         what platforms do", it should be flexible enough to allow
         platforms to do different things that could change.
  Rossen: So a proposed resolution?
  <fremy> (at least on Windows, no browser outputs Text that is
          similar to Word for the same code...)
  florian: Attempt to make this work for ::marker as well as ::before/
           after, come back with a specific proposal that allows it
           while respecting platform conventions
  Rossen: Objections?

  RESOLVED: Attempt to make this work for ::marker as well as ::before/
            after, come back with a specific proposal that allows it
            while respecting platform conventions

Custom properties on :root
  github: https://github.com/w3c/csswg-drafts/issues/6641

  schenney: Problem with highlight pseudos with custom properties
  schenney: Right now you have to double your custom props on the root
  schenney: I summarized the options on the issue
  schenney: From our perspective (chromium/igalia) our preferred
            option is that custom props come through the highlight
            inheritance chain, then if you get to the root and still
            don't have a value for the custom prop, look at the root
  schenney: We feel that has advantage of all the proposals
  <fantasai> summary of the options ->

  schenney: Simple inheritance chain, don't do two lookups
  schenney: It addresses the problem that most people put custom props
            on the root, so we don't have to change our advice
  schenney: Only problem is that if custom props are further down the
            tree we won't discover them
  schenney: But an author always has the ability to put them in the
            highlight inheritance chain manually
  schenney: So proposal is to use the selection inheritance chain, and
            put the root element at the top
  schenney: That's the last proposal in my summary
  <bramus> The summary being

  fantasai: So that means highlight pseudos are able to be assigned
            custom props?
  schenney: Yes, they can use existing from the root, or you can
            define them in the highlight itself
  fantasai: Okay, just need to make that clear in the spec

  emilio: Is there behavior difference between this and saying custom
          highlights always inherit custom props from the root?
  schenney: I think that is the proposal
  schenney: We're only saying to inherit custom props from the root
            not all

  emilio: Okay as an aside I think the highlight inheritance is funky
  emilio: but generally I think it's weird that custom props work in
          some places but not others
  emilio: You can't see a custom prop defined on non-root elements
  TabAtkins: Unless you spam them in
  emilio: It makes me sad that this is more complicated and doesn't
          solve ::backdrop either
  TabAtkins: ::backdrop is pretty different

  iank: The current behavior in the spec is breaking sites, fwiw
  fremy: What is that behavior?
  emilio: A highlight pseudo inherits from your parents highlight
          pseudo, etc. then the root's highlight doesn't inherit from
          the root, so you have to specify your custom props on both
          root and highlight root
  emilio: Current non-spec behavior is that selection pseudos just
          inherit from the originating element, no inheritance from
          the highlight tree at all

  delan: Clarification - the proposal is not that highlight styles
         inherit from the root, but rather that they continue to
         inherit from parent highlight styles, but at the top the root
         highlight inherits from the root element
  delan: So we're only changing what happens at the top
  florian: For custom props only
  delan: Right. There was an earlier proposal where we considered
         doing it for all, and it's simpler, but it breaks paired
         defaults which are a really important compat behavior

  fantasai: 1) if we want internally to implement as inherit
            everything from root to root highlight, you can do that
            and set "all:initial"
  fantasai: You'll have to pull out writing-mode/direction as well.
            But internally you can just inherit everything and reset a
  fantasai: For ::backdrop I think it's completely unrelated, there's
            no weird cascading/inheritance behavior
  fantasai: We should discuss ::backdrop but separately. I don't
            understand why we didn't give it inheritance to begin with
  fantasai: I feel like this is a good proposal.
  fantasai: If you're using custom props in your highlight styling
            you'll have to set that on the highlight itself, but at
            that point you're already selecting that highlight so it's
            not bad

  schenney: I still think that taking a resolution to consider the
            broader solution of different place to define custom props
            (the @document idea from earlier) I think is still
            important, it would solve other cases
  schenney: But I think our current proposal for now will fix the
            breakage we currently see
  fremy: I think I agree with that, we should fix the local problem

  fremy: One comment, to me it makes sense to inherit properties from
         the originating element
  fremy: but you say it would be challenging from impl perspective
  fremy: Why?
  schenney: It's *doable* but it requires two sets of inheritance
            passes to make it work as authors expect
  schenney: You'd have to look down the highlight inheritance chain,
            and if you didn't find a custom variable you'd have to go
            back to the originating element and walk its inheritance
  schenney: Weird behavior from an author's perspective too, it grates
            me as an author
  fremy: It is still confusing to me that you can't make a property
         called --selection-color and change it further down and have
         it work, you have to send it to the highlight itself
  fremy: But it's not for me to say what's hard to implement
  fremy: I do think the root will solve 95% of the problems
  <TabAtkins> (I strongly disagree, I think two inheritances is much
              worse than just rooting the highlight tree under the
              root el)

  oriol: In the spec we resolved that ::backdrop now inherits from
         originating element
  TabAtkins: When I asked Anne about it, he didn't know why it was
             that way, so we fixed it
  emilio: The backdrop case is similar in that the root el isn't in
          its inheritance chain, so if that's fixed it's good
  emilio: But I still think it'll be confusing for authors that they
          can't set further down the tree
  fantasai: Given that highlights don't inherit *anything else* from
            their originating element, I don't think it's unreasonable
            to assume the custom props inherit the same
  fremy: Some things are inherited...
  emilio: currentcolor
  fantasai: That's not inheritance

  delan: I think we're getting sidetracked
  delan: I was originally queued to say that all the breakage we've
         seen (and we've had dozens of bug reports) were about custom
         props on root
  delan: So not a single instance reported of breakage from custom
         props elsewhere in the tree
  delan: so for the compat issue this should be enough

  schenney: re: things coming from originating element, yes
  schenney: And next issue is about another case where we might take
            some info, still not a property tho
  schenney: In *all* cases though, for properties themselves it comes
            solely through the highlight inheritance chain

  ntim: I see authors put custom props on shadow roots, I'd expect
        that to work
  <emilio> To clarify, ntim means via `:host`
  <astearns> +1 to accommodating :host as well
  schenney: So if you put custom props on the shadow root, do you want
            it to have different values for the highlight than
            elsewhere on the page?
  <TabAtkins> :host::selection should work, right?
  <delan> does this proposal change anything around that?
  <emilio> Having an editor custom-element doing something like `:host
          { --selection-color: red }` and use that from highlight
          pseudos seems reasonable...
  <emilio> no

  emilio: It seems reasonable if you have an editor custom element to
          set custom props on :host
  emilio: This is what I was talking about - it seems weird as an
          author that setting props on the root works but setting
          anywhere else doesn't work
  emilio: I understand you can say :host::highlight but I think people
          wouldn't do that
  <ntim> I agree with emilio
  emilio: They'd think if the root case worked, why wouldn't other
          cases work
  emilio: I understand this fixes the compat issue and there are ways
          to get the behavior you want, I just think it's not great

  schenney: I just think the only option would be to go to dual
  schenney: Which is a bad option too
  schenney: So I'd prefer minimum compat maintenance
  <iank> I would prefer no double inheritance

  TabAtkins: I don't agree that this would be confusing for authors
  TabAtkins: having one single inheritance tree is usual
  TabAtkins: and I feel it would be even more strange if different
             properties inherit in different paths
  TabAtkins: I can see people stumbling on this once, of course, but
             they can look up and fix it with specific code
  TabAtkins: so I don't see this being a long term confusion for
  florian: Going in the same direction as Tab, custom props are also
           sometimes used to polyfill regular properties
  florian: Having them be more similar rather than more different
           probably is better

  emilio: I'm just not convinced authors would understand that
          highlight style inherits from other highlight pseudos and
          finally the root

  dbaron: I have mixed feelings overall, but think I'm reasonably
          sympathetic to Tab's argument about consistent model
  dbaron: One of the things we might require authors to do is write
          something both for the el and its highlights
  dbaron: Which might be painful because there's several highlight
  dbaron: We might want a pseudo that refers to all the highlights.
  dbaron: Probably only useful for custom props
  dbaron: Would probably make this less painful for moving custom
          props around

  delan: I think that's a good idea
  delan: I also wanted to say that I'm not convinced that the proposed
         behavior would be too difficult for authors to understand
  delan: and that it would be much worse than the legacy behavior
         where selection inherited from the originating el
  delan: That model, which most browsers currently have, also has
         un-intuitive aspects
  delan: For example, I set a selection color and background color on
         `p`, then the children don't have those colors. Highlight
         inheritance fixes that
  delan: It is something authors could trip on but I think I generally
         agree with Tab, they'll trip over it once and then move on

  fremy: could we have an example of how you fix this with custom els?
  <dbaron> (The example I gave was that authors could style element,
           element::all-the-highlight-pseudos { --custom-properties:
           values }.)
  <emilio> `:host, :host::highlight { --foo: red }
  TabAtkins: You just need to shift them into the highlight tree as
  fremy: Okay that's not that bad
  <emilio> Well, without dbaron's proposal you'd need `:host,
           :host::selection, :host::spelling-error,
           :host::grammar-error, :host::highlight(<foo>),
           :host::highlight(bar), ... { --foo: red }`

  Rossen: So can we get to a resolution?

  proposed resolution: highlight pseudos inherit across the highlight
           tree, and the root highlight inherits custom props from the
           root element
  Rossen: Objections?

  RESOLVED: Highlight pseudos inherit across the highlight tree, and
            the root highlight inherits custom props from the root

Highlight pseudos and non-applicable properties
  github: https://github.com/w3c/csswg-drafts/issues/7591

  schenney: This issue arises when properties in highlights, like
            shadow blur radius, etc
  schenney: Use property values that have font-dependent metrics
  schenney: or any other type of context-dependent value that can only
            be resolved from outside the highlight
  schenney: Like, you can't set font-size on a highlight, but if you
            use 1em in the highlight we need to look that up somehow
  schenney: Currently the spec would have us walk the highlight chain
            for a font-size property, never find one, and use the
            initial value
  schenney: So the proposal is that property-dependent metrics you
            find in a highlight property, you take from the
            originating element
  schenney: font size, line height, etc
  schenney: So if you use the same property on the el and the
            highlight you'd get the same behavior

  delan: A few extra notes
  delan: font-size and line-height are, as the issue title says,
         they're not applicable properties for highlights
  delan: Can't actually change them in highlights, we don't want
         highlighting to change the font size
  delan: so when you highlight *in practice* it takes the font-size
         and line-height from what it would be when it wasn't selected
  delan: So we're trying to make the font-relative units consistent
         with that, matching the actual used font-size and line-height
  delan: rather than some arbitrary initial value
  delan: Also, we had a previous resolution for this a while back
  delan: but it seemed muddled, there were other issues mixed in
  delan: But all we're really trying to do is resolve what happens
         when you use em/etc units
  delan: not really changing anything else here about how shadows or
         decorations work in highlights, just what happens with those

  florian: So we're not *really* discussing property inheritance, just
           unit resolution
  fantasai: I support this proposal and think it's the right thing,
            and the fact that it's implemented is great
  <florian> +1

  emilio: Can't we just... could we fix the previous issue the same way
  TabAtkins: That was the 'don't inherit custom props at all, just
             from originating element'. That runs into you expect
             custom props to inherit
  TabAtkins: [missed]
  TabAtkins: it ends up being a lot weirder in a lot of cases
  TabAtkins: We talked about that solution earlier, i.e. not
             inheriting custom props at all and inheriting from
             originating element
  TabAtkins: that ends up being more confusing, because you can't set
             custom props on highlight a tall, you have to rely on
             light DOM to inherit
  TabAtkins: was confusing that you could set a var() but not set it
             in the same place
  TabAtkins: Because resolution is off a completely different element
  TabAtkins: basically it's confusing
  <TabAtkins> `::highlight { --foo: 1; --bar: var(--foo); }` would
              *not* do what you think
  schenney: Yeah I think the previous behavior would be the bad author
            behavior, using different metric values than what you'd
            see if you used that property on the originating element

  Rossen: So do we still have a proposed resolution?
  schenney: I propose that font and other metrics that used in
            highlights, where that value isn't available from a
            highlight-applicable property, use the originating element
            to resolve that unit
  dbaron: Just to clarify: that's about whether the property in
          question is *valid* for highlights, not whether it's used.
  schenney: Yes
  delan: I wonder if this could be phrased more simply as "in a
         highlight pseudo, the values of font-relative metrics come
         from the originating element"
  schenney: I'm concerned that any other cases where this problem
            arises need a general resolution
  delan: Fair

  dbaron: I think there's a very slight risk in the opposite
          direction, where a unit depends on a combo of properties
          where some are valid in highlights, and there you probably
          want it from the originating element still and not try to
          mix things
  dbaron: maybe there's no example of that right now

  Rossen: So returning to the resolution, any objections?

  RESOLVED: If a unit (or similar value) relies on the value of a
            property that's not applicable to highlights to resolve
            itself, it uses the value from the originating element

  <br until=10am-local>

Highlight pseudos and compat stroke/fill properties
  github: https://github.com/w3c/csswg-drafts/issues/7580
  scribe: emilio
  scribe's scribe: bramus

  schenney: Simple question: -webkit- prefixed stroke / fill
            properties are interoperable and supported across
            browsers, but not supported in highlights
  schenney: question is should they?
  emilio: I think they are not synonymous with their unprefixed
          versions. Some are not impl as aliases
  emilio: I think it is worth trying not to support them
  <TabAtkins> agree

  fantasai: I think the intention was that they would eventually be
  fantasai: We should look into whether we can make them aliases
  fantasai: Up until we do that I'm fine with them not being supported

  schenney: I'd support not supporting them but could in the future if
            unprefixing them becomes appropriate
  florian: The compat spec isn't entirely clear between the
           interaction between these and the unprefixed versions
  florian: We should be looking into doing this
  florian: and if they end up being aliases then yeah they should work
  fantasai: Makes sense, I guess that means TabAtkins and I are
            responsible for that
  fantasai: if/when we can make them aliases then they'd start working
  GameMaker: I'm agreeing with fantasai, support them once unprefixed,
             not support them until then
  <TabAtkins> (elika and I stopped working on fill-stroke because
              there was no one biting on implementation)
  <TabAtkins> (we're happy to pick it up again)
  <GameMaker> WebKit obviously has an implementation, and we were just
              looking at supporting these in highlights, so I would
              love if we can move forward with the unprefixed versions

  RESOLVED: Do not support them until unprefixed

Received on Sunday, 10 September 2023 15:22:41 UTC