Skip to content
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

Extend the slotting algorithm so that a slot can select an element which doesn't have slot attribute. #343

Closed
hayatoito opened this issue Oct 16, 2015 · 16 comments
Labels

Comments

@hayatoito
Copy link
Member

@hayatoito hayatoito commented Oct 16, 2015

I am afraid that component users would complain when they find that shadow host's children should always have a slot attribute, after shipping v1.

I don't have an intention to include this feature in v1. Let me file an issue here with v2 label, so that users can know that we are aware of this concern.

@rniwa

This comment has been minimized.

Copy link
Contributor

@rniwa rniwa commented Oct 16, 2015

You mean adding a declarative way to do this? Once we have an imperative API, authors can do whatever they want, right?

@hayatoito

This comment has been minimized.

Copy link
Member Author

@hayatoito hayatoito commented Oct 16, 2015

I don't have any concrete plan. I just wanted users to know what we are thinking, like your comment.
When we hear complaint from users, we can point this issue's URL to users. That would make users feel comfortable.

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Mar 22, 2016

Is this issue still needed?

@rniwa

This comment has been minimized.

Copy link
Contributor

@rniwa rniwa commented Mar 22, 2016

Yes, this issue about being able to select elements based on other criteria like element names slated for v2. I think we should address this by imperative API.

@hayatoito

This comment has been minimized.

Copy link
Member Author

@hayatoito hayatoito commented Mar 23, 2016

Yes, I think this issue is important because we can remove "slot" attribute from markup.

It makes sense to keep this issue open, though I guess we do not start to work on this issue soon. This is not easy.

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Mar 23, 2016

Didn't we have an issue for an imperative API that we also closed because of a lack of a concrete proposal? I'm not sure that we need issues for ideas.

@hayatoito

This comment has been minimized.

Copy link
Member Author

@hayatoito hayatoito commented Mar 23, 2016

That's #60.

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Mar 23, 2016

Right, let's just mark this as a duplicate.

@hayatoito

This comment has been minimized.

Copy link
Member Author

@hayatoito hayatoito commented Mar 23, 2016

However, the imperative API is not the only way to resolve this issue, I think.

@tomalec

This comment has been minimized.

Copy link
Contributor

@tomalec tomalec commented Mar 23, 2016

We do have created many custom elements (with shadow DOM v0) that acts as a containers for any content. It would be great if we could be able to achieve same functionality with v2, and to be able to do declaratively something like:

<my-fancy-container> <!-- , my-app-layout or any other element that should consume variaty of different elements -->
  <h1>Goes to `slot name="header"`</h1>
  <div>Any</div>
  <span>other</span>
  <p>element will be distributed where `slot`(?) or any other replacement for `content` without `select` attribute is</p>
</my-fancy-container>

With v0 we were able to to it simply with:

<!-- shadow root -->
<div class="makeContainerLookFancy">
   <div class="addUnicornToTheHeader"><content select="h1"></content></div>
   <content></content>
</div>

Personally I think it's not a duplicate of imperative API, as it would be great to be able to do something that simple declarative way.

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Mar 23, 2016

My main point was that this is just an idea. Without a concrete proposal, I don't think an issue is warranted.

@tomalec

This comment has been minimized.

Copy link
Contributor

@tomalec tomalec commented Mar 23, 2016

Ok, got it.

And probably something like below introduces same performance and lifecycle issues, like content select from v0, doesn't it?


Input
NODE, a node
Output
(nullable) SLOT, a slot to which NODE is assigned.

  1. If the parent node of NODE is a shadow host:
    1. Let TREE be the shadow tree that the parent node of NODE hosts
    2. Let NAME be the value of the slot attribute of NODE
    3. If NAME is missing:
      1. Let SLOT be a default slot for TREE if it exists, Otherwise, null
    4. If NAME is the empty string:
      1. Let SLOT be the first slot which select attribute matches NODE, If there is none null
    5. Otherwise:
      1. Let SLOT be the most preceding slot in TREE whose slot name is NAME if it exists. Otherwise null.
  2. Otherwise:
    1. Let SLOT be null

However with such algorithm, we will be able to specify that some nodes are allowed to be distributed, without awareness of shadow DOM structure (slot name), keeping the fully efficient slot selector.

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Mar 23, 2016

Yeah, that has the same problem.

@rniwa

This comment has been minimized.

Copy link
Contributor

@rniwa rniwa commented Mar 23, 2016

I don't think using CSS selector is the way to go here. That would have the same problem where if you have an instance of custom element A that gets slotted to S, then an instance of a subclass of A would not be slotted the same way. This was a big problem for Polymer and Component Kitchen, and that's why many components relied on explicit classes and other attributes to slot elements.

I think selecting elements based on interface would be a better alternative. That is, instead of selecting an element based on DOM state, we select based on the [[Prototype]] internal slot. This allows every subclass of an element slotted to S would also be slotted.

More, concretely, you could imagine adding methods on HTMLSlotElement to specify a list of element interfaces to assign to the slot. e.g. slot.addSelectedElement(HTMLSummaryElement).

@hayatoito

This comment has been minimized.

Copy link
Member Author

@hayatoito hayatoito commented Dec 6, 2016

Let me close this since we do not have any clear idea to achieve this.

@hayatoito hayatoito closed this Dec 6, 2016
@WalterWeidner

This comment has been minimized.

Copy link

@WalterWeidner WalterWeidner commented Dec 29, 2016

@rniwa you also have the case where you don't want subclasses to be slotted into where a base is allowed (which seems like it would be more common).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.