- From: Ryosuke Niwa <notifications@github.com>
- Date: Sun, 19 Feb 2017 23:42:46 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/509/281008352@github.com>
> @rniwa That is such a cool, outside-of-the-box suggestion. Haha, it's not so outside-of-the-box if you work on the browser engine. We have a whole bunch of C++ classes various elements use to behave the way they behave. It's not like we implement each element as one monolithic C++ class. If you think of it, the whole idea of shadow DOM came out of the internal implementation detail of input and textarea elements in WebKit, which Dave Hyatt modeled after XBL2. > I'm interested in exploring the path this is going down because it feels like, if there is a direction for this, library authors can start providing abstractions similar to how these might be used natively, thus not only giving a stop-gap API that is similar to the WC future, but also being able to provide extensions in a similar manner. Great. We're interested in exploring this space. I think a good start would be providing a mechanism to participate in a form submission. The accessibility object tree API would go a long way to address the accessibility concern, but providing the default accessibility role in `customElements.define` is also a great small step forward. We probably don't want to tackle all these issues in this thread though. Also, this is precisely why I was interested in the list of use cases. Because given use cases, we can come up with an iterative API which address each one of them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/509#issuecomment-281008352
Received on Monday, 20 February 2017 07:43:29 UTC