Intent to Ship: CSS shadow parts

[Fergal Daly]

Contact emails

fer...@chromium.org, taba...@chromium.org

Explainer

::part and ::theme explainer. Note that this I2S is only for the ::part pseudo-element; ::theme requires more web developer feedback and implementation work.

Design doc/Spec

https://drafts.csswg.org/css-shadow-parts/

TAG review request: https://github.com/w3ctag/design-reviews/issues/230

Summary

Introduce part= and exportparts= attributes and ::part(ident) CSS pseudo element to allow custom elements to expose specific sub-elements for styling by the containing light-tree.

Link to “Intent to Implement” blink-dev discussion

There was no discussion on the previous Intent to Implement thread.

Motivation

Previous methods like /deep/ and >>> were overpowered, exposed implementation details of custom elements and had performance problems. This proposal gives custom elements a clear API and avoids leaking implementation details.

Risks

Interoperability and Compatibility

As this is a new feature which Chromium is leading with, we have solicited community feedback and submitted a complete WPT test suite. The spec had a lot of input from Apple, some input from Mozilla and Edge and agreement at CSS-WG

 

Edge: "I furthermore don't see any reason why Microsoft wouldn't support this spec moving forward as a prototype implementation in Blink. " in this issue

Firefox: "worth prototyping" in this issue

Safari: Supportive of approach in this issue

Web developers: Polymer team and Salesforce are supportive

Ergonomics

Significant time was spent on the syntax of part forwarding with the final syntax mimicking that of object destructuring assignment in JS. There is no API for programmatic manipulation of the exported parts map beyond string assignment of a new pending more investigation.

Activation

This feature is likely to require transpiler support for developers targeting legacy browsers. We're actively looking for feedback from Web Component authors. As the needs this feature is designed to address are a top request from Polymer and other framework users, we anticipate working with Web DevRel to reach those communities for feedback.

Debuggability

Search box in DevTools Elements tab supports this and be able to show where in the shadow tree a selector has matched.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5763933658939392

Requesting approval to ship?

Yes

[astorin...@gmail.com]

What about many issues marked in the editor's draft?

[Fergal Daly]

On Tue, 11 Dec 2018 at 04:57, <astorin...@gmail.com> wrote:

What about many issues marked in the editor's draft?

They were mostly potential enhancements. I've migrated them to github issues where appropriate. There is one issue remaining which is a matter of moving the part attribute to be a super-global in the HTML spec but it does not block anything,

F

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8f62f10e-2375-4084-928a-2d6700a6af1b%40chromium.org.

[Yoav Weiss]

The feedback from other browsers seems to be that they support prototyping the approach, and you say here that we're looking for feedback from authors.

Have you considered an origin trial to gather such feedback? Have authors tried the API shape out and experimented with it behind a flag? 

How confident are we that the shape of the API is the right one? 

 

Debuggability

Search box in DevTools Elements tab supports this and be able to show where in the shadow tree a selector has matched.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5763933658939392

Requesting approval to ship?

Yes

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEhrzUfyirAniN2UFeGRPBjgMb6wTG%2BN3Ycr_Dcr-YAW%3DnnnAw%40mail.gmail.com.

[Daniel Bratell]

fergal, ping, just in case you missed yoav's questions.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgX71RV%2Bw0Y_6g_shPnL6cT4GR3bnwY1z6rF6L88ryP4A%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Daniel Bratell]

Removing Google internal mailing lists (dom-team, polymer-team) from CC. They wouldn't get my mails anyway.

/Daniel

[dpa...@chromium.org]

On Monday, December 10, 2018 at 1:42:02 AM UTC-8, Fergal Daly wrote:

Contact emails

fer...@chromium.org, taba...@chromium.org

Explainer

::part and ::theme explainer. Note that this I2S is only for the ::part pseudo-element; ::theme requires more web developer feedback and implementation work.

Design doc/Spec

https://drafts.csswg.org/css-shadow-parts/

TAG review request: https://github.com/w3ctag/design-reviews/issues/230

Summary

Introduce part= and exportparts= attributes and ::part(ident) CSS pseudo element to allow custom elements to expose specific sub-elements for styling by the containing light-tree.

Link to “Intent to Implement” blink-dev discussion

There was no discussion on the previous Intent to Implement thread.

Motivation

