- From: Matthew Robb <notifications@github.com>
- Date: Wed, 22 Feb 2017 14:46:42 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/509/281830358@github.com>
> I think it's premature to try to come up with a set of compassable features like that. I think we need to first come up with a list of use cases that aren't adequately addressed by the current Web API (besides is attribute), and spec API for those. > >Once we have those primitive APIs to address use cases, I can see bundling some of them up to make it easily compassable seems as a sensible approach but perhaps this is an area we can leave to library/framework authors first. Once it became obvious that every library/framework is having some basic set of feature as a composable function/class, etc... then we can standardize them. > >In general, adding new features to browsers is a slow & painful process so we should be adding things that are already well vetted in JS library/framework. Honestly the use cases are equal to or greater than those of the built-ins themselves. We aren't sitting around justifying why anyone would ever want to provide input to a web page so why should we re-justify the use cases that drove each and every currently existing built in element and ultimately brought along special features to support those use cases. My WORRY about this `pave the cowpaths` argument is twofold. For one the cowpaths are already paved by the built ins which we can really just consider User-Agent Defined Custom Elements. If we solve each and every case one by one then we are narrowing our vision and likely to end up with many awkward solutions spread out all over the spectrum. I really think for this case it is considerably more practical on all accounts to come up with solution that is broad-sweeping. The use case: Allow developers to build custom elements with all the same affordances, conveniences, and behaviors to built-ins. Requiring a user-story other than this is a political movement that we all know will block or stall progress on this issue for YEARS if not indefinitely. -- 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-281830358
Received on Wednesday, 22 February 2017 22:47:43 UTC