Webcomponents: [Shadow]: rename <content> to <slot> (bugzilla: 28561)

[hayatoito]

Title: [Shadow]: rename to (bugzilla: 28561)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28561

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28561#c0
_Anne_ wrote on 2015-04-27 05:30:45 +0000.

Since we successfully managed to avoid bikeshedding at the meeting... I think makes more sense, especially with an API. "Distributing nodes into slots".

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28561#c1
_Justin Fagnani_ wrote on 2015-04-27 07:04:07 +0000.

I'm honestly not sure that makes more sense than . It's not just any nodes that can be redistributed - it must be children of the host, so makes sense here to me. is where all or some of the hosts content goes.

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28561#c2
_Travis Leithead [MSFT]_ wrote on 2015-04-27 20:00:34 +0000.

Slot does seem pretty generic... like . Can't say I'm behind the new name idea either.

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28561#c3
_Hayato Ito_ wrote on 2015-04-30 10:42:34 +0000.

This might be bikeshed. :)

Can we defer the decision until the upcoming Imperative APIs proposal?
I hope the situation will be more clear after that.

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28561#c4
_Anne_ wrote on 2015-04-30 11:31:03 +0000.

Sure, I don't feel strongly about this. Dimitri came up with this and I liked it since it was a somewhat shorter and clearer name.

To reply to Justin, it's the host element's content that is distributed. But it's not distributed into content... Rather, it's content distributed into slots based on (most likely) a Turing complete set of rules.

---

comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28561#c5
_Hayato Ito_ wrote on 2015-04-30 12:47:59 +0000.

If I were allowed to write the spec from the scratch, I prefer "slot" to "content" because the name of "slot" is more intuitive than insertion points to me.

However, I am not sure this kind of renaming is really worth doing only because we find a better name.

I'd like to defer this, given we have more high priority tasks.

---

comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28561#c6
_Anne_ wrote on 2015-04-30 12:53:15 +0000.

Okay, let's wait for the imperative API. Because if we change that, we can change this too.

[wilsonpage]

Does this mean ::content will change to ::slot?

[hayatoito]

I guess there is no intention for that. We can file a new bug if we prefer ::slot to ::content.

[wilsonpage]

Without a <content> tag ::content pseudo selector no longer makes as much sense.

[hayatoito]

::content can be used for insertion points in general. It makes sense, doesn't it?
In fact, ::content could be used for both <content> and <shadow> at the era of 'multiple shadow roots'.

[rniwa]

Note I don't have a strong preference on the name of the element into which nodes are distributed.

However, given the current consensus is _not_ to have multiple shadow roots at least in v1, I don't think it makes sense to keep the name ::content if we're renaming <content> to <slot> just in case we all happen to agree on adding back <content> and <shadow> since some vendors, such as us (Apple), vocally opposed to that.

[annevk]

Yeah, we should rename ::content too if we rename <content>. And I think we should rename both.

[hayatoito]

The point is ::slot is not a good name here. That's a confusing name for the purpose of ::content.
::slot is likely to make developers have a wrong impression that ::slot is used for selecting slot elements which are assigned to this slot, rather than selecting distributed nodes which are distributed to this slot.
Do you want ::slot to select distributed nodes? I don't think so.

One idea, we might have both:

• A. ::slot - used for selecting slots which are assigned to this slot. I am not sure there is a use case for that.
• B. ::distributed - which has the same behavior of the current ::content. Actually, ::distributed was the former name for ::content.

IMO, renaming to ::distributed is much better than renaming to ::slot because it is less confusing for the purpose of B. We might want to reserve ::slot for the purpose of A.

[rniwa]

I don't think we should use a completely different name like ::distributed. You might be well versed with all the terms in web components but a typical Web developer already has to deal with terms like shadow DOM and slots. Introducing yet another arbitrary term like _distribution_ is only doing disservice to the developer ergonomics. In general, our industry is _completely insane_ for making up all these words. We need to stop doing that.