Previous methods like /deep/ and >>> were overpowered, exposed implementation details of custom elements and had performance problems. This proposal gives custom elements a clear API and avoids leaking implementation details.

Risks

Interoperability and Compatibility

As this is a new feature which Chromium is leading with, we have solicited community feedback and submitted a complete WPT test suite. The spec had a lot of input from Apple, some input from Mozilla and Edge and agreement at CSS-WG

 

Edge: "I furthermore don't see any reason why Microsoft wouldn't support this spec moving forward as a prototype implementation in Blink. " in this issue

Firefox: "worth prototyping" in this issue

Safari: Supportive of approach in this issue

Web developers: Polymer team and Salesforce are supportive

The Chromium's WebUI team is also interested in this feature, so that we can start moving away from CSS mixins (currently working via Polymer's polyfil). Do you think this feature is ready for us to play with? If so, what flags do we need to use, and when can we expect this to be enabled by default?

[Fergal Daly]

Apologies for the slow reply, I was hoping to get some direct feedback from devs on this thread.

Some of that paragraph is out of date and copied from the I2I. We have been talking to devs and have feedback and some requests for more advanced capabilities for this.

Salesforce, Polymer and Component Kitchen have engaged at various points.

I don't think an origin trial makes a lot of sense for this. The risk is about the API being the wrong shape, as you say, and that mostly just needs people to try develop with it.

I will get back on this thread with clear confirmation from the component devs who have tried it, that the API is sufficient for their purposes. We know there are some things that could be more convenient, they are features like wildcard forwarding, attribute selection, theme support but they would be additions and wouldn't change what we are trying to ship now,

F

[Yoav Weiss]

That's exactly what an origin trial is for...

Is there some reason people cannot start developing prototypes with it behind an origin trial (or for a smaller audience, behind a flag?)

[Fergal Daly]

On Sun, 16 Dec 2018 at 07:24, <dpa...@chromium.org> wrote:

On Monday, December 10, 2018 at 1:42:02 AM UTC-8, Fergal Daly wrote:

Contact emails

fer...@chromium.org, taba...@chromium.org

Explainer

::part and ::theme explainer. Note that this I2S is only for the ::part pseudo-element; ::theme requires more web developer feedback and implementation work.

Design doc/Spec

https://drafts.csswg.org/css-shadow-parts/

TAG review request: https://github.com/w3ctag/design-reviews/issues/230

Summary

Introduce part= and exportparts= attributes and ::part(ident) CSS pseudo element to allow custom elements to expose specific sub-elements for styling by the containing light-tree.

Link to “Intent to Implement” blink-dev discussion

There was no discussion on the previous Intent to Implement thread.

Motivation

Previous methods like /deep/ and >>> were overpowered, exposed implementation details of custom elements and had performance problems. This proposal gives custom elements a clear API and avoids leaking implementation details.

Risks

Interoperability and Compatibility

As this is a new feature which Chromium is leading with, we have solicited community feedback and submitted a complete WPT test suite. The spec had a lot of input from Apple, some input from Mozilla and Edge and agreement at CSS-WG

 

Edge: "I furthermore don't see any reason why Microsoft wouldn't support this spec moving forward as a prototype implementation in Blink. " in this issue

Firefox: "worth prototyping" in this issue

Safari: Supportive of approach in this issue

Web developers: Polymer team and Salesforce are supportive

The Chromium's WebUI team is also interested in this feature, so that we can start moving away from CSS mixins (currently working via Polymer's polyfil). Do you think this feature is ready for us to play with? If so, what flags do we need to use, and when can we expect this to be enabled by default?

That would be great. You can enable it with --enable-blink-features=CSSPartPseudoElement against M72. That gets you everything except .part IDL attribute and some different handling of parse errors. M73 has those last bits.

How soon? The public spec is fully implemented in M73 behind that flag. So as soon as we can get approval to ship,

F

 

 

Ergonomics

Significant time was spent on the syntax of part forwarding with the final syntax mimicking that of object destructuring assignment in JS. There is no API for programmatic manipulation of the exported parts map beyond string assignment of a new pending more investigation.

Activation

This feature is likely to require transpiler support for developers targeting legacy browsers. We're actively looking for feedback from Web Component authors. As the needs this feature is designed to address are a top request from Polymer and other framework users, we anticipate working with Web DevRel to reach those communities for feedback.

