- From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Apr 2019 05:41:55 +0000
- To: public-css-archive@w3.org
> I think the main objection t this is that it would expose the implementation details in the API. E.g. if you expose something as ::part(a)::part(b)::part(c) then you must continue to maintain a custom element b wrapping c forever (or make a breaking API change). Assuming you had to explicitly export the nested parts in the first place that doesn't seem like a huge concern to me, fwiw. > It also prevents a component from hiding its inner parts from styling (unless we add some kind of do-not-expose-parts="...". Preventing users from styling certain things is less of a concern but preventing users from depending on the existence of certain implementation details is a real goal. Yes, to be clear the proposal is not automatically exporting all nested parts or such. I understand that hiding implementation details is a goal worth the effort. This isn't about getting rid of that functionality, but about how to address nested parts using selectors. Sorry if that caused misunderstanding. Basically, you would have `<my-component exportparts="foo bar">` and you would only match `::part` on the outer trees if that part is actually exported. Not sure if that is clear enough, I'm happy to make a more formal proposal if it's not clear enough. > It would be useful to know how you have been using part and what pain-point inspired this suggestion. Part hasn't had much attention since shipping, so knowing more about the practical problems with using it could help get it some attention. I'm mostly been playing with it a bit, and mostly with an implementer hat on, FWIW. Some of the Firefox front-end engineers are interested in shadow parts to style part of the UI, and I thought a bit about how would I go about implementing it. Implementing parts without part forwarding is quite straight-forward. Implementing forwarding is a bit more of a headache, since you need to track changes to a bunch of different attributes in all your ancestor chain, and makes a single `::part()` jump across potentially many nested shadow trees. The model I'm proposing for nested parts would be quite simpler (this is both with an author hat on and an implementer hat on), and the only thing you miss is the "you can't lie and say that a nested component's part is actually your part". > Yes, allowing a component to choose how it exposes a component/sub-component is an intentional and important point here; whether a part is implemented directly by the component or as part of a nested sub-component isn't a detail that the outer page should care about or even be aware of. I'm not sure I agree with that. Allowing to rename parts brings quite a bit of implementation complexity unnecessarily, IMO. I think the whole model would be a bit easier to understand if you could just say which nested parts of a component you export, and match them using selectors. > Indeed automatically exposing inner parts is problematic because a component may not want to let its users style a component used as an implementation detail. Yes, I get that. as I said I'm not talking about automatically exposing inner parts, that's not incompatible with this model. You could still require having `exportparts="foo bar"` on the shadow host in order to expose it to outer trees. This is _exclusively_ about how to address them with selectors. Sorry for not making that clearer. -- GitHub Notification of comment by emilio Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3841#issuecomment-484773610 using your GitHub account
Received on Friday, 19 April 2019 05:41:56 UTC