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

[CSSWG] Minutes Virtual F2F 2020-05-06 Part IV: Custom State Pseudo Classes

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 15 May 2020 18:48:47 -0400
Message-ID: <CADhPm3v+WoxZ=m062joBWnDHCbZ-pOsSEwcoabzJKvgN8Fdnkg@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Custom State Pseudo Classes

  - RESOLVED: Syntax changes from :state(foo) to :--foo (WICG custom
              state pseudo classes issue #6: Switch syntax from
              :state(foo) to :--foo)


Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-three-time-slot-3a

Scribe: myles

Custom State Pseudo Classes

Switch syntax from :state(foo) to :--foo
 GitHub: https://github.com/WICG/custom-state-pseudo-class/issues/6

  TabAtkins: Should I go over the history? Or just jump right in?
  astearns: Please refresh us
  <jensimmons> I always appreciate context

  TabAtkins: Custom elements want to be able to expose some way of
             selecting based on stuff happening internally to them.
             Like <input> exposes :invalid state. Theoretically they
             can do this by altering the attributes on the host
             element, but this is bad because they shouldn't change
             outer page's stuff because elements shouldn't change
             themselves from underneath. Confusion & unintended
             interaction with scripts ensue
  TabAtkins: We try avoid this in other places. Exposing the ARIA
             stuff directly as an API
  TabAtkins: If an element wants to declare it's in another state,
             attributes are bad. So :state can correspond to some JS
             API underneath that the element can manipulate
             internally. "I'm matching a light class and a wide class"
             or whatever
  TabAtkins: Initially we realized that :state is a null word, it
             doesn't have any meaning on its own here, and we avoid
             that in CSS. All pseudo-classes are a type of state.
  TabAtkins: If we want to emulate the sort of thing that built-in
             elements can do, like :invalid, this is what we wanted to
             run into for custom pseudo classes eventually. The syntax
             for custom pseudo classes were supposed to be just like
             normal, but starts with --
  TabAtkins: The suggestion is to change the syntax to that. So you
             could do :--light to match light mode.
  TabAtkins: There were other topics about boolean vs enum pseudo
             classes, but we won't talk about those now
  TabAtkins: Just for now: Should we change from :state(stuff) to
  <florian> makes sense to me
  TabAtkins: The web components meeting isn't a ruling body so we have
             to discuss this here
  TabAtkins: (in CSS)

  hober: tl;dr: I can live with this, but I prefer :state().
  hober: I'm not sure it would be useful to reiterate the reasons for
         preferring :state() because these are in the issue. Other
         folks like mjs and Greg have raised them.
  hober: But if that's the consensus, we can live with it.

  AmeliaBR: Same as hober in general. I'm a bit concerned if :--x and
            ::--x have two very distinct meanings, and I don't think
            we have widespread author understanding of the difference
            between pseudo classes and pseudo elements. I don't know
            if the final proposal will keep the part wrapper for the
            pseudo element and drop the state wrapper for pseudo
  TabAtkins: There's a possibility it might change. The reason is that
             pseudo classes and pseudo elements work differently.
             Pseudo elements are a combinator and selector in one. If
             you want to select on more than one aspect (like multiple
             part names) and we switch to ::-- then you could only
             select one. But for pseudo classes you can select more
             than one
  TabAtkins: Due to unfortunate history, we're under different
             constraints for pseudo element parts. ::part might be the
             best way, but we're in discussions. You might be able to
             expose the part names can be used directly as ::--
  TabAtkins: So if you have a calendar widget and your days are
             exposed as parts, you want a partname of day, partname of
             "weekend" vs "weekday", etc. So all of these can be
             selected in whatever combination you need to style
             particular things. So you couldn't say ::--weekend but if
             you want to style weekend in the second week differently
             then you could use ::part that would let you select both
             at once
  TabAtkins: I'm not caught up on this discussion. The current thought
             is to allow both -- in as many places as possible for the
  AmeliaBR: My concern is that it could get confusing for authors of
            the difference between what's selecting the state of the
            custom element vs what's selecting a part within it
  <fantasai> AmeliaBR++
  TabAtkins: Yep. It's just a big jumble. There is prior art here
             inside existing browsers.
  fantasai: Can we not make it worse?
  TabAtkins: I don't think we can avoid it. If it was an actual
             combinator, we could avoid it, but we have to provide a
             name because of how the syntax works and we can't avoid
             it. We won't make it worse but we will be keeping current
             practice that we can't get around

  fremy: I am very much in favor of this. Because typing :state()
         :state() :state() is annoying. Every time you want to use
         this stuff you have to type this. I think there is a point in
         making it shorter. I did not consider the confusion between
         pseudo classes and pseudo elements. But it's not an issue
         with the naming, it's an issue in general. But for practical
         purpose, typing :state() isn't useful. And selectors already
         can be quite long.
  TabAtkins: Your point about "this isn't a question of the particular
             syntax, if we expose pseudo elements and pseudo classes
             in any syntax, there might be a collision" but this is
             general and doesn't have a bearing on this issue
  fremy: Eventually you have to learn it anyway. So I'm not sure it's
         valid .... people already have to understand what + means if
         people want to use it. + is also confusing if you don't know
         what it means. It could have been better, I'm not sure it's a
         convincing argument
  florian: As long as it's syntax based on obscure characters, people
           get confused on what's a pseudo class and pseudo element.
           But if they're named, it's harder to be confused
  TabAtkins: The confusion is partially that but it's also what
             aspects get exposed as states vs parts. There's a venn
             diagram and it's almost a circle
  florian: In your example, weekend vs second week seems to be
           obviously part of the calendar. I think you'll get more
           reliable answers from authors about the difference between
           parts vs states than pseudo elements vs pseudo classes
  TabAtkins: I don't agree with your characterization. There's
             confusion there anyway.
  TabAtkins: Part names are controlled by the component using its own
             element. It chooses what to expose and what to expose it
             as. States are exposed by the element itself. So there's
             two different products inter-operating here. The
             component itself and the thing using the component and
             exposing it up higher. And they shouldn't syntactically
             collide because that makes for upgrade issues when
             suddenly your component uses a state name that you're
             already using as a part name. As long as they're distinct
             syntactically it's fine
  fantasai: Nobody's saying they should be in the same namespace
  TabAtkins: That was the argument
  fantasai: I thought the discussion was should it be :--state or
            :part(), not whether to put them all under :--foo
  TabAtkins: There are other proposals too.
  TabAtkins: Unless we do think there is a sufficient separation
             between the two that needs to be captured by different
             names in -- vs - then we can keep the conversation on the
             current discussion about :-- vs :part()

  AmeliaBR: I mentioned with : :part() there would need to be wrappers
            still available for when you want the intersection of two
            classes. For state, is it okay to allow the state wrapper
            as optional? So you could have :state(foo) vs :--foo as
            equivalent so the stylesheet author who is using the web
            component can use the syntax that is most intuitive for
            them, regardless of the web component's design?
  <fremy> I think that's extra confusing
  TabAtkins: The issue is keeping around the :state() as a fallback
             doesn't allow anything new. You can always select on
             multiple pseudo classes by stacking them with :is(). But
             pseudo elements you can't do that. You can use "or" but
             you can't use "and" conditions. So you need syntax to do
             that. So we shouldn't have two different syntax for the
             same thing if the only reason is that some people might
             want to type parentheses

  plinss: :state(--statname)? What about :state(hover)??
  AmeliaBR: That is a fair argument.

  astearns: hober, you said would you prefer the state() syntax, but
            you didn't want to describe the reasons. Can you summarize
            the state of the discussion in the web components group?
            I'm looking through the minutes and I can't find consensus
  hober: Our positions have been made on the github issue. Some of
         that argument is aesthetic, but to go beyond that I'd have to
         catch myself up
  astearns: Is the aesthetics just "naming things is hard" or is it
            about the typographic :-- not conveying as much
            information as the word does
  hober: I think some of the aesthetic concerns about it being ugly.
         Which is not a position that is worth arguing for on this
         call. Other aspects of the concern were around matching
         ::part because these two features would be used in tandem and
         it's a bit jarring to have one of them be named and the other
         one not. There's probably more to it than that but I can't
  <fremy> to be very honest, I could also live with both options
  <fremy> I agree it's mostly down to aesthetics
  TabAtkins: That was one of the points that mjs made. For the rest of
             the thread people were riffing on mjs's points or talking
             about the aesthetics. With regard to mjs's things, there
             is active discussion on allowing custom pseudo elements
             to use the same syntax. I dropped looking at the thread
             to do other things but last time I did I put in some
             possibilities, but I don't know what happened to them. I
             think there's a path to getting them semantically similar.
  TabAtkins: Everyone thought -- was ugly in custom properties, but
             now people ... still think it's ugly, but it conveys

  plinss: Are we going to want custom pseudo classes in some other
          way? I can't think of one.
  TabAtkins: The main use case is defining general selector aliases.
             If you want :heading that selected <h1> through <h6> this
             would be easy to do in CSS, would be worthwhile... I
             would be okay with that, we can figure out something for
             this later when we need to. Pseudo classes here are more
             similar to regular pseudo classes for video, etc. In
             terms of what has the most claim to the syntax space,
             custom elements have a better claim to it. If we want
             more for things like JS, we can cross that bridge when we
             come to it

  chrishtr: I read through the issue again, and it sounds like the
            debate is mostly aesthetic or developer understandability.
            Most of the people talking seemed to indicate they have a
            similar stance to hober. I actually personally don't care
            that much, there are arguments both ways. If everyone
            feels the same way, or leaning one way, we can just take a
            straw poll and pick the one that has the most votes
  chrishtr: In interest of moving forward
  astearns: I'm not that interested in voting. We have some people
            pushing for the change and most people say "yyyyyeah
  astearns: I'm not hearing people objecting to the change or giving
            strong arguments why it should remain :state()

  fantasai: We might want more feedback from the developer community.
            The question is more on their side what's easier for them
  astearns: It's not on them, it's on us to determine how this whole
            thing will work with custom states and states on custom
            elements and making sure we have consistency.
  Rossen: Didn't TabAtkins run polls on twitter?
  TabAtkins: No. But Jan Mikovsky has been working on this. He
             initially thought :-- is ugly and weird, but he switched
             his opinion after using it because he felt it was more
             natural and CSSy. This matches my intuition

  chrishtr: astearns, were you trying to drive toward resolution?
  astearns: I was thinking we could get an _unenthusiastic_ consensus
  astearns: I'm happy to back down from that if anyone has a strong
            enough objection to making the change

  plinss: Not objection, but it became clear that many people don't
          understand what a pseudo class actually is, and that it's
          just state. People seem to think that functional notation of
          pseudo classes implies functional behavior, which is untrue.
          Rather than asking developers, we should educate developers
          about what pseudo classes are. This is just how we expose
  chrishtr: This is an argument in favor of :state()?
  plinss: No, the opposite.
  plinss: I'd rather it be :--
  <fantasai> plinss++
  plinss: I don't want state to be a weird thing for custom elements.
          I want custom elements to create pseudo classes just like
          regular elements can
  <florian> +1
  AmeliaBR: The single colon means state, rather than having an extra
            state keyword
  astearns: The syntax is difficult to teach, but if you want to avoid
            people having the impression that there's some functional
            behavior, I don't know which syntax would be better

  chrishtr: Should we try for resolution?
  astearns: Yes.
  astearns: Let's resolve to make the change from :state(foo) to
            :--foo even if people are somewhat unenthusiastic. If
            someone is really unenthusiastic they can object
  <florian> I support the proposed resolution
  fantasai: plinss's argument convinced me.
  astearns: Anyone else?

  RESOLVED: Syntax changes from :state(foo) to :--foo
Received on Friday, 15 May 2020 22:49:32 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:14 UTC