Re: :host pseudo-class
On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's certainly no weirder, imo, than having a pseudo-element that doesn't actually live in any element's pseudo-tree, but instead just lives in the normal DOM, but can only be selected by using a pseudo-element selector with no LHS. Pseudo-elements are fucked, unfortunately, but we have to live with their quirks, and those quirks make them really bad for this particular case. Why? As was said before, pseudo-elements have to be attached to a real element. Pseudo-element selectors have a built-in combinator; they're actually complex selectors all by themselves. (This isn't properly reflected in Selectors right now; I haven't made the edits to the data model that need to happen to make pseudo-elements work properly.) But the host element isn't attached to any of the elements in its shadow tree; it's a *parent* of all of them. If we ignored this and let it attach to an element, which one? There's no single top-most element to privilege. If we attach to *all* of them, then we get the bizarre result that #foo::host #foo might actually select something. Having lots of elements share the same pseudo-element is also unprecedented currently. Pseudo-elements also, because they're complex selectors, aren't usable everywhere that other selectors are. If you have a context that only accepts simple or compound selectors (as a filter, for instance), pseudo-elements aren't available. So if we use :host, we have to invent a new concept to make it work (featureless). If we use ::host, we have to invent a new concept to make it work (new ways for pseudo-elements to exist and be targeted). I think the latter is weirder than the former. And again, from the perspective of the shadow tree, the host element is not part of its normal DOM. The shadow tree is its normal DOM. This is the same as ::-webkit-range-thumb. From the perspective of the light DOM, that element is not part of its normal DOM. But it is part of the composed DOM. And again, it depends on what level of authority you're talking about. As far as the outer page is concerned, the input element is empty, and ::webkit-range-thumb is a fictitious pseudo-element created solely by the platform. There's no real DOM underlying it, because the shadow dom is fully sealed, so anything inside of it is dead. From the platform's perspective, sure, there's a real element under there. And the platform does get special powers that the page might not have. But the fact that input is implemented with shadow DOM is an undetectable implementation detail at the moment. ~TJ
Re: :host pseudo-class
On Wed, May 6, 2015 at 4:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren ann...@annevk.nl wrote: And again, from the perspective of the shadow tree, the host element is not part of its normal DOM. The shadow tree is its normal DOM. This is the same as ::-webkit-range-thumb. From the perspective of the light DOM, that element is not part of its normal DOM. But it is part of the composed DOM. And again, it depends on what level of authority you're talking about. As far as the outer page is concerned, the input element is empty, and ::webkit-range-thumb is a fictitious pseudo-element created solely by the platform. There's no real DOM underlying it, because the shadow dom is fully sealed, so anything inside of it is dead. From the platform's perspective, sure, there's a real element under there. And the platform does get special powers that the page might not have. But the fact that input is implemented with shadow DOM is an undetectable implementation detail at the moment. A) This platform advantage will go away. Isolated shadow DOM is going to be a thing developers can play with. B) At the F2F there was lots of talk that even with custom properties, there was still a desire to support custom pseudo-elements to target actual elements in a way similar to what (mostly) WebKit/Blink offer today. -- https://annevankesteren.nl/
Re: :host pseudo-class
On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's certainly no weirder, imo, than having a pseudo-element that doesn't actually live in any element's pseudo-tree, but instead just lives in the normal DOM, but can only be selected by using a pseudo-element selector with no LHS. Pseudo-elements are fucked, unfortunately, but we have to live with their quirks, and those quirks make them really bad for this particular case. Why? And again, from the perspective of the shadow tree, the host element is not part of its normal DOM. The shadow tree is its normal DOM. This is the same as ::-webkit-range-thumb. From the perspective of the light DOM, that element is not part of its normal DOM. But it is part of the composed DOM. -- https://annevankesteren.nl/
Re: :host pseudo-class
On Mon, May 4, 2015 at 9:38 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 5, 2015 at 2:08 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren ann...@annevk.nl wrote: But maybe you're right and the whole pseudo-class/pseudo-element distinction is rather meaningless. But at least pseudo-class til date made some sense. I still don't understand what you find wrong with this. It's not that :host() [can] match an element that cannot otherwise be matched, it's that the host element element is featureless, save for the ability to match :host. (That's the definition of a featureless element - it's allowed to specify particular things that can still match it.) In other words, it's not :host that's magical, it's the host element itself that's magical. So :host:hover would not work? I guess you would have to spell that :host(:hover)? Because although it does not have features, it has features inside the parenthesis? Correct. The functional :host() pseudo-class can match the selector against the *real* host element that hosts the shadow tree (and :host-context() can do so for the entire shadow-piercing ancestor tree). But normal selectors inside a shadow tree only see the featureless version of the host element that lives inside of the shadow tree. Was this concept introduced for other scenarios or just for :host? Seems like a very weird rationalization. Yeah, it was introduced to give the host element the selection behavior we wanted (I explained this in more detail in my first post in the thread). It's certainly no weirder, imo, than having a pseudo-element that doesn't actually live in any element's pseudo-tree, but instead just lives in the normal DOM, but can only be selected by using a pseudo-element selector with no LHS. Pseudo-elements are fucked, unfortunately, but we have to live with their quirks, and those quirks make them really bad for this particular case. ~TJ
Re: :host pseudo-class
On Mon, May 4, 2015 at 9:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron dba...@dbaron.org wrote: On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. We haven't really used (in the sense of shipping across browsers) pseudo-elements before for things that are both tree-like (i.e., not ::first-letter, ::first-line, or ::selection) and not leaves of the tree. (Gecko doesn't implement any pseudo-elements that can have other selectors to their right. I'm not sure if other engines have.) I'd be a little worried about ease of implementation, and doing so without disabling a bunch of selector-related optimizations that we'd rather have. At some point we probably do want to have this sort of pseudo-element, but it's certainly adding an additional dependency on to this spec. My understanding is that the question here isn't what is being matched, but rather what syntax to use for the selector. I.e. in both cases the thing that the selector is matching is the DocumentFragment which is the root of the shadow DOM. As Anne said, no, the thing matched is the actual host element. But otherwise, yeah, we're just debating the syntax of how to select that (while obeying the constraints I outlined in my first post to this thread). If implementing :host is easier than ::host, then it seems like the implementation could always convert the pseudo-element into a pseudo-class at parse time. That should make the implementation the same other than in the parser. Though maybe the concern here is about parser complexity? It's not about parser complexity. (dbaron did use that as an argument against ::host, but I'm not making that argument; Blink's parser has no problem with it.) It's about hitting the (admittedly complex) constraints sanely within the existing Selectors model. ~TJ
Re: :host pseudo-class
On Tue, May 5, 2015 at 2:08 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren ann...@annevk.nl wrote: But maybe you're right and the whole pseudo-class/pseudo-element distinction is rather meaningless. But at least pseudo-class til date made some sense. I still don't understand what you find wrong with this. It's not that :host() [can] match an element that cannot otherwise be matched, it's that the host element element is featureless, save for the ability to match :host. (That's the definition of a featureless element - it's allowed to specify particular things that can still match it.) In other words, it's not :host that's magical, it's the host element itself that's magical. So :host:hover would not work? I guess you would have to spell that :host(:hover)? Because although it does not have features, it has features inside the parenthesis? Was this concept introduced for other scenarios or just for :host? Seems like a very weird rationalization. -- https://annevankesteren.nl/
Re: :host pseudo-class
On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron dba...@dbaron.org wrote: On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. We haven't really used (in the sense of shipping across browsers) pseudo-elements before for things that are both tree-like (i.e., not ::first-letter, ::first-line, or ::selection) and not leaves of the tree. (Gecko doesn't implement any pseudo-elements that can have other selectors to their right. I'm not sure if other engines have.) I'd be a little worried about ease of implementation, and doing so without disabling a bunch of selector-related optimizations that we'd rather have. At some point we probably do want to have this sort of pseudo-element, but it's certainly adding an additional dependency on to this spec. My understanding is that the question here isn't what is being matched, but rather what syntax to use for the selector. I.e. in both cases the thing that the selector is matching is the DocumentFragment which is the root of the shadow DOM. If implementing :host is easier than ::host, then it seems like the implementation could always convert the pseudo-element into a pseudo-class at parse time. That should make the implementation the same other than in the parser. Though maybe the concern here is about parser complexity? / Jonas
Re: :host pseudo-class
On Tue, May 5, 2015 at 6:52 AM, Jonas Sicking jo...@sicking.cc wrote: My understanding is that the question here isn't what is being matched, but rather what syntax to use for the selector. I.e. in both cases the thing that the selector is matching is the DocumentFragment which is the root of the shadow DOM. No, :host matches the host element in the light tree that holds the shadow tree. -- https://annevankesteren.nl/
Re: :host pseudo-class
On Thu, Apr 30, 2015 at 10:51 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn espr...@chromium.org wrote:
That's still true if you use ::host, what is the thing on the left hand side
the ::host lives on? I'm not aware of any pseudo element that's not
connected to another element such that you couldn't write {thing}::pseudo.
::selection?
::selection has a host element. If you use it by itself it just means
you're selecting *::selection.
But maybe you're right and the whole
pseudo-class/pseudo-element distinction is rather meaningless. But at
least pseudo-class til date made some sense.
I still don't understand what you find wrong with this. It's not that
:host() [can] match an element that cannot otherwise be matched,
it's that the host element element is featureless, save for the
ability to match :host. (That's the definition of a featureless
element - it's allowed to specify particular things that can still
match it.) In other words, it's not :host that's magical, it's the
host element itself that's magical.
~TJ
Re: :host pseudo-class
On Thu, Apr 30, 2015 at 10:25 PM, Anne van Kesteren ann...@annevk.nl
wrote:
...
My problem is not with the ability to address the host element, but by
addressing it through a pseudo-class, which has so far only been used
for matching elements in the tree that have a particular internal
slot.
I don't understand what distinction you're trying to draw here. Can
you elaborate?
A pseudo-class selector is like a class selector. You match an element
based on a particular trait it has. Your suggestion for :host()
however is to make it match an element that cannot otherwise be
matched. That's vastly different semantics
That's still true if you use ::host, what is the thing on the left hand
side the ::host lives on? I'm not aware of any pseudo element that's not
connected to another element such that you couldn't write {thing}::pseudo.
- E
Re: :host pseudo-class
On Fri, May 1, 2015 at 2:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Pseudo-elements are things that aren't DOM elements, but are created by Selectors for the purpose of CSS to act like elements. That's not true for e.g. ::-webkit-slider-thumb as I already indicated. Sure it is. input type=range has no children, and the shadow tree is sealed, so the fact that a shadow tree even exists is hidden from DOM. As far as CSS is capable of discerning, there is no thumb element, so the pseudo-element makes sense. That seems rather arbitrary. To the browser it is a DOM element and to CSS it is too. E.g. at the global level CSS will have to reason about what it means to override the element's existing styles. My problem is not with the ability to address the host element, but by addressing it through a pseudo-class, which has so far only been used for matching elements in the tree that have a particular internal slot. I don't understand what distinction you're trying to draw here. Can you elaborate? A pseudo-class selector is like a class selector. You match an element based on a particular trait it has. Your suggestion for :host() however is to make it match an element that cannot otherwise be matched. That's vastly different semantics -- https://annevankesteren.nl/
Re: :host pseudo-class
On Fri, May 1, 2015 at 7:39 AM, Elliott Sprehn espr...@chromium.org wrote:
That's still true if you use ::host, what is the thing on the left hand side
the ::host lives on? I'm not aware of any pseudo element that's not
connected to another element such that you couldn't write {thing}::pseudo.
::selection? But maybe you're right and the whole
pseudo-class/pseudo-element distinction is rather meaningless. But at
least pseudo-class til date made some sense.
--
https://annevankesteren.nl/
Re: :host pseudo-class
On Thu, Apr 30, 2015 at 2:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Pseudo-elements are things that aren't DOM elements, but are created by Selectors for the purpose of CSS to act like elements. That's not true for e.g. ::-webkit-slider-thumb as I already indicated. Sure it is. input type=range has no children, and the shadow tree is sealed, so the fact that a shadow tree even exists is hidden from DOM. As far as CSS is capable of discerning, there is no thumb element, so the pseudo-element makes sense. The host element is a real DOM element. It just has special selection behavior from inside its own shadow root, for practical reasons: there are good use-cases for being able to style your host, but also a lot for *not* doing so, and so mixing the host into the normal set of elements leads to a large risk of accidentally selecting the host. This is particularly true for things like class selectors; since the *user* of the component is the one that controls what classes/etc are set on the host element, it's very plausible that a class used inside the shadow root for internal purposes could accidentally collide with one used by the outer page for something completely different, and cause unintentional styling issues. Making the host element present in the shadow tree, but featureless save for the :host and :host-context() pseudo-classes, was the compromise that satisfies all of the use-cases adequately. My problem is not with the ability to address the host element, but by addressing it through a pseudo-class, which has so far only been used for matching elements in the tree that have a particular internal slot. I don't understand what distinction you're trying to draw here. Can you elaborate? It's possible we could change how we define the concept of pseudo-element so that it can sometimes refer to real elements that just aren't ordinarily accessible, but I'm not sure that's necessary or desirable at the moment. Well, it would for instance open up the possibility of using :host in the light tree to match elements that are host elements. That's just a naming-collision thing. We can come up with a different name for either has a shadow tree or is the host element of the current shadow tree; it's just that right now, the latter has claimed the name :host. I certainly don't want to create both a pseudo-class and pseudo-element with the same name if I can help it (or at least, not ones that refer to similar things); the distinction between pseudo-classes and pseudo-elements in most author's minds is already tenuous. (Definitely not helped by the legacy :before/etc syntax.) ~TJ
Re: :host pseudo-class
On Mon, Apr 27, 2015 at 9:03 AM, Rune Lillesveen r...@opera.com wrote:
On Mon, Apr 27, 2015 at 6:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
Would they match against elements in the host's tree or the shadow
tree? I don't see anything in the specification about this.
They would match elements in the shadow tree.
A typical use case is to style elements in the shadow tree based on
its host's attributes:
my-custom-element disabled
custom-child/custom-child
/my-custom-element
In the shadow tree for my-custom-element:
style
:host([disabled]) ::content custom-child { color: #444 }
:host([disabled]) input { border-color: #ccc }
/style
content/content
input type=text
Thanks, that example has another confusing bit, ::content. As far as I
can tell ::content is not actually an element that ends up in the
tree. It would make more sense for that to be a named-combinator of
sorts. (And given ::content allowing selectors on the right hand, it's
now yet more unclear why :host is not ::host.)
--
https://annevankesteren.nl/
Re: :host pseudo-class
On Sat, Apr 25, 2015 at 9:32 AM, Anne van Kesteren ann...@annevk.nl wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. Pseudo-elements are things that aren't DOM elements, but are created by Selectors for the purpose of CSS to act like elements. The host element is a real DOM element. It just has special selection behavior from inside its own shadow root, for practical reasons: there are good use-cases for being able to style your host, but also a lot for *not* doing so, and so mixing the host into the normal set of elements leads to a large risk of accidentally selecting the host. This is particularly true for things like class selectors; since the *user* of the component is the one that controls what classes/etc are set on the host element, it's very plausible that a class used inside the shadow root for internal purposes could accidentally collide with one used by the outer page for something completely different, and cause unintentional styling issues. Making the host element present in the shadow tree, but featureless save for the :host and :host-context() pseudo-classes, was the compromise that satisfies all of the use-cases adequately. It's possible we could change how we define the concept of pseudo-element so that it can sometimes refer to real elements that just aren't ordinarily accessible, but I'm not sure that's necessary or desirable at the moment. On Sun, Apr 26, 2015 at 8:37 PM, L. David Baron dba...@dbaron.org wrote: We haven't really used (in the sense of shipping across browsers) pseudo-elements before for things that are both tree-like (i.e., not ::first-letter, ::first-line, or ::selection) and not leaves of the tree. (Gecko doesn't implement any pseudo-elements that can have other selectors to their right. I'm not sure if other engines have.) I'd be a little worried about ease of implementation, and doing so without disabling a bunch of selector-related optimizations that we'd rather have. At some point we probably do want to have this sort of pseudo-element, but it's certainly adding an additional dependency on to this spec. The ::shadow and ::content pseudo-elements are this way (tree-like, and not leaves). We implement them in Blink currently, at least to some extent. (Not sure if it's just selector tricks, or if we do it properly so that, for example, inheritance works.) On Mon, Apr 27, 2015 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote: Thanks, that example has another confusing bit, ::content. As far as I can tell ::content is not actually an element that ends up in the tree. It would make more sense for that to be a named-combinator of sorts. (And given ::content allowing selectors on the right hand, it's now yet more unclear why :host is not ::host.) It's a (pseudo-)element in the tree, it's just required to not generate a box. Having ::content (and ::shadow) be pseudo-elements lets you do a few useful things: you can use other combinators (child *or* descendant, depending on what you need) and you can set inherited properties to cascade down to all the children (especially useful for, for example, setting 'color' of direct text node children, which can appear in a shadow root or in a content with no select='', and can't be targeted by a selector otherwise). I did originally use combinators for this, but they're less useful for the reasons just listed. (This was explicitly discussed in a telcon, when I noted that sometimes you want to select the top-level things in a shadow tree or distribution list, and sometimes all the things. I had proposed two versions of each combinator, or an argument to a named combinator (like /shadow / versus /shadow /), but someone else (I think it was fantasai?) suggested using a pseudo-element instead, and it turned out to be a pretty good suggestion.) ~TJ
Re: :host pseudo-class
On Mon, Apr 27, 2015 at 6:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Apr 27, 2015 at 5:56 AM, L. David Baron dba...@dbaron.org wrote:
For :host it's less interesting, but I thought a major use of
:host() and :host-context() is to be able to write selectors that
have combinators to the right of :host() or :host-context().
Would they match against elements in the host's tree or the shadow
tree? I don't see anything in the specification about this.
They would match elements in the shadow tree.
A typical use case is to style elements in the shadow tree based on
its host's attributes:
my-custom-element disabled
custom-child/custom-child
/my-custom-element
In the shadow tree for my-custom-element:
style
:host([disabled]) ::content custom-child { color: #444 }
:host([disabled]) input { border-color: #ccc }
/style
content/content
input type=text
--
Rune Lillesveen
Re: :host pseudo-class
I think using ::host pseudo element can avoid this kind of *controversial* discussion and we can get benefits from that. +1 for ::host pseudo element. On Sun, Apr 26, 2015 at 4:02 AM Daniel Tan li...@novalistic.com wrote: On 4/26/2015 12:32 AM, Anne van Kesteren wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. My guess is it's because a shadow host element is an element, not a pseudo-element. The reason * doesn't match :host is because the host element, in the context of its shadow tree, is featureless, as mentioned in [1]section 3.1.1 of css-scoping and [2]section 3.3 of selectors-4. Does the following note in css-scoping 3.1.1 answer your question? Why is the shadow host so weird? The shadow host lives outside the shadow tree, and its markup is in control of the page author, not the component author. It would not be very good if a component used a particular class name internally in a shadow tree, and the page author using the component accidentally also used the the same class name and put it on the host element. Such a situation would result in accidental styling that is impossible for the component author to predict, and confusing for the page author to debug. However, there are still some reasonable use-cases for letting a stylesheet in a shadow tree style its host element. So, to allow this situation but prevent accidental styling, the host element appears but is completely featureless and unselectable except through :host. [1]: http://dev.w3.org/csswg/css-scoping-1/#host-element-in-tree [2]: http://dev.w3.org/csswg/selectors-4/#data-model -- Daniel Tan NOVALISTIC http://NOVALISTIC.com
Re: :host pseudo-class
On Mon, Apr 27, 2015 at 5:56 AM, L. David Baron dba...@dbaron.org wrote: For :host it's less interesting, but I thought a major use of :host() and :host-context() is to be able to write selectors that have combinators to the right of :host() or :host-context(). Would they match against elements in the host's tree or the shadow tree? I don't see anything in the specification about this. And I tend to think :host, :host(), and :host-context() should probably agree on whether to be pseudo-classes or pseudo-elements. Agreed. Another reason why I think it should be a pseudo-element is that :host would make for a suitable pseudo-class to select host elements in a tree (elements that have an associated shadow root). That is, :host makes sense within the light tree, and ::host makes sense within the shadow tree. And given that a shadow tree can also be simultaneously a light tree due to nesting, we don't want to conflate the two. -- https://annevankesteren.nl/
Re: :host pseudo-class
On Sat, Apr 25, 2015 at 8:59 PM, Daniel Tan li...@novalistic.com wrote: My guess is it's because a shadow host element is an element, not a pseudo-element. I think a pseudo-element makes more sense as it represents an element/box not accessible within the tree, whereas a pseudo-class represents an element/box with an internal flag set accessible within the tree. Potentially we could have a new kind of selector representing an actual element not accessible within the tree, but browser vendors by and large have decided to use pseudo-elements, e.g. ::-webkit-slider-thumb. Does the following note in css-scoping 3.1.1 answer your question? No. -- https://annevankesteren.nl/
Re: :host pseudo-class
On Saturday 2015-04-25 09:32 -0700, Anne van Kesteren wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. We haven't really used (in the sense of shipping across browsers) pseudo-elements before for things that are both tree-like (i.e., not ::first-letter, ::first-line, or ::selection) and not leaves of the tree. (Gecko doesn't implement any pseudo-elements that can have other selectors to their right. I'm not sure if other engines have.) I'd be a little worried about ease of implementation, and doing so without disabling a bunch of selector-related optimizations that we'd rather have. At some point we probably do want to have this sort of pseudo-element, but it's certainly adding an additional dependency on to this spec. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature
Re: :host pseudo-class
On Mon, Apr 27, 2015 at 5:37 AM, L. David Baron dba...@dbaron.org wrote: We haven't really used (in the sense of shipping across browsers) pseudo-elements before for things that are both tree-like (i.e., not ::first-letter, ::first-line, or ::selection) and not leaves of the tree. (Gecko doesn't implement any pseudo-elements that can have other selectors to their right. I'm not sure if other engines have.) I'd be a little worried about ease of implementation, and doing so without disabling a bunch of selector-related optimizations that we'd rather have. At some point we probably do want to have this sort of pseudo-element, but it's certainly adding an additional dependency on to this spec. Are you saying :host accepts selectors to its right and they would potentially result in a match? Even if that were the case it's still unclear to me how a pseudo-class is justified. Or are you saying the concept of a host element selector is problematic in general? -- https://annevankesteren.nl/
Re: :host pseudo-class
On Monday 2015-04-27 05:49 +0200, Anne van Kesteren wrote: On Mon, Apr 27, 2015 at 5:37 AM, L. David Baron dba...@dbaron.org wrote: We haven't really used (in the sense of shipping across browsers) pseudo-elements before for things that are both tree-like (i.e., not ::first-letter, ::first-line, or ::selection) and not leaves of the tree. (Gecko doesn't implement any pseudo-elements that can have other selectors to their right. I'm not sure if other engines have.) I'd be a little worried about ease of implementation, and doing so without disabling a bunch of selector-related optimizations that we'd rather have. At some point we probably do want to have this sort of pseudo-element, but it's certainly adding an additional dependency on to this spec. Are you saying :host accepts selectors to its right and they would potentially result in a match? Yes. For :host it's less interesting, but I thought a major use of :host() and :host-context() is to be able to write selectors that have combinators to the right of :host() or :host-context(). And I tend to think :host, :host(), and :host-context() should probably agree on whether to be pseudo-classes or pseudo-elements. Even if that were the case it's still unclear to me how a pseudo-class is justified. Or are you saying the concept of a host element selector is problematic in general? No. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature
Re: :host pseudo-class
On 4/26/2015 12:32 AM, Anne van Kesteren wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. My guess is it's because a shadow host element is an element, not a pseudo-element. The reason * doesn't match :host is because the host element, in the context of its shadow tree, is featureless, as mentioned in [1]section 3.1.1 of css-scoping and [2]section 3.3 of selectors-4. Does the following note in css-scoping 3.1.1 answer your question? Why is the shadow host so weird? The shadow host lives outside the shadow tree, and its markup is in control of the page author, not the component author. It would not be very good if a component used a particular class name internally in a shadow tree, and the page author using the component accidentally also used the the same class name and put it on the host element. Such a situation would result in accidental styling that is impossible for the component author to predict, and confusing for the page author to debug. However, there are still some reasonable use-cases for letting a stylesheet in a shadow tree style its host element. So, to allow this situation but prevent accidental styling, the host element appears but is completely featureless and unselectable except through :host. [1]: http://dev.w3.org/csswg/css-scoping-1/#host-element-in-tree [2]: http://dev.w3.org/csswg/selectors-4/#data-model -- Daniel Tan NOVALISTIC http://NOVALISTIC.com
:host pseudo-class
I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. -- https://annevankesteren.nl/
