- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 15 May 2020 18:48:47 -0400
- 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)
===== FULL MINUTES BELOW ======
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
:--stuff?
<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
classes
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
author.
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
remember
<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
meaning
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
okay...."
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
state.
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