Debuggability

Search box in DevTools Elements tab supports this and be able to show where in the shadow tree a selector has matched.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5763933658939392

Requesting approval to ship?

Yes

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8bbebf1d-e605-4f26-aa34-1f9907d80656%40chromium.org.

[elfo...@gmail.com]

At Salesforce we just recently launched Lightning Web Components to all our +5M developers, and certainly we are super excited about parts and themes since it will enable the component customization we been looking for years in a multi-author multi-version ecosystem.

We will ship it to our customers as soon as implementors do a +1 in the final spec and we have some implementations ready to run!

Exciting times!

On Monday, December 10, 2018 at 1:42:02 AM UTC-8, Fergal Daly wrote:

[Yoav Weiss]

On Tue, Dec 18, 2018 at 8:29 AM <elfo...@gmail.com> wrote:

At Salesforce we just recently launched Lightning Web Components to all our +5M developers, and certainly we are super excited about parts and themes since it will enable the component customization we been looking for years in a multi-author multi-version ecosystem.

We will ship it to our customers as soon as implementors do a +1 in the final spec and we have some implementations ready to run!

That's great to hear! Have you played around with the API (behind a flag) and seen that it will tackle your use-cases as well as that its ergonomics make sense?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/40dadd23-ca4f-47f8-98c2-7e252ac9b7cd%40chromium.org.

[elfo...@gmail.com]

Yes! We have a parallel thread with Fergal, Rakina and Domenic. Will share some feedback shortly.

[Yoav Weiss]

Friendly post-holidays ping :) Feedback will be highly appreciated.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/78c6c5fe-0042-41f7-bf00-7213df7b973d%40chromium.org.

[Fergal Daly]

Thanks for you patience Yoav. We have feedback from 2 producers of component sets Salesforce and Component Kitchen.

Part as it stands provides needed functionality for them. It seems pretty clear that there is still functionality missing and several ideas of how to expand the API to provide that, none of which confict with the basic API.

I can think of a few options

1 ship what we have an work with CSSWG to add more features

2 don't ship what we have until we have agreed how to add more features

3 other options???

On the issue of an origin trial, we didn't really look at that because it doesn't seem like we would learn much about the ergonomics and capabilities of the API by sending live traffic to a site with these features enabled.

I'm not really sure how to proceed here, I really don't like the look of #2,

F

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhDUvtt-wpqO2jYNhwbmiiCzGK-0gp38BrMVRgaBR1s%2Bg%40mail.gmail.com.

[Diego Ferreiro Val]

Fergal, we would love to know if you guys have some soft-deadline in mind so we can provide some more feedback and finish our work to make sure what we currently have implemented is sufficient (assuming workarounds) to make it part of our platform. 

For example per our feedback, only having pseudoselectors might not be sufficient and maybe wouldn't be to hard to add it as part of first batch if we have the time and makes sense from your end (not saying we should do this, is just an example of a potential quick iteration before 1#).

Also, probably this is in a thread on the repo already, but knowing where other implementors position at this point with the current state of things will be interesting as well.

--

Diego Ferreiro Val

@diervo

[Justin Fagnani]

On Tue, Jan 8, 2019 at 4:59 AM Fergal Daly <fer...@google.com> wrote:

Thanks for you patience Yoav. We have feedback from 2 producers of component sets Salesforce and Component Kitchen.

Part as it stands provides needed functionality for them. It seems pretty clear that there is still functionality missing and several ideas of how to expand the API to provide that, none of which confict with the basic API.

I can think of a few options

1 ship what we have an work with CSSWG to add more features

2 don't ship what we have until we have agreed how to add more features

3 other options???

On the issue of an origin trial, we didn't really look at that because it doesn't seem like we would learn much about the ergonomics and capabilities of the API by sending live traffic to a site with these features enabled.

I'm not really sure how to proceed here, I really don't like the look of #2,

Both the feedback docs seems to point to the same issue that also overlaps with custom pseudo-classes. That should be explored, but not block this initial step. Also, I still think ::theme() is critical for this feature.

FYI, we now have the beginnings of a plan to use ::part() in LitElement on browsers that support it, and do a bespoke workaround for those that don't - an approach that should be a lot less work than a real polyfill. This would make #1 valuable to us before other engines implement.

 

You received this message because you are subscribed to the Google Groups "Polymer Team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-team...@google.com.
To post to this group, send email to polyme...@google.com.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/polymer-team/CAAozHLkVUUrMamfEaxs3OL-TGLpZH4bY%2B5601OCho9dPL_LaSg%40mail.gmail.com.

[Diego Ferreiro Val]

I will give you some update next week in case we find something else worrying, but otherwise, from our end, we are happy to see it ship ASAP!

[Fergal Daly]

I don't think this thread or blink-dev is the right place for detailed discussion, e.g. about what's missing or what should be changed, a github issue would be best for that (I created this one to capture general feedback but feel free to create new ones for specific problems). However it would be helpful to get a concise positive or negative feedback, e.g. "if you ship this we will use it immediately and the API looks right to me" or "this will only be useful if you address X, Y and Z [links to issues]".

Thanks,

F

On Fri, 11 Jan 2019 at 09:49, <stephan...@gmail.com> wrote:

Hi all, I couldn't post with my Salesforce address, but can with my personal. So just to clarify, I'm Stephanie Rewis from the SLDS framework team.

My team just spent some time on this over the past couple of days. We have some feedback and questions. Would you like me to post them here?

Cheers 

[Justin Fagnani]

Stephanie, that makes sense to me. I'd like to try to separate "missing" as in "I can't use this without it" from "missing" as in "adding another incremental feature will unlock additional important use-cases and/or complete ::part". I think both ::theme and custom pseudo-classes are critical for many things, but I'd want to ship ::part first and add them next.

On Thu, Jan 10, 2019 at 6:16 PM <stephan...@gmail.com> wrote:

Thanks Fergal. We can post our feedback on github if that's better (we created a doc). We'd like to get a couple roadmap questions answered prior to saying, "Yes, I'll use it tomorrow." I'm sure you understand. Did you mean to link to the thread we should use?

Cheers

[stephan...@gmail.com]

Thanks Fergal. We can post our feedback on github if that's better (we created a doc). We'd like to get a couple roadmap questions answered prior to saying, "Yes, I'll use it tomorrow." I'm sure you understand. Did you mean to link to the thread we should use?

Cheers

On Thursday, January 10, 2019 at 6:21:16 PM UTC-7, Fergal Daly wrote:

[stephan...@gmail.com]

Hi all, I couldn't post with my Salesforce address, but can with my personal. So just to clarify, I'm Stephanie Rewis from the SLDS framework team.

My team just spent some time on this over the past couple of days. We have some feedback and questions. Would you like me to post them here?

Cheers 

On Thursday, January 10, 2019 at 5:35:57 PM UTC-7, Diego Ferreiro Val wrote:

[stephan...@gmail.com]

For those interested, I've posted my team's findings and questions here: https://github.com/w3c/csswg-drafts/issues/3467

[ad...@ionic.io]

At Ionic we're very excited about the CSS shadow parts spec and seeing the intent to ship. We've recently moved to using shadow dom and heavily using CSS variables at the moment, but fully intend on using these features.

[Yoav Weiss]

On Fri, Jan 11, 2019 at 11:40 PM <stephan...@gmail.com> wrote:

For those interested, I've posted my team's findings and questions here: https://github.com/w3c/csswg-drafts/issues/3467

Thanks for your feedback, Stephanie!

Regarding the "Web Component default exportparts=" section, is that technique currently possible? Or is it something you want added to the API?

Fergal & team - the question about "::before and ::after pseudo elements" seems potentially relevant to compatibility.

[Rune Lillesveen]

On Sat, Jan 12, 2019 at 9:53 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Fri, Jan 11, 2019 at 11:40 PM <stephan...@gmail.com> wrote:

For those interested, I've posted my team's findings and questions here: https://github.com/w3c/csswg-drafts/issues/3467

Thanks for your feedback, Stephanie!

Regarding the "Web Component default exportparts=" section, is that technique currently possible? Or is it something you want added to the API?

Fergal & team - the question about "::before and ::after pseudo elements" seems potentially relevant to compatibility.

That should have worked according to the current spec draft. That's a bug that should be fixed.

[Yoav Weiss]

That's great to hear. IIUC, all other feedback is additive feature requests, so shipping what we have now (and working on the missing pieces later) seems like the right way to go.

LGTM1 

[Philip Jägenstedt]

LGTM2

https://wpt.fyi/results/css/css-shadow-parts?label=experimental is looking good, but I wonder if any of the passes in Firefox/Safari suggest a problem with the tests, given that this isn't implemented yet?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhTcDM1Rp5o%2B4LJ0mqxSQoQs9rmfeoR3%3DLFFsPUe3neJw%40mail.gmail.com.

[Chris Harrelson]

LGTM3!

I really like the great and clear feedback provided by customers of this feature. Nice work! And thanks all for providing excellent feedback.

This is a model we can all learn from to improve feature quality in the future.

(p.s. Please fix the ::before and ::after pseudo bug before shipping.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfY_Tq0nCzgjXy8C4J_ohcsLDN3giTbo7uGoEmMve21ew%40mail.gmail.com.

[Hayato Ito]

Non-Owner LGTM.

Thank you all for providing precious feedback. One thing I would like to mention here about additive feature request is:

Regarding the feedback about a desire to style an ::part element based on the elements' attribute, we also got feedback that exposing an attribute by default (without opt-in) might not be a good idea, in terms of encapsulation. Let's continue the discussion in other thread. Anyway, that should be an additive feature.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-ppk%2Bj8Rh%3D48j6QseZw8AwHSGc9pdyeeuHqq%3DDyXxdbQ%40mail.gmail.com.

--

Hayato

[Fergal Daly]

Thanks. I will address various bits of feedback on github etc and have filed https://crbug.com/921908 for the ::before/::after issue,

F

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_3da74xK-pnXiacGawbrhaGN%3D_xKSegHFnuYu2EN4tC0w%40mail.gmail.com.

[wox...@gmail.com]

The explainer doc link is invalid in https://www.chromestatus.com/feature/5763933658939392

[Jeffrey Yasskin]

On Thu, Feb 7, 2019 at 9:20 AM <wox...@gmail.com> wrote:

The explainer doc link is invalid in https://www.chromestatus.com/feature/5763933658939392

I've fixed the link. (The box holds a list of URLs, but the last editor tried to include a label.)

[john...@google.com]

Hi,

Just as an FYI, the Chromium WebUI team has started using this feature with much success to replace our CSS mixins and to allow customization of our internal shared components.

.

You may follow along and see the journey here if you're curious: https://bugs.chromium.org/p/chromium/issues/detail?id=973674.

Thanks for the implementation!

On Saturday, December 15, 2018 at 2:24:21 PM UTC-8, dpa...@chromium.org wrote:

On Monday, December 10, 2018 at 1:42:02 AM UTC-8, Fergal Daly wrote:

Contact emails

fer...@chromium.org, taba...@chromium.org

Explainer

::part and ::theme explainer. Note that this I2S is only for the ::part pseudo-element; ::theme requires more web developer feedback and implementation work.

Design doc/Spec

https://drafts.csswg.org/css-shadow-parts/

TAG review request: https://github.com/w3ctag/design-reviews/issues/230

Summary

Introduce part= and exportparts= attributes and ::part(ident) CSS pseudo element to allow custom elements to expose specific sub-elements for styling by the containing light-tree.

Link to “Intent to Implement” blink-dev discussion

There was no discussion on the previous Intent to Implement thread.

Motivation

Previous methods like /deep/ and >>> were overpowered, exposed implementation details of custom elements and had performance problems. This proposal gives custom elements a clear API and avoids leaking implementation details.

Risks

Interoperability and Compatibility

As this is a new feature which Chromium is leading with, we have solicited community feedback and submitted a complete WPT test suite. The spec had a lot of input from Apple, some input from Mozilla and Edge and agreement at CSS-WG

 

Edge: "I furthermore don't see any reason why Microsoft wouldn't support this spec moving forward as a prototype implementation in Blink. " in this issue

Firefox: "worth prototyping" in this issue

Safari: Supportive of approach in this issue

Web developers: Polymer team and Salesforce are supportive

The Chromium's WebUI team is also interested in this feature, so that we can start moving away from CSS mixins (currently working via Polymer's polyfil). Do you think this feature is ready for us to play with? If so, what flags do we need to use, and when can we expect this to be enabled by default?

 

[Chris Harrelson]

That's awesome! Thanks for the feedback.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9011b436-ea61-4e3d-a3a9-2892f25cca33%40chromium.org.