Replies: 8 comments 16 replies
-
|
Since there have been additional breakouts for both cross root ARIA features and DOM Parts, I think reporting on the progress of those efforts should be specifically included in this year's report. Based on where we landed last year, I think we should come up with the top list of asks we have of implementors, keeping it to a short list of the most critical issues, so we can focus the actual meeting on those. The broad categories I personally would prioritize are:
These are the categories I've heard the most about coming from the community, both folks who are using Web Components and those who are holding off for now. AccessibilityI'm less up to date in this area, but I think we need the Cross Root ARIA story settled and commitment from implementors as a top priority. We probably want to see if we can get declarative ElementInternals settled as well, as this relates to both accessibility and declarative scenarios. Declarative ScenariosFirst, we should work hard to get commitment from Firefox to implement DSD, as a top priority. Right now, they are the only implementor who hasn't shipped it. Second, we need to drive for some implementation of Declarative CSS Modules. This is making various DSD scenarios difficult or impractical. It's a hangup for various folks not adopting Web Components. Third, we should re-iterate our philosophy in the ears of everyone present that all Web Component features need to be designed with declarative scenarios in mind from the beginning. We should also make it clear that we want to get to some sort of declarative custom element capability soon. ScalabilityWe really need to get scoped element registries over the finish line. This keeps coming up as a reason why folks won't adopt Web Components. When I first entered Web Component territory myself, it was one of my biggest concerns. I also see existing Web Component adopters struggling with this in two particular cases:
SummarySo, here's what my list to focus on would be:
In addition to this, I think we should do the update on DOM Parts in the meeting. Then, lets use the written report to make sure we cover everything else in some way. |
Beta Was this translation helpful? Give feedback.
-
|
Also, I'm happy to help out in preparing the report. |
Beta Was this translation helpful? Give feedback.
-
|
You're just the first victim on the discussion, but I rather like how this shapes into a section title slide: Table Stakes
There is no escaping delivering on these things. 😉 |
Beta Was this translation helpful? Give feedback.
-
|
Seriously considering putting up a whiskey bounty on Mozilla DSD https://mh-distillery.com/product_series/elements/ It's called "elements", get it? |
Beta Was this translation helpful? Give feedback.
-
|
I would love for this issue to get some attention: WICG/webcomponents#814. There seems to be positive reactions toward the idea, but somebody "just" needs to write a proposal? This could also allow the custom elements to support the |
Beta Was this translation helpful? Give feedback.
-
|
Would you be interested in submitting the PR to HTML as per this comment? Being able to show places where "we help you to help us help you" would be a great addition to the conversation here! |
Beta Was this translation helpful? Give feedback.
-
|
I don't feel very qualified to create such a PR to be honest, as in: I have no idea what/how to write such a thing. Also, there seems to be an open question regarding the declarative way to implement the feature. That probably has overlap with @EisenbergEffect's points. |
Beta Was this translation helpful? Give feedback.
-
|
That begs a valuable question, while declaratively is highly important, for APis like Element Internals, will we block new features being added (like this) until the whole API can be addressed declaratively? Also, a non-shipping ask for the TPAC attendees might be for a “learning the process” meeting/docs (that might already exist) to position interested parties, like yourself, to better contribute in these areas! |
Beta Was this translation helpful? Give feedback.
-
|
With cross-browser DSD support nearing and opening the door for SSR, an issue that Cory LaViska on Shoelace and I on Material Web have increasingly run into is SSR FOUC regarding styling a node that contains a slot with content or not. Essentially a need for either Previous conversations going on here: WICG/webcomponents#936 There are workarounds to this that are not the best DX-wise. In Material we require a user to add an attribute to an element in the case of SSR with auto-detection on client (causing FOUC but the right behavior) e.g. Personally I'm not picky if the solution doesn't look like this issue above, but we need something here as users are increasingly trying to integrate our components across SSR-first frameworks like Next and Nuxt |
Beta Was this translation helpful? Give feedback.
-
|
A composed analogue to :empty (ideally trimming/normalizing) on slot would be good too, and let us replace a bunch of JavaScript with much less CSS |
Beta Was this translation helpful? Give feedback.
-
|
Specifically, I have a bunch of cases where being able to do something like this would be a huge saving: .something:has(+ slot:has-slotted(*)) |
Beta Was this translation helpful? Give feedback.
-
|
It's probably a bit out of scope for web components, but I think it's worth looking at the custom attributes proposal a bit more. The Lit controllers and directives are very useful but are Lit specific, unfortunately. Custom attributes provide a nice generic way of implementing them, with the added advantage of being applicable to any element. In many cases where I want to customize a built-in element a custom attribute will do the job. |
Beta Was this translation helpful? Give feedback.
-
|
Now that there is general adoption for the
|
Beta Was this translation helpful? Give feedback.
-
|
Are there any issues/explainers/proposals related to the concepts herein? |
Beta Was this translation helpful? Give feedback.
-
|
Not that I'm aware of. |
Beta Was this translation helpful? Give feedback.
-
|
The first seems like a tooling question, but the second seems like it could have one opened in https://github.com/WICG/webcomponents/issues if you were able to whip one up. |
Beta Was this translation helpful? Give feedback.
-
|
The first one is a combination of browsers support (Safari) issues and tooling issues. I went ahead and opened a ticket for the second. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Apple has reasserted its preference for Element Behaviors and Custom Enhancements over Customized Built-ins. We should look at building off of that position and see if there's room to advance discussion, proposals, and possibly even specs and that area more actively. |
Beta Was this translation helpful? Give feedback.
-
|
Could not agree more. WebKit's blocking of customized builtins leaves a huge hole in the ability to write composable custom elements when dealing with elements that require a strict child hierarchy ( |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to add that saying "just use a polyfill" is not an acceptable response for those wanting to deliver HTML for progressive enhancement. |
Beta Was this translation helpful? Give feedback.
-
|
Report on current status and alternatives filed; let me know if this should be moved here or to an issue, PR, or something else! |
Beta Was this translation helpful? Give feedback.
-
|
I like @EisenbergEffect's summary a lot. If I could vote for only one thing, though, it would be for cross-root ARIA. My reasoning is that almost everything else is polyfillable/work-around-able: Declarative shadow DOMFully polyfillable. It's a perf hit, and requires JavaScript, but it's doable. Declarative CSS modulesThe main benefit here AIUI compared to classic Scoped custom element registriesA polyfill exists, and we ourselves at Salesforce have experimented with our own flavor of polyfill. The strategy looks viable, although it has some small perf and correctness issues (e.g. timing of attribute changes, dealing with conflicting Declarative ElementInternalsAgain, inherently polyfillable (since the JS solution already exists), so this is mostly about perf and progressive enhancement. Cross-root ARIAWe've experimented with polyfilling this, but it's incredibly tricky and fragile. Essentially you need a system to copy DOM nodes from one shadow root to another, hiding them visually but exposing them to screen readers, which opens several cans of worms:
In short, it's really hard to polyfill even something as small as ARIA element reflection, let alone full cross-root ARIA. And you can't just say "accessibility doesn't matter, let's ship anyway." So from my POV, this is a hard blocker for web component adoption (with native shadow roots, anyway). I'd be curious to know if other framework authors see any other features that are equally "blocking." (E.g. I've only glanced at WICG/webcomponents#814, but it seems pretty tricky to work around.) |
Beta Was this translation helpful? Give feedback.
-
|
Agreed that cross-root aria is top priority, but DSD in moz should be close behind, especially since it's (a) "just" an implementation issue and (b) makes shadow dom workable at scale for many who were until now not comfortable with it |
Beta Was this translation helpful? Give feedback.
-
|
+1 to cross-root ARIA. Is
Is style is Declarative CSS Modules an attempt to solve for that? Or is that only for DSD? |
Beta Was this translation helpful? Give feedback.
-
Last year we had a great early discussion here on GitHub had got us prepared to share out our 2022 Report at TPAC, and now it's time to start the discussion again! In the last year, what went wrong, what went right, what did we learn to ask for next? Let's get the conversation started here in preparation for some calls starting in July around developing and presenting this year's report. Whether you're a web component user, a web component writer, a browser implementor, or somewhere in between your insight could go a long way towards our 2023 report, and on going efforts by the Web Components Community Group. We hope you'll share your thoughts below. 🙏🏼
To keep things productive, let's try to keep each response focused on one spec/proposal/feature area, so that we can keep any other responses grouped together. To support that, please read through any open response threads to see if your subject has already been opened and respond there, rather than in a new thread. 🧵
When discussing open proposals, be sure to share as many links to issues, explainers, previous conversation as possible to support connecting all the dots on these often complex and always very nuanced ideas. If you're really invested in one feature area or another, start thinking about volunteering to take responsibility of that segment of the report as we prepare for TPAC. 🧑🔬
Looking forward to seeing what you all bring to the conversation! 👋🏼
Beta Was this translation helpful? Give feedback.
All reactions