-
Notifications
You must be signed in to change notification settings - Fork 371
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
[Shadow]: rename <content> to <slot> (bugzilla: 28561) #92
Comments
Does this mean |
I guess there is no intention for that. We can file a new bug if we prefer |
Without a |
|
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 |
Yeah, we should rename |
The point is One idea, we might have both:
IMO, renaming to |
I don't think we should use a completely different name like Having said that, the only name I can think of will be |
Agreed on terrible naming history, would love to do better. How about |
I am not saying that we have to rename What problems are you trying to solve by renaming Anyway, now I think everyone can understand why I think everyone doesn't like a renaming again and again. :( |
I disagree. |
If you are still interested in renaming, could you file a bug for CSS Scoping, http://dev.w3.org/csswg/css-scoping/ ? |
If that's your final response, why didn't you just say that at the beginning instead of making comments about how 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 |
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. |
Hey @tabatkins, what's the best place to discuss renaming |
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 |
Yeah, so I don't see how |
(Behavior of |
If the behavior is the same, then yeah, |
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.
|
Aa far as I can read from the slots proposal, [1], there is one significant change in the behavior.
[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 I can say, in the slots proposal, there are two kinds of "distributed nodes" for slot elements.
"::slot" will impress developers that it selects the former, rather than the latter. 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.
|
BTW, can we defer the discussion, say one month later? |
Yes, I'd greatly prefer to wait until the slots proposal is fully statted out before trying to mold some CSS around it. |
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. |
@humanarity |
I'm not sure the best place to ask this question, but... I'm curious, did the Any replies would be awesome, also is there a better location for QA? |
I guess the subject of this issue would confuse you. Rename is not a good word here. They,
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. |
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. |
@wejrowski I recommend reading through http://hayato.io/2016/shadowdomv1/. |
As a developer , It is getting a tad inconclusive. I know, that a Now, I see that we have a concept called the |
|
Huh! Nooooo! all my old code is gonna break? Rememeber we used to
and if the custom element we defined was "custom-element" ,
the markup would be injected into the template. What are our options now, considering content being obsolete? |
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. |
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.
The text was updated successfully, but these errors were encountered: