=========================================
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 Breakout
===================
- Issue #12158 (Add a property to the `CSSPseudoElement` IDL
interface to determine if a pseudo element "exists") will return
to the github issue to define per element and answer some
questions raised on the call.
- RESOLVED: For a valid selector we will always return the
CSSPseudoElement object (Issue #12159: What should `pseudo
(type)` return for elements that can't have pseudo
elements?)
- Issue #12160 (Should non-tree-abiding pseudo elements have a
separate IDL interface?) requires further thought about event
listeners so will return to the issue.
- Issue #12163 (How to handle addEventListener on
`CSSPseudoElement`?) will be brought up at the joint meeting with
WHATWG to get additional input.
- There was general agreement to have a separate property that
returns the full string for issue #12161 (Add a property to the
`CSSPseudoElement` IDL interface to retrieve pseudo argument(s))
however there wasn't enough time left on the call to agree on
details and reach a resolution.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jun/0015.html
Present:
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Justin Breiland
Oriol Brufau
Stephen Chenney
Yehonatan Daniv
Elika Etemad
Robert Flack
Cassondra Roberts
Daniil Sakhapov
Alan Stearns
Scribe: ydaniv
CSS Pseudo Breakout
===================
Add a property to the `CSSPseudoElement` IDL interface to determine
if a pseudo element "exists"
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12158
sakhapov: want to discuss pseudo-element interface to use it from JS
sakhapov: element.pseudo, if object is valid the the pseudo is used
sakhapov: has several props like using identity for event delegation
sakhapov: ability to distinguish if element is rendered or exists
sakhapov: add property exists per element
sakhapov: is add property per element defined and supported
oriol: not sure if this make sense for some elements
oriol: whether this interface would be able to work for any element,
or just tree-abiding ones
oriol: not sure whether it's well defined
oriol: also whether if there's a generated box for this element
oriol: you only want to check whether it exists or not
oriol: also has perf concerns, to check if has generated boxes
oriol: so makes sense to add extra APIs for these
sakhapov: for now defined only for 4-5 elements
sakhapov: we can later defined for other elements, and having same
interface for element and pseudo
sakhapov: each pseudo is unique and different, so makes sense to
define per element, and later generalize
oriol: so makes sense to define per element if box exists or
something different
sakhapov: yes, for example for :column
flackr: I think Daniil covered all my points, part of goal here to
define the exists and can be different, like whether
selection exists
flackr: part of it is defined whether exists, because if has box is
different
sakhapov: gCS for highlight pseudos it returns styles as if active,
so not same as box is present
dbaron: I think this seems reasonable, agree we define existence per
element
dbaron: for customizable select we defined specific mechanism, my
intuition is that it should return true only if has select on
element, .... <missed>
<TabAtkins> Big +1 to dbaron (and I think I feel a bit more strongly
about it)
<dbaron> questions: 1. whether ::checkmark existing depends on
whether the <select> has appearance:base-select
<dbaron> 2. whether ::checkmark existing depends on whether the popup
is open
<dbaron> 3. (from alan?) whether ::checkmark existing depends on
whether the option is currently checked
<dbaron> (I think yes to 1 but not to 2 and 3, but we probably need
to define the underlying principles.)
<fantasai> Definitely no dependency on #3 -- ::checkmark is intended
to be available for styling iconography in the unchecked
state as well.
schenney: for many pseudos it should return whether active or not has
also privacy concerns, so we return regardless same style
schenney: also currently defined 4 pseudos available, and we can
define for each case
schenney: we can punt on the rest later
astearns: a little concerned about having this single member mean
different things for different pseudos and whether has a
single true on false for different cases
astearns: sometimes you want to tell whether there's a box, so I
think we should take this back to the issue
astearns: define what this might mean per element or whether we can
define something general
flackr: should define whether something is defined for this check and
whether needs better definition, we should be talking about
actual use-cases
<kbabbitt> +1 to flackr
<fantasai> +1 flackr
<schenney> +1
astearns: any comments
astearns: taking it back to the issue and define per element and get
a clear picture first
sakhapov: sounds good
What should `pseudo(type)` return for elements that can't have
pseudo elements?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12159
sakhapov: this one is about entry point element.pseudo which always
returns element if selector is valid
sakhapov: for example input element can not generate pseudos, so
question what to return in this case
sakhapov: false or otherwise
sakhapov: no preference here, looking for ideas
flackr: one clarification, if selector is invalid, does it throw?
sakhapov: I think we return null
flackr: I think in other APIs we throw, so should consider changing
flackr: I think if the pseudo could conditionally exist then should
be good to return an interface of whether it exists
flackr: might be other cases where existence could change
sakhapov: if wanna add scroll event listeners to scroll-marker then
enter a loop and just request scroll-marker on every
element, and then exceptions would look ugly
flackr: if the selector that you wrote is never valid we should throw
sakhapov: question if we should throw on before/after
flackr: in that case condition can't change
kbabbitt: just thinking on Rob's point, gets weird in some cases, for
example with checkboxes, can change the state and get
different pseudo, kind of weird
sakhapov: in this scenario defined to always return
sakhapov: we can discuss back in the issue
TabAtkins: on Rob's point, the condition of existence, isn't
necessarily a static thing, like password reveal icon
TabAtkins: definitely don't want a throw to happen
TabAtkins: I think "knowing" is definitely helpful
flackr: was only advocating to cases to throw if not valid
<flackr> similar to element.animate:
https://www.w3.org/TR/web-animations-1/#dom-keyframeeffect-pseudoelement
TabAtkins: ok
<kbabbitt> I think querySelector throws on an invalid selector also
sakhapov: for now returns null when not valid
TabAtkins: if at all possible throwing on non-valid stuff is ideal
TabAtkins: there's a chance it's not web compat
TabAtkins: but should be silent if valid but not getting anything
right now
sakhapov: but then in cases you get null and change type of element
then you once again call for same pseudo, but then you
query again you get an element
sakhapov: is that stable?
TabAtkins: if your input goes to password and back, if you queried on
all states you get the first option first and last should
be same
TabAtkins: if you change an input from password, to text, then back
to password, and ask for a password-reveal pseudo-element
all three states, you should get the same object back on
the first and third calls, ideally (despite getting null
on the second call)
TabAtkins: And that should be addressable with `[SameObject]` and
some prose, I think
kbabbitt: kind of related, for password control, grab a pseudo
element for that, and then change input type to text where
pseudo doesn't exist, and query, not clear what behavior
should be
TabAtkins: I'd assume that when they don't exist it would reveal the
change via the "exists" boolean
kbabbitt: in that case, does the null return makes sense? how is it
different than returning object and checking for existence?
TabAtkins: if you know at time of call it doesn't exist returning
something that may change is bad design
TabAtkins: I think in common case if you're not changing things
around, it's more useful to get no result back if doesn't
exist at the moment
kbabbitt: going to previous issue should be good to have use-cases
flackr: I feel I'm on the other side, there's a pref cost on checking
for existence, having event listeners and style resolution
flackr: we'd like developers to be able to set stuff up if they're
not in the document
astearns: Rob convinced me
<TabAtkins> +1 to resolve on always returning a pseudoelement, yeah
proposed: for a valid selector we will always return the
CSSPseudoSelector object
<sakhapov> CSSPseudoElement object
proposed: for a valid selector we will always return the
CSSPseudoElement object
astearns: objections?
RESOLVED: for a valid selector we will always return the
CSSPseudoElement object
Should non-tree-abiding pseudo elements have a separate IDL interface?
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12160
scribe: TabAtkins
sakhapov: This issue is just about what we return for non-tree
abiding pseudos.
sakhapov: they might need a different type, not inherited from
eventtarget, because they don't actually fit into the
bubbling model
flackr: in the issue I said highlightsFromPoint isn't a great API, we
wanted an event listener on the highlight pseudo
flackr: so I'd prefer, as much as possible, to have the same interface
flackr: only thing I'd say is that if we start exposing the tree
structure of tree-abiding pseudos, we'd say that non-tree
abiding don't have children
flackr: but for event listeners, I think it still makes sense
sakhapov: I wrote that these can't always be in the bubbling model,
but can you elaborate on your case?
flackr: the highlightsFromPoint api handles clicks on a highlight.
but the way to do that right now is to add a click event
listener on an ancestor and then querying which highlights
were clicked.
flackr: a better model is to add an event listener to the highlight
pseudo. we'd have to figure out the event dispatch, but we
could figure it out
flackr: so devs would just be directly notified that you've clicked
on a highlight pseudo
fantasai: interesting question here, which we get to on other issues,
is what is the identity of the highlight pseudo? is it the
one the author needs it to be?
fantasai: there's kinda three different concepts, maybe four
fantasai: example, suppose I want to represent spelling errors. three
different misspelled words. one in the first, one in the
second, third is partly bolded.
fantasai: when I select ::spelling-error, I'm selecting all of these
fantasai: but I get all of them because I wrote p::spelling-error, on
two different p, and a b::spelling-error that is the bolded
part of the third word
fantasai: from the author's perspective there are three misspelled
words, but there are more than three pieces here
fantasai: from our perspective, the bolded and non-bolded are two
different pseudos
fantasai: so the author might be interested in different things. the
entire set, each individual range, or the pieces associated
with a single element
fantasai: we're interested in the pieces associated with an element,
because it's what we style
fantasai: from a css perspective, the two halves of the semi-bolded
word are two different pseudos, two different boxes, styled
separately
fantasai: but the author isn't thinking about that, they're probably
seeing three spelling errors
fantasai: I don't know we have the model that gets authors what they
want to identify
fantasai: we'll have to build up that model before we can attach
event listeners to it
flackr: I haven't thought about addEventListener side yet, but on
dispatch side, the event target would be the specific element
that you clicked on, with the pseudoElement property pointed
at the pseudo you actually clicked on
flackr: I don't want to derail things. some things will never make
sense on tree-abiding pseudos ever, but aspirationally we'll
want to support event listening. better than a polling model,
which is what's needed today
fantasai: yeah won't dispute that, it'll just be complicated to
figure out
flackr: yeah, so maybe have event listeners on non-tree-abiding on
hold until we figure it out. maybe that'll eventually mean
separate interfaces.
astearns: even if we never have a way to add events, even if we have
the same interface we could have the APIs return null or
error?
flackr: you'd just notice you never get an event from it. but we
could also error, yeah.
fantasai: do we have an OM interface representing highlight pseudos
yet?
fantasai: because it's not just event handling that they want it for.
anything you want to do with it, these questions come up
astearns: let's take this back to the issue
How to handle addEventListener on `CSSPseudoElement`?
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12163
sakhapov: so PseudoElement inherits from EventTarget
sakhapov: how do we represent this, without webcompat problems
sakhapov: proposal is to add pseudoElementTarget and
currentPseudoElementTarget, similar to target and
currentTarget. Will have to discuss this with DOM folks as
well, but wanted opinions here first
flackr: sounds good
<TabAtkins> Yeah, I think this is what we need, can't set .target to
a PseudoElement without breaking code
sakhapov: anne pointed out it might be a layering violation
flackr: I think the point is just that the html spec needs to call
into the css pseudo spec to set up this property on the event
sakhapov: okay, if no one objects I'll propose this at the WHATNOT
html meeting
fantasai: Anne says he wants more time to consider flackr's idea,
also wants to hear from smaug from Mozilla since he's been
involved with events for a long time
astearns: I think taking this to HTML is the right next step, to get
feedback there as well
astearns: we have a joint meeting with whatwg every other Thursday
sakhapov: sounds good
Add a property to the `CSSPseudoElement` IDL interface to retrieve
pseudo argument(s)
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12161
sakhapov: some pseudo-elements can have an argument, should we return
name and arguments as one string, or separately?
sakhapov: right now CSSPseudoElement.type returns the name
sakhapov: I think it makes sense to have arguments separately, so
authors don't have to parse a string
sakhapov: haven't thought too much about use-cases yet, but as a
future proofing
flackr: there's something nice about .type, or some property,
returning the thing you passed in. so maybe .type still
returns what you passed in, and we have .name/.arguments
as new
sakhapov: do you think name/arguments/name+arguments is too much?
flackr: don't think it's too much
astearns: if you have them separately you can reconstruct the combined
fantasai: I think splitting them out is good, it makes it easy to
identify classes of pseudos. matches elements too, the
tagname and attributes are separate
fantasai: but I can also see wanting back what you passed, note that
what you get back out will probably be re-serialized in a
normalized form anyway
flackr: I do think normalization is good, but I'd like to be able to
pass the string into the .pseudo() method and get back the
same thing
flackr: also concerned about complex pseudos, like in VT there's a
whole tree. don't have anywhere to represent that if you just
have a "view-transition-image()" pseudo
astearns: running close on time, hearing agreement that arguments
should be separate at least. suggesting resolving on a
separate property, details TBD?
sakhapov: we can also wait for use-cases
astearns: so could leave as-is, with the *intent* to add a separate
property if needed
astearns: so let's do that.
flackr: also not against renaming .type
flackr: but I do think we should have *something* that returns the
full string
fantasai: I agree that makes sense, but do think .type should be the
"type" of the pseudo-element, not its full arguments
fantasai: so my suggestion is .type doesn't return the params, we add
another attribute that gets you the whole thing
astearns: we're out of time, take back to the issue
Received on Wednesday, 25 June 2025 23:13:39 UTC
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4