- From: Bruce Lawson <brucel@opera.com>
- Date: Thu, 29 Jan 2015 15:33:52 +0000
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "Edward O'Connor" <eoconnor@apple.com>, WebApps WG <public-webapps@w3.org>
On 29 January 2015 at 14:54, Steve Faulkner <faulkner.steve@gmail.com> wrote: > I think being able to extend existing elements has potential value to > developers far beyond accessibility (it just so happens that accessibility > is helped a lot by re-use of existing HTML features.) I agree with everything Steve has said about accessibility. Extending existing elements also gives us progressive enhancement potential. Try https://rawgit.com/alice/web-components-demos/master/index.html in Safari or IE. The second column isn't functional because it's using brand new custom elements. The first column loses the web componenty sparkles but remains functional because it extends existing HTML elements. There's a similar story with Opera Mini, which is used by at least 250m people (and another potential 100m transitioning on Microsoft feature phones) because of its proxy architecture. Like Steve, I've no particularly affection (or enmity) towards the <input type="radio" is="luscious-radio"> syntax. But I'd like to know, if it's dropped, how progressive enhancement can be achieved so we don't lock out users of browsers that don't have web components capabilities, JavaScript disabled or proxy browsers. If there is a concrete plan, please point me to it. If there isn't, it's irresponsible to drop a method that we can see working in the example above with nothing else to replace it. I also have a niggling worry that this may affect the uptake of web components. When I led a dev team for a large UK legal site, there's absolutely no way we could have used a technology that was non-functional in older/proxy browsers. bruce
Received on Thursday, 29 January 2015 15:34:20 UTC