- From: Ryosuke Niwa <notifications@github.com>
- Date: Wed, 22 Feb 2017 02:54:49 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 22 February 2017 10:55:45 UTC
> > it's probably best to let Web developers experiment it first > > We cannot extend native builtins so how/what are we supposed to experiment, exactly? I'm not suggesting to start experimenting anything right now. The first step is to expose native builtin elements' capabilities as mandated by use cases. > * extend native builtins This is not a use case. A use case would must be an user scenario which one may wish to extend native builtins to address. > * define table rows as custom elements Again, this is not a use case. A use case would be an user scenario in which one may wish to customize table rows, and for which one may wish to address it by defining it as a custom element. > * use smarter img tags Again, this is not a use case, and did you actually want to change some parser behavior with respect to `img` or you meant to say `img` elements? If so, what do you want to change about `img` elements? > * inherit aria Setting the default ARIA role is something I've suggested time and time again. Here's an actual use case: I wish to create a toolbar component and set the [toolbar ARIA role](https://www.w3.org/TR/wai-aria/roles#toolbar) without having to add a content attribute visible to the component users. -- 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-281635998
Received on Wednesday, 22 February 2017 10:55:45 UTC