-
Notifications
You must be signed in to change notification settings - Fork 689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define "part-like pseudo-element", from #10083. #10199
Conversation
Part-Like Pseudo-Elements</h3> | ||
|
||
A subset of [=tree-abiding pseudo-elements=], | ||
the <dfn>part-like pseudo-elements</dfn>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I like this name. Can we pick something that isn't a reference to ::part()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, would love a different name, but having a problem coming up with one. Problem is coming up with something that's not just a synonym of "abiding". We could try to skirt a little farther in the "Tree-X" namespace - tree-located? tree-positioned? tree-structural?- to indicate that not only do they abide by the tree structure generally (insofar as having a parent/child relationship) but actually have a definite position in that tree (and thus know their sibling relationships too).
Or we could go further afield. Semi-real? Pseudo-real?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Tree-structural" is actually really grabbing me, given its parallel with the tree-structural pseudo-classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well ::marker
has a definite position in the tree, but you're not including it in this set of things afaict. So it's not about it's tree position, it's about the fact that generates a box that behaves exactly like any other element's generated box.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was under the impression that the reason ::marker didn't act like ::before/etc is because we specifically hadn't nailed down its exact tree position. If it does have an exact position, then what is the reasoning behind limiting it? (Besides applying a few one-offs, like disallowing it from being display: list-item
or something; that's fine for this new category of pseudos to do.)
<div class=example> | ||
For example, a [=part-like pseudo-element=] | ||
can be used in the <{html-global/exportparts}> attribute, | ||
to masquerade as a ''::part()'' | ||
for the component it's in: | ||
|
||
<xmp class=html> | ||
<template id=custom-element-template> | ||
<p exportparts="::before : preceding-text"> | ||
You can style my ::before pseudo-element | ||
by using ::part(preceding-text), too! | ||
</template> | ||
</xmp> | ||
</div> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't helping to illustrate pseudo-elements that "interact with some other platform features as if they were real elements". It's illustrating a real element acting like a pseudo-element (by being selected by one), which is kindof the opposite!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're misunderstanding the example, because it illustrates the exact opposite. ::part(preceding-text)
is selecting a pseudo-element (the p::before
pseudo).
Merging for now, we can figure out what the better term is later. |
@fantasai review?