Having said that, the only name I can think of will be ::slot-content if ::slot is confusing.

[dglazkov]

Agreed on terrible naming history, would love to do better. How about ::slotted?

[hayatoito]

I am not saying that we have to rename ::content to ::distributed.
I am saying ::distributed is better than ::slot, _relatively_. ::content is still better than ::distributed and ::slot-content.
I think ::slot-content is just redundant. I want to write slot::content rather than slot::slot-content.

What problems are you trying to solve by renaming ::content to ::slot-content?

Anyway, now I think everyone can understand why ::slot is not a good name here, as I pointed out in the previous comment, this kind of renaming is a low priority task for me. I hope the discussion would settle down with a reasonable result, including the possibility of 'no renaming'.

I think everyone doesn't like a renaming again and again. :(

[rniwa]

I disagree. ::content is a _horribly_ vague. Everything in a HTML/XML document is content. ::slotted sounds best among what's been proposed so far although ::inserted and ::placed may also work.

[hayatoito]

If you are still interested in renaming, could you file a bug for CSS Scoping, http://dev.w3.org/csswg/css-scoping/ ?
The Shadow DOM spec doesn't define it.

[rniwa]

If that's your final response, why didn't you just say that at the beginning instead of making comments about how ::content would be just fine? I find it extremely frustrating for the whole discussion to be debunked like that.

Now, the said spec, in fact, has issue 6 which states "::content is a confusingly general name for something that is specific to the projected content of a shadow tree" so we should be renaming this pseudo element even if we kept content as the element name, which we aren't doing anymore.

[hayatoito]

It would be reasonable to continue the discussion in the right place if we expect that the discussion would become long. I'm not a fan of continuing the discussion in the wrong place because the relevant people don't notice the discussion. In this case, you might want to know Tab Atkins' opinion, the editor of CSS Scoping.

[annevk]

Hey @tabatkins, what's the best place to discuss renaming ::content?

[tabatkins]

www-style, but I'm not sure how all this works - in particular, I don't understand how ::slotted or any similar name is appropriate. That sounds like a pseudo-class that applies to the elements distributed to a slot. Have y'all changed the _behavior_ of <content>/<slot> in any significant way?

[annevk]

Yeah, so I don't see how ::slot is actually a bad name given the description in http://dev.w3.org/csswg/css-scoping/#content-combinator Perhaps ::shadow-slot if you want to scope the naming somewhat. (What @hayatoito describes above for what ::content would do does not match the description in the CSS specification. Or maybe I'm missing something.)

[annevk]

(Behavior of <content>/<slot> has not changed significantly. Just simplified.)

[tabatkins]

If the behavior is the same, then yeah, ::slot seems like the best name.

[JanMiksovsky]

For what it’s worth, I share Hayato's concern that ::slot suggests it’s targeting the slot itself, not the distributed nodes.

I think it’s more important to have the combinator’s name suggest its intent than to have its name exactly match that of the element. To the extent that the #foo::content combinator was clear before, I think it worked because it could be read as “the content of #foo”, not just because the combinator’s name matched the element name .

I like Ryosuke’s goal of avoiding new terms like “distributed” if possible. I also agree with him that ::content on its own is too vague.

Of the proposals discussed so far, I believe ::slot-content strikes the best balance of: a) implying a connection to the element, and b) being reasonably intuitive.

On Jun 10, 2015, at 3:48 PM, Tab Atkins Jr. [email protected] wrote:

If the behavior is the same, then yeah, ::slot seems like the best name.

—
Reply to this email directly or view it on GitHub https://github.com/w3c/webcomponents/issues/92#issuecomment-110939785.

[hayatoito]

Aa far as I can read from the slots proposal, [1], there is one significant change in the behavior.

• doesn't select other elements. It tries to select the distributed nodes of the other content elements. See http://w3c.github.io/webcomponents/spec/shadow/#dfn-pool-population-algorithm for details.
• selects other elements

[1] https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md

That's the reason I have a concern.

As for , I guess developers don't get confused by ::content because content elements never select other content elements.
As for , developers might get confused by ::slot because slot elements _select_ other slot elements.

I can say, in the slots proposal, there are two kinds of "distributed nodes" for slot elements.

• One is directly assigned to slots, including other slots elements.
• The other is the result of slot.getDistributedNodes() as the slot proposal describes, excluding other slots elements.

"::slot" will impress developers that it selects the former, rather than the latter.
My concern hasn't changed.

It is also worth noting that '::content' is always used with a left side selector, such as "content::content". "#abc::content", in practical.

"::content" might be okay, but it should be avoided in practical because "*::content" is very wasteful. "content::content" can replace "::content" unconditionally.

I guess the same thing applies for slots elements.

• "::content" can be replaced with "slot::content", and it should be recommended to avoid unnecessary selector matching.

[hayatoito]

BTW, can we defer the discussion, say one month later?
I think it's a bit early to discuss this kind of topic. I'd like to prioritize other tasks than this and wait for the final version of the slots proposal.

[tabatkins]

Yes, I'd greatly prefer to wait until the slots proposal is fully statted out before trying to mold some CSS around it.

[humanarity]

Since slots inverts control from content ( content decides which nodes to distribute, nodes named to a slot can decide where they distribute ), can't we have both? Seems there are cases where the balance of control on component authors or component users could work to go either way.

[hayatoito]

@humanarity
I have the similar concern about slots.
You might want to take a look at: https://github.com/w3c/webcomponents/issues/343

[wejrowski]

I'm not sure the best place to ask this question, but... I'm curious, did the <content> tag which chrome currently supports simply get renamed to <slot>? Or is there something more going on here? I know I can use in chrome, but FF was showing the content tag deprecated.

Any replies would be awesome, also is there a better location for QA?

[hayatoito]

I guess the subject of this issue would confuse you. _Rename_ is not a good word here. They, <content> and <slot>, have different purposes.

<content> continues to work in chrome for Shadow DOM v0 (I mean it works inside of a shadow tree created by Element.createShadowRoot()) until it is deprecated someday. The deprecation should not happen soon. I will support it until it is deprecated.

Any replies would be awesome, also is there a better location for QA?

Yeah, we should discuss this in other places because your concern might be specific to chrome, but I think it's okay to answer here because you might not be the only person who got confused.

[wejrowski]

Yeah I'm curious what what difference is apart from just a rename.

Currently I'm trying to look into what's supported on browsers and where the standards are... what is firmly established and what is open for discussion (as far as web component related features are concerned). My assumption has been that the basic component API has been agreed on and it's just a matter of naming, though perhaps everything's still up in the air. I also discovered createShadowRoot() has also been renamed which was a surprise to me too.

[annevk]

@wejrowski I recommend reading through http://hayato.io/2016/shadowdomv1/.

[retrocausal]

As a developer , It is getting a tad inconclusive. I know, that a <content> tag would render whatever is marked down within the custom element tags.

Now, I see that we have a concept called the <slot> tags within the shadowDoM for a custom element, and any markdown within the tags , gets appended to the slot tag in the shadowDoM.
Now, where does that leave <content>?

[annevk]

<content> is obsolete.

[retrocausal]

Huh! Nooooo! all my old code is gonna break?

Rememeber we used to

<template id="some-id">
    <div class="some-class">
        <content></content>
    </div>
</template>

and if the custom element we defined was "custom-element" ,
and if that element was built using the template above ,
anything within

<custom-element>
 < markup>
</custom-element>

the markup would be injected into the template.

What are our options now, considering content being obsolete?

[domenic]

Your old code was already broken in all browsers except Chrome :)

As @annevk said a few posts ago, reading through http://hayato.io/2016/shadowdomv1/ or other tutorials will be your best way to understand your options.