[CSSWG] Minutes Telecon 2022-10-12 [css-text-4] [selectors] [css-ruby] [css-values] [css-nesting] [css-tables]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Meeting Schedule

  - There will be an extended meeting on Wed Oct 26, 2022 from 7:00am –
      10:00am PT

CSS Text

  - RESOLVED: Incorporate trim-end behavior into the normal keyword
              (Issue #7055: text-spacing: trim-end is better than
              allow-end for the normal value)

CSS Ruby

  - RESOLVED: Add text-justify:ruby, which is like 'auto' but disables
              justification opportunity on spaces and bopomofo (Issue
              #771: Treatment of multiple Latin words in space-between
              & space-around)
  - RESOLVED: `rt, rtc { text-justify: ruby; }` to UA stylesheet (Issue


  - RESOLVED: `lang=und` matches :lang("*")`, `lang=""` doesn't match
              any `:lang()` (Issue #6915: `:lang` for documents without
              content language and for elements of unknown language;
              consider `:lang("")` over `:not(:lang("*"))`)
  - RESOLVED: Accept :open and :closed with definitions as proposed by
              TabAtkins (Issue #7319: Add `:open` or `:top-layer`
              pseudo class)
      - Proposed definitions:
          The :open pseudo-class represents an element that has both
          "open" and "closed" states, and which is currently in the
          "open" state. Exactly what "open" and "closed" mean is
          host-language specific, but exemplified by elements such as
          HTML's <details>, <select>, and <dialog> elements, all of
          which can be toggled "open" to display more content (or any
          content at all, in the case of <dialog>).
          Note: Being "open" is a semantic state. An element not
          currently being displayed (for example, if it is in a
          display: none container) can still be "open" and will match

CSS Values

  - The proposal for issue #7431 (Restrict none/auto/normal from
      <custom-ident>) was to restrict none/auto/normal from
      <custom-ident> however, after conversation, there is a desire to
      revisit in context of the overall <custom-ident> grammar to
      ensure this doesn't make other naming issues worst.

Nesting & Selectors

  - RESOLVED: Accept to make & valid everywhere, maps to :scope where
              not otherwise defined (Issue #7545: Move nest-containing
              and nest-prefixed selector definitions to Selectors)

CSS Tables

  - The group is going to think more about the possible use cases
      around issue #7340 (Allow 'order' on table columns) and decide
      next week if this is something they want to pursue further.


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Oct/0003.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Elika Etemad
  Robert Flack
  Mason Freed
  Megan Gardner
  Paul Grenier
  Daniel Holbert
  Brad Kemper
  Jonathan Kew
  Vladimir Levin
  Peter Linss
  Alison Maher
  François Remy
  Morgan Reschenberg
  Florian Rivoal

  Chris Harrelson
  Miriam Suzanne
  Lea Verou

Chair: Rossen

Scribe: TabAtkins

Next vF2F/Extended Call

  <Rossen> Wed Oct 26, 2022 from 7:00am – 10:00am PST

CSS Text

text-spacing: trim-end is better than allow-end for the normal value
  github: https://github.com/w3c/csswg-drafts/issues/7055

  fantasai: About text-spacing
  fantasai: One of its functions is to handle the blank half of CJK
  fantasai: A couple of values of how to handle it at start or end of
            the line, trim or not
  fantasai: Proposal from murakami-san is incorporate the trim-end
            behavior into the 'normal' value
  fantasai: review from i18n is to recommend adopting this
  <fantasai> https://www.w3.org/TR/css-text-4/#text-spacing-property

  Rossen: Objections?

  RESOLVED: Incorporate trim-end behavior into the normal keyword


`:lang` for documents without content language and for elements of
    unknown language; consider `:lang("")` over `:not(:lang("*"))`
  github: https://github.com/w3c/csswg-drafts/issues/6915#issuecomment-1247024928

  fantasai: When a lang is unknown, there's two ways to make it unknown
  fantasai: first is blank `lang` value
  fantasai: second is `lang=und`
  fantasai: So how do you match these elements?
  fantasai: Proposal is `:lang("")` matches untagged (blank tag), and
            add a note that `"und"` and `""` are matched differently
            despite similar semantics
  fantasai: And then `:lang("*")` will match any tagged element,
            including `lang=und` (but won't match untagged/empty string)

  TabAtkins: Sorry, hadn't read the discussion, but what's the
             justification for treating empty string differently from
  Rossen: I'm not sure about treating them differently

  <PaulG> which spec does "und" value come from?
  <fantasai> Probably BCP47
  Rossen: Is it in selectors, or text...?
  fantasai: und is in the lang tag spec
  PaulG: rfc 5646 doesn't have it, it's not in the IDN reg
  Rossen: Perhaps we should delay a week for florian to be able to
          weigh in
  <dbaron> und looks like it's for undetermined

CSS Ruby

Treatment of multiple Latin words in space-between & space-around
  github: https://github.com/w3c/csswg-drafts/issues/771#issuecomment-1182339573

  <fantasai> https://github.com/w3c/csswg-drafts/issues/779
  fantasai: Ruby text, when you put it on base text, it has different
            default alignment. Latin text and bopomofo is centered, but
            cjk ruby, if the annotation is smaller than base, it'll be
  fantasai: Straightforward way to handle this is to say that ruby
            annotations are justified by default, and to adjust the
            justification opportunities
  fantasai: In normal text we allow spaces to stretch, and
            inter-character for CJK
  fantasai: So if we create a justification method where spaces don't
            expand, but CJK still does, we'll get the intended behavior
  fantasai: And then people who want a different behavior can use
            text-justify: inter-word or inter-character if they want it
  fantasai: So proposal is to create this new justification mode
  fantasai: One, we could say text-justify:auto on ruby annotation has
            special behavior,
  fantasai: Two, we could introduce a new text-justify:ruby keyword,
            and use that in the UA stylesheet
  fantasai: Probably introducing a new keyword is a little more
            straightforward for impls
  <TabAtkins> Sounds reasonable to me, but I'm not a text implementors.
              Also lean slightly toward new keyword.
  florian: I agree

  Rossen: Can we have a res with a path forward, not open options?
  fantasai: Yes, one or the other
  Rossen: So proposal to add new text-justify mode as a keyword
  fantasai: Yes, add text-justify:ruby. It disables justification
            opportunities on spaces and bopomofo, but otherwise is like

  RESOLVED: Add text-justify:ruby, which is like 'auto' but disables
            justification opportunity on spaces and bopomofo.

  fantasai: Also need a resolution to apply it to rt and rtc in UA
  Rossen: Objections?

  RESOLVED: `rt, rtc { text-justify: ruby; }` to UA stylesheet


`:lang` for documents without content language and for elements of
    unknown language; consider `:lang("")` over `:not(:lang("*"))`
  github: https://github.com/w3c/csswg-drafts/issues/6915#issuecomment-1247024928

  <fantasai> dbaron dropped a link to the "und" definition in

  Rossen: So question was inconsistency between empty string and und
          both being "undefined", but they match differently
  florian: Empty string is defined to mean "undefined" by HTML. "und"
           is defined as "undefined by ISO [something]
  florian: Possibly HTML shouldn't have introduced another value to
           mean the same thing
  florian: but it did
  florian: i18n group was somewhat struggling with whether to unify it
           or not
  florian: Could be pushed back, but logic was that HTML didn't unify
           them, and when we do the string matching of lang selectors
           we do string matching without worrying about the semantics
  florian: So our :lang() just does standard lang string parsing +
  florian: So logic was probably "just keep it simple"
  florian: In practice HTML semantics somewhat combine both "explicitly
           undetermined" and "author couldn't be bothered to specify".
  florian: but generally, this is a space where we don't control the
  florian: But I don't think i18n was firm on the conclusion, so if we
           want to push back it could be heard

  TabAtkins: That does answer the question
  TabAtkins: I think I'd be happier if we push back
  TabAtkins: but having this distinction from HTML be reflected in our
             Selectors should be avoided if possible
  florian: I think what happened in practice is the observation is that
           "und" wasn't really used on the web, so empty string is how
           it was actually done in HTML
  florian: So effectively we can ignore the "und" value and have
           :lang("*") match everything *but* the empty string.
  florian: And so while technically "und" matches the lang, in practice
           undefined langs don't match it
  fantasai: Yeah, "*" matches "und", but we've had a request for "can I
            match things without a language", and we'd be able to do
            that if we make a distinction in this manner
  <TabAtkins> My position is very weak, I defer to whoever has expertise

  jfkthame: I think this is a distinction we should maintain, seems
            there is a semantic difference between lang being undefined/
            untagged and explicitly tagged as undetermined
  jfkthame: I agree "und" is rarely used but it does seem semantically
  TabAtkins: If we accept to keep distinct, we don't need to push back.
             Since several people think it's good to keep separate, I'm
             ok with that
  florian: The group that came up with the original rec was just weakly
           leaning - I think they got it right, but still

  PaulG: Agree with keeping them separate. I suspect coalescing would
         encourage more "und", where default lang choice is used when
         undefined, but I think it shouldn't when it's explicitly
  <TabAtkins> Sounds good to me
  <TabAtkins> (I appreciate the "undefined" vs "undetermined"
              distinction. Was just objecting to two separate
              "undefined" notions.)
  Rossen: Objections?

  RESOLVED: `lang=und` matches :lang("*")`, `lang=""` doesn't match any

CSS Values
  scribe: fantasai

Restrict none/auto/normal from <custom-ident>
  github: https://github.com/w3c/csswg-drafts/issues/7431#issuecomment-1178237576

  TabAtkins: In the definition for <custom-ident> in Values and Units
  TabAtkins: can be any keyword, except CSS-wide keywords
  TabAtkins: can't name an animation "initial"
  TabAtkins: any other keywords that need to be excluded for
             grammatical ambiguity reasons, you need to specify that
  TabAtkins: However, there's a handful of keywords that are used so
             often in properties, and seem so not-very-useful for
             naming things
  TabAtkins: that it might make sense to restrict them as well
  TabAtkins: specifically: auto, none, normal
  TabAtkins: these are used in a lot of properties, and are not good
             names for animations/counter-styles/etc.
  TabAtkins: First question is, are sites using these?
  TabAtkins: dbaron did an initial analysis, and while they are used in
             a few places
  TabAtkins: they appear to be invalid in those places anywhere
  TabAtkins: e.g. 'none' as a line name in Grid, but no 'none' line
  TabAtkins: so makes sense to treat as invalid anyway
  TabAtkins: I believe compat impact will be minimal to none
  TabAtkins: all uses we saw were already invalid
  TabAtkins: and this should make custom idents safer to use in
             general, without us having to remember to explicitly cut
             out these common keywords
  TabAtkins: so that's the proposal -- restrict none/auto/normal from

  plinss: If using 'none' as a line name now, would that invalidate the
          line name or the whole declaration
  TabAtkins: invalidate the whole declaration
  plinss: That's more breakage than making valid but matching nothing
  plinss: That said, I'm not too concerned
  plinss: probably too late to do anything, allowing custom-idents
          without prefixing was risky in the first place
  TabAtkins: Definitely it's a problem we should avoid
  plinss: Should we require that, and not repeat this mistake that
          allows potentially conflicting <custom-ident>
  TabAtkins: Could do that, make these legacy
  fantasai: I would prefer to stay consistent with existing practice
  fantasai: Anyway that's outside the scope of the issue

  <dbaron> One other example I've seen is the use of `auto` as a named
           toggle state in https://toggles.oddbird.net/#named-modes
  dbaron: There are probably some uses of <custom-ident> that could be
          <ident> because don't conflict with other stuff
  dbaron: not sure if that's one of them
  TabAtkins: names, toggle-state, and line names won't
  TabAtkins: Problems are things like animation-name, which we screwed
             up on, and don't want to repeat that
  plinss: Original sin here was unquoted font names, all kinds of
          problems from day 1

  fantasai: Back to original issue, do we exclude these keywords? I
            propose to accept
  TabAtkins: I'm now less convinced that we should
  TabAtkins: Maybe revisit grammar, and require only using in
             unambiguous contexts like line names
  TabAtkins: Let's not screw it up again
  fantasai: I still think it's worth excluding these keywords
  TabAtkins: I say take it back to issue

Nesting & Selectors

Move nest-containing and nest-prefixed selector definitions
    to Selectors
  github: https://github.com/w3c/csswg-drafts/issues/5745#issuecomment-1271874448

  TabAtkins: Separate from discussion of which exactly nesting syntax
  TabAtkins: all of our proposals use the &
  TabAtkins: We have a few different contexts where we do nesting
  TabAtkins: and they don't currently allow &
  TabAtkins: Right now assumption is that & only has meaning and
             possibly only valid in direct nesting
  TabAtkins: this is not great, particularly if use & > .foo
  TabAtkins: meaning of this is clear in any nestable context
  TabAtkins: so being able to copy-paste rule between different things,
             from nesting to @scope or querySelector
  TabAtkins: even globally, makes sense, just say parent context is
  TabAtkins: similarly in shadow DOM
  TabAtkins: So proposal is, to avoid authors being forced to edit
             selectors as they move nesting context
  TabAtkins: defined & to be valid and to have meaning in other context
  TabAtkins: If not defined specially, is equivalent to :scope
  TabAtkins: and this is already defined globally, top level it is host
             element of shadow stylesheet or :root otherwise
  TabAtkins: so make this analogous unless context explicitly defines
             it analogously
  florian: Seems reasonable, but haven't thought about it much
  Rossen: I'm convinced, too
  Rossen: Objections?

  PaulG: Gotten to comments about how used inside scope would be
         referencing, if possible to get up to another nested context
  PaulG: Getting confused to understand, anyone can describe clearly?
  PaulG: "What would the below example be? Would be unable to reference
         :scope in a nested context"
  <TabAtkins> (comment is
  TabAtkins: The answer is later in the thread, where the call was to
             not to change meaning of :scope
  TabAtkins: Doesn't change the meaning, & is always using the local
             definition of it
  TabAtkins: Question was if you put nested style rule under the img
             style rule, what would & refer to, it would refer to img
  TabAtkins: Direct nesting doesn't change :scope
  PaulG: Thanks
  Rossen: Back to objections?

  RESOLVED: Accept to make & valid everywhere, maps to :scope where not
            otherwise defined


Add `:open` or `:top-layer` pseudo class
  github: https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1242377579

  TabAtkins: We've talked about this topic before, last time we did the
             name :open seemed to be preferred
  TabAtkins: we wanted a strict definition before resolving
  TabAtkins: so I drafted one, see comment
  TabAtkins: [reads comment]
  TabAtkins: Secondary question, do we want a :closed pseudo-element
  TabAtkins: because :not(:open) selects all elements not just openable
  TabAtkins: First question is, should we resolve to add :open with
             this definition?
  TabAtkins: second, do we want to add :closed
  <tantek> SGTM and +1 to :closed
  <flackr> +1 to both
  <fantasai> +1 to both
  <masonf> +1 to both
  Rossen: +1 to both

  TabAtkins: There's also a comment from annevk about asking ":shown",
             and masonf replied that it would be less confusing to use
  TabAtkins: I agree with masonf's comment
  [see https://github.com/w3c/csswg-drafts/issues/7319#issuecomment-1274745594 ]
  <PaulG> +1 to both
  <tantek> agreed, open/closed sound more semantic than shown/hidden.
           also "hidden" already has a different meaning in CSS
  <flackr> +1
  <ydaniv> how will :closed match differently from :not(:open)?

  plinss: :open also matches the .open property
  TabAtkins: Only elements that have a notion of open and closed can
             match :closed
  TabAtkins: similar to :playing :paused, can only match elements that
             have that notion

  Rossen: Anything else?
  Rossen: Objections?

  RESOLVED: Accept :open and :closed with definitions as proposed by

CSS Tables
  scribe: TabAtkins

Allow 'order' on table columns
  github: https://github.com/w3c/csswg-drafts/issues/7340#issuecomment-1247390415

  fremy: Can summarize, maybe can't resolve
  fremy: So we have some props that apply to grid-ish layout modes but
         not tables
  fremy: we discussed 'gap' earlier
  fremy: But 'order', think it makes sense to be able to swap columns
  fremy: Right now you have to change every single row to swap columns
  fremy: So you'd be able to apply 'order' to columns and it will swap
         them around. Sounds reasonable, but raises some questions
  fremy: column groups, spanning cells, etc
  fremy: There's a concrete proposal - you glue together columns that
         are part of a column group or have spanning cells, and they
         can't be moved separately
  fremy: Seems doable, but is it something we want to do?

  iank: My concern - this sounds ok - but this is slightly special and
        new because it isn't how order works in the other properties
  iank: Like flex and grid, it just literally reorders the items as you
        lay them out
  iank: This has a second-order effect
  iank: So a little more complexity
  iank: Also want to spend more time thinking about how columns move
        when they're spanning

  PaulG: Table semantics often have grid controls like arrow keys,
         focus groups, etc
  PaulG: Reordering columns means devs also have to understand the
         impact on those, and adjust
  PaulG: Seems quite complex and fraught
  PaulG: If it doesn't adjust, the arrow keys will jump columns and not
         match visual order
  PaulG: If we adopt focus group controls, it'll get more complicated
  fremy: Agree, but we're just talking about data tables. If you use
         for anything else you're doing wrong
  fremy: But this is same for Flexbox generally, if you change the
         order you have to worry about keyboard order.
  fremy: But I do think this is a valid concern
  fremy: I think if we assume it's just data tables it's ok

  dbaron: In terms of column spans/groups, I think reordering in a way
          that doesn't break them is probably desirable
  dbaron: But it's not especially clear to me what you do to keep them
  dbaron: Can maybe be flushed out in the issue
  dbaron: Also concerned with same things as PaulG, whether there are
         *good* use-cases that justify the problematic with keyboard
  fantasai: Question really is not whether this is ready to adopt right
            now, but if this is something we potentially care about at
            all. If we think it's bad we can just drop it, rather than
            asking fremy to work on it.
  fremy: Suggest we give everyone a week to think about it.
  Rossen: agreed

Received on Wednesday, 12 October 2022 23:31:12 UTC