2023 TPAC F2F discussion?
rniwa opened this issue · comments
Are folks interested in discussing web components at this year's W3C TPAC? If so, what are the topics of your interests?
Absolutely would love to meet and discuss web components topics. The Web Components CG has started a thread to prepare the annual report and discussion topics here:
In addition to what is discussed there, there's been a renewed discussion of WebKit's current stance on customizable built-ins and how we should proceed with the relevant scenarios. I pinged you on the issue. Feel free to chime in whenever you get a chance.
Alright, I've migrated the list of topics from that page:
- Cross Root ARIA
- Scoped Element Registries
- DOM Parts
- Custom Attributes / Element Behaviors
- #972, especially accessibility-related scenarios.
- #939
- #814
- dequelabs/axe-core#4085
- #936
How long are the sessions? Given the potentially very long list of WC topics, would it make sense to prioritize by those that have some sort of update or need consensus on a particular open question?
For instance, the Chrome team has been prototyping both scoped custom element registries and DOM Parts to gather early implementor feedback. That might be good to discuss (if we don't get them it at earlier meetings).
Proposing DOM / Template parts breakout session: w3c/tpac2023-breakouts#13
Cross-Root ARIA breakout session: w3c/tpac2023-breakouts#14
Scoped custom element registry session: w3c/tpac2023-breakouts#15
Respectfully, I think that proposal falls short in a number of ways:
- For each behavior, the vendor needs to fully dictate what goes into the initial settings of the attribute (whether it be JSON or some other format). Sharing one attribute for all behaviors would be too limiting.
- Having separate attributes conforms much more closely to proven solutions across multiple frameworks and across multiple decades of development.
- There's no explicit support for providing a public way for external components to interact with the behavior. Not having that would make the proposal fall short of providing a true alternative to customized built-ins. [Update: there is - element.behaviors - I missed that].
- It isn't a formal proposal.
There is a formal proposal that addresses all these concerns. Any flaws that you see with it?
@bahrus Let's discuss both of these options then. I just wanted to make sure we have some way of moving the conversation forward.
Respectfully, I think that proposal falls short in a number of ways:
Just wanted to add a comment here on the topic of these custom enhancements/attributes to say that I think that scoping should be a first-party concern whenever the element in question has a "canonical name". I think that the global nature of the custom element registry is coming to bear as a problem rather than the desired end state, and as such I think that we should consider scoping as a first concern with any new feature where defining the thing starts with some name that must be unique.
IMO any feature like custom elements or custom behaviors/enhancements should have the ability to be scoped to a particular element/collection so that third party libraries can safely declare these without worrying about conflicts in consuming applications.
Can we make sure to leave technical discussion to specific issues about proposals and keep this one focused on agenda setting?
Hello you all, I'm new to this process. Anything I can do to help facilitate the TPAC session on customized built-ins alternatives? Totally willing to help out, but not sure if someone already has that covered or what would be particularly helpful.
Hello you all, I'm new to this process. Anything I can do to help facilitate the TPAC session on customized built-ins alternatives? Totally willing to help out, but not sure if someone already has that covered or what would be particularly helpful.
Proposed it in w3c/tpac2023-breakouts#44