[CSSWG] Minutes Telecon 2023-01-25 [css-nesting] [css-text] [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 Nesting

  - RESOLVED: Publish updated WD of CSS Nesting with an added issue
              about lookahead

CSS Text

  - RESOLVED: A single-string value changes what is inserted, but not
              where (Issue #2975: hyphenate-character doesn't just put
              hyphen at end of line)
  - RESOLVED: Close WONTFIX (Issue #5972: Hyphenation styling should
              apply to the wbr element)
  - RESOLVED: Accept changes [changes:
              (Issue #5973: Better describe the likely outcomes of
              hyphenation (editorial))
  - RESOLVED: Republish CR [of CSS Text 3]!

CSS Pseudo

  - RESOLVED: Restriction will be relaxed to allow punctuation-only
              matching (Issue #2254: Multi-line ::first-letter)
  - RESOLVED: Revert previous resolution; accept :blank works for this
              use case (Issue #2517: Clarification: do ::placeholder/
              :placeholder-shown apply to <select>s' “placeholder
              label option”?)
  - RESOLVED: ::first-line applies to markers when
              `list-style-position` is `inside` but excludes them when
              it's `outside` (Issue #5406: Should ::first-line include
  - RESOLVED: CSS inline layout properties are not applied to
              ::placeholder (Issue #5379: Should `line-height` be
              applicable to ::placeholder?)
  - Discussions began around use cases for issue #6641 (Custom
      properties on :root) but the call time ended before the group
      could do any deep discussion about the potential usage.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0010.html

  Adam Argyle
  Rossen Atanassov
  Tab Atkins
  David Baron
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  Daniel Holbert
  Jonathan Kew
  Peter Linss
  Alison Maher
  Eric Meyer
  François Remy
  Morgan Reschenberg
  Jen Simmons
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou

  Rachel Andrew
  Delan Azabani
  Chris Harrelson

Chair: Rossen

Scribe: emeyer

CSS Nesting

  Rossen: Any changes to the agenda?
  flackr: Propose breakout session for scroll animations?
  Rossen: Let's do that on the mailing list

  fantasai: We should publish updated WD of CSS Nesting, it was last
            updated 2021
  plinss: Want to revert a previous resolution before republishing,
          but it's not a big deal since it is a WD
  fantasai: Yes, we can add an issue about lookahead

  RESOLVED: Publish updated WD of CSS Nesting with an added issue
            about lookahead

CSS Text

hyphenate-character doesn't just put hyphen at end of line
  github: https://github.com/w3c/csswg-drafts/issues/2975

  fantasai: Last two comments on issue clarify that single-string
            value changes what is inserted, but not where
  <jfkthame> +1
  Rossen: Any opinions?
  florian: I think it's the right thing to do for now
  florian: When we look into expansions, we'll need to think harder
           about whether this is novelty hyphens or about manually
           defining hyphenation in unsupported languages

  RESOLVED: A single-string value changes what is inserted, but not

Hyphenation styling should apply to the wbr element
  github: https://github.com/w3c/csswg-drafts/issues/5972

  <fantasai> ->

  fantasai: We propose to close WONTFIX because <wbr> is a soft-wrap
            but not a hyphenation opportunity
  fantasai: HTML could extend itself to do more, but current spec is
            written that if that ever happens, this will all apply to
            that correctly
  <florian> I'm the other part of "we", so I agree
  <TabAtkins> +1 to wontfix


Better describe the likely outcomes of hyphenation (editorial)
  github: https://github.com/w3c/csswg-drafts/issues/5973

  <fantasai> ->
  fantasai: We added examples
  fantasai: and made a normative change to say a hyphenation character
            property applies to soft hyphenation opportunities
  fantasai: if there's supposed to be a spelling change in a
            hyphenated word, you should apply that
  fantasai: we want the UA to make a best effort but it may or may not
            match up
  <fantasai> normative changes ->
  florian: Examples were added to show these sorts of situations
  Rossen: Anything else?
  Rossen: Any objection to these changes, or do we need more time?
  florian: We did get a heart emoji on the issue, so there's that

  RESOLVED: Accept changes

  github: https://github.com/w3c/csswg-drafts/issues/6900

  fantasai: We compiled a changes list and disposition of comments
  fantasai: There's a minor change we made as a followup to one of the
  fantasai: Assuming that's good, we'd like to request an updated CR
  <fantasai> https://github.com/w3c/csswg-drafts/commit/d3ed39e04fb2a3087aa745dce57abd59c93412c5
  fantasai: `text-justify: distribute` addition
  fantasai: spec was updated to allow Firefox treatment
  florian: About testing, all normative changes since last CR do have
  florian: Spec itself has pretty extensive test coverage
  florian: Not complete, but pretty exhaustive
  Rossen: All the more reasons to republish

  RESOLVED: Republish CR!

CSS Pseudo

Multi-line ::first-letter
  github: https://github.com/w3c/csswg-drafts/issues/2254

  <fantasai> ->
  oriol: We discussed in the past what happens if first-letter
         container is very narrow
  oriol: And then would span multiple lines
  oriol: We resolved to clamp to match characters in the first line
  oriol: Focus of the previous proposal was not addressing this
  oriol: Better to discuss this and clarify
  oriol: So: what to do if the first-letter container only contains
  oriol: Spec currently selects punctuation if there's another letter
         character that appears later in the container
  oriol: This seems strange; if the letter character is in another
         line and you remove it, this suddenly makes the first-letter
         unable to match punctuation characters
  oriol: first-letter should only be allowed to match punctuation
  oriol: I think Gecko's behavior makes more sense
  oriol: Some prefer the specification as it is now

  Rossen: Opinions?
  Rossen: Any objections to resolving on the option to use Gecko's
  iank: Basically logic UAs use to skip punctuation characters would
        have that logic removed?
  oriol: Yes, since the only one affected would be Blink, it would
         need to start matching punctuation-only containers
  Rossen: I believe the answer is yes, Blink can stop skipping

  RESOLVED: Restriction will be relaxed to allow punctuation-only

Clarification: do ::placeholder/:placeholder-shown apply to <select>s'
    “placeholder label option”?
  github: https://github.com/w3c/csswg-drafts/issues/2517

  fantasai: The placeholder-shown example is about validation and it's
            not really a placeholder option, it's just a validation
  fantasai: Tab and I propose to undo previous resolution and have
            :blank match the default option in a dropdown
  TabAtkins: Placeholder pseudo doesn't explicitly refer to validation
  TabAtkins: Any time your input is empty, it will match ::placeholder
  TabAtkins: I agree with Elika, we can revert about adding
             placeholder label option to matching placeholder pseudos
             and lean on :blank for use cases
  TabAtkins: This will get us where we want without binding us to this
             weird solution

  Rossen: Any objections?

  RESOLVED: Revert previous resolution; accept :blank works for this
            use case

Should ::first-line include markers?
  github: https://github.com/w3c/csswg-drafts/issues/4506

  <fantasai> ->
  <fantasai> ->
  <fantasai> ->
  fantasai: Does ::marker part of a ::first-line or not?
  fantasai: A lot of tests were done on implementations
  fantasai: Proposed resolution is ::first-line includes markers when
            `list-style-position` is `inside` but excludes them when
            it's `outside`
  oriol: I think that's fine
  <TabAtkins> No strong opinion from me, but the proposed resolution
              seems good

  emeyer: So this would mean that if list-style-position is outside,
          and color is set by ::first-line, the marker would not pick
          up that color
  TabAtkins: correct
  TabAtkins: With outside positioning, it's positioned, so we're
             considering it outside the line
  fantasai: This is important if you set a background color on the
            first line and it wouldn't match well with the marker, we
            don't want it to apply to that outside marker

  RESOLVED: ::first-line applies to markers when `list-style-position`
            is `inside` but excludes them when it's `outside`

Should `line-height` be applicable to ::placeholder?
  github: https://github.com/w3c/csswg-drafts/issues/5379

  <fantasai> ->
  fantasai: Proposal is to exclude CSS inline layout properties from
  Rossen: Objections?

  RESOLVED: CSS inline layout properties are not applied to

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

  <fantasai> ->
  TabAtkins: Authors often define a big set of custom properties on
             the root element
  TabAtkins: These reasonably might want to be used in highlight
  TabAtkins: Currently, highlight pseudos don't inherit from the
             normal DOM tree
  TabAtkins: So they won't see any of the stuff on the root
  TabAtkins: The way around that is to have that big block have a
             selector of `:root, ::highlight`
  TabAtkins: It's a little weird and funky
  TabAtkins: There are a few suggestions to address this
  TabAtkins: One is to have some kind of at-rule allowing you to apply
             custom properties at a level higher than the root, which
             highlight pseudos could see
  TabAtkins: Another is to change things so that highlight pseudos
             resolve their vars against the originating element
  TabAtkins: Another is to say highlight inherits all custom
             properties from the root
  <fantasai> ... and maybe all properties from the root
  TabAtkins: I don't like resolving var() differently
  TabAtkins: I think it would complicate or break setting vars
             directly on highlights
  TabAtkins: Inheriting from the root element has possibilities, but
             could cause cascade problems
  TabAtkins: Inheriting just custom properties would be a little
             weird; it has minimal impact but it's a new way of doing
             things that might have implementation problems
  TabAtkins: Having a root-superior at-rule is also a new weird way to
             address this
  TabAtkins: Not really sure how to approach this, but leaving as is
             where you have to select both root and highlights has
             some implementor objections over memory cost

  <bramus> A use-case for inheriting only custom properties is
  <fantasai> bramus, why?
  <bramus> Authors want it:
  <fantasai> bramus, but ::backdrop could just inherit from its
             originating element like all pseudo-elements, couldn't
             it? why would you want it to inherit from :root

  miriam: ::backdrop has a similar problem and it's caused author
          problems, and articles are starting to pop up about having
          to address both
  miriam: I like ::document or something like that, maybe could also
          respond to dark and light modes
  miriam: I'm not sure a document-selector toggle could respond, though

  bramus: There's author demand for backdrop inheriting custom props
  fantasai: That is a little different, as ::backdrop can inherit from
            its originating element and we should make it do that
  fantasai: highlights have to inherit from a tree parallel to the
            document tree
  fantasai: I can see reasons why we might want an @document
  fantasai: Downside to inherit-from-root is that you can only ever
            get variables from the root, not from other elements
            between root and the highlight
  <bramus> Spec says it doesn't:
  <bramus> “It does not inherit from any element and is not inherited
  <TabAtkins> Right, spec says it doesn't, but we can't see any reason
              *why* it shouldn't inherit.
  <bramus> True :)
  <TabAtkins> We asked about it in the repo but haven't gotten a
  <fremy> +1 to inherit custom properties from :root, I think they are
          de-facto considered "global" by authors

  argyle: If I do define a bunch of vars on @document I could toggle
          them, but it's a good place to put them
  argyle: The at rule would be the place things are originally
          defined, but can be changed later
  fremy: I don't see why a document is different form an initial value
         in this case
  fremy: Why would we ask authors define things in @document and then
         ask them to redefine later
  <fremy> (for the minutes, I mentioned how developers already assume
          :root variables are global, and we could acknowledge them
  <dbaron> argyle, what about miriam's point about things like light/
           dark mode depending both on media queries *and* an
           attribute on the root that comes from a user-facing toggle
  <argyle> dbaron: @document { --brand: hotpink }, and for dark mode
           `@media (prefers-color-scheme: dark) { :root { --brand:
           deeppink } } .dark { --brand: deeppink }` is what I was
  <fremy> @ argyle what is the value of @document here? @property
          { initial } feels identical (and, I believe, not that great
          in this case, you would want the deeppink in dark mode)

  Rossen: Any other thoughts?
  Rossen: Do we feel like we're close to resolution, or should we just
          capture this and pick it up next week?

  fantasai: Is there any reason we should NOT have the highlight
            pseudo inherit from :root?
  TabAtkins: If you put color: black on root and then inherit into the
             highlight, it would break the cascade
  fantasai: I think that can work by having the UA stylesheet break
            inheritance for color
  fantasai: You can have paired default highlight colors happen based
            on author style rules
  <TabAtkins> (I'm completely confused as to what fantasai is trying
              to say.)
  <TabAtkins> (Either I, her, or both of us don't understand what
              we're talking about.)
  dbaron: A reason not to add it is that it still doesn't solve the
          variables problem when they're set on something other that
          the root

  Rossen: We'll have to close here, the clock has run out

IRC chat post-meeting

  <TabAtkins> fremy: Problem with `@property {initial:...}` is (a)
              it's a lot more verbose than a `--foo:...;`, and (b)
              initial values can't refer to each other, so you can't
              set a default composite custom property
  <fremy> @ TabAtkins, ah yes, the compositionality argument makes
          sense (still feel :root ought to be enough, but different
  <TabAtkins> I agree that something just referencing :root is gonna
              be the best ^_^
  <fantasai> [post-meeting discussion]
  fantasai: three options
  fantasai: 1. inherit from :root
  fantasai: 2. inherit custom properties from originating element,
            other properties from highlight parent
  fantasai: 3. don't manage custom properties on the highlight, have
            var() look up on the originating element
  <fantasai> 1. Doesn't handle subtree variable changes
  <fantasai> 2. is hard to implement, because you have two different
                inheritance models for the same element
  <fantasai> 3. has the weird problem that you can't set a custom
                property and use it in the same declaration block
  <fantasai> emeyer indicates that as an author, he'd expect behavior
             of #2

Received on Wednesday, 25 January 2023 23:55:50 UTC