- From: Joshua Peek <josh@joshpeek.com>
- Date: Thu, 11 Jun 2015 13:41:01 -0700
- To: WebApps WG <public-webapps@w3.org>
GitHub has been using tag extensions in a few places for progressive enhancement. Form and button elements have been the most useful things to extend the behavior of. "is=" syntax aside, I do agree extending complex native element prototypes in general has alot of associated undefined behavior. If "is=" is going to be dropped, we'll probably revert back to annotating these elements with special class names or data- attributes and avoid custom elements for these use cases. On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall <aboxhall@google.com> wrote: > > On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> >> On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall <aboxhall@google.com> >> wrote: >> > - In the time between v1 and v2 (however long that ends up being) we are >> > left without any way to solve this problem, assuming we don't come up >> > with >> > something else for v1. If developers start using custom elements where >> > they >> > would previously have used a native element, this could well result in a >> > regression in accessibility for the web as a whole for this period, and >> > we >> > will be stuck with the legacy of code written during this period for >> > much >> > longer as well. >> >> I don't see how it is a regression compared to the current situation. > > > Exactly: this describes the current situation, which I think is > unsatisfactory. > >> > - I realise that to some extent developers already aren't using native >> > elements, in part because of the styling issues we've discussed which >> > also >> > affect is=. My concern here is that custom elements will further >> > legitimise >> > this habit, which we've been making some recent progress in changing - >> > we >> > stand to backslide on that effort. Having is= would allow us to roll it >> > into >> > the "use native elements where possible" message rather than diluting it >> > with "unless you're using a custom element in which case here's a >> > checklist >> > which you're not going to look at of everything it should do" until we >> > come >> > up with an alternative. >> >> Most examples of custom elements to date are not actually with is="", >> simply because custom tag names are much more appealing. The >> ergonomics don't back up the message. > > > Polymer have a whole suite of elements which use is=: > https://elements.polymer-project.org/browse?package=gold-elements > > When you refer to "ergonomics", are you talking purely about the syntax? Or > about the set of issues involved in using native elements compared to (lower > case c) custom elements: essentially, whether or not you're ceding some > control over styling and behaviour to the browser? > >> > - v1 sets the stage for people to develop habits and expectations about >> > how >> > custom elements work. New features tend to be slowly adopted, by both >> > browser vendors and (partly as a consequence) developers, so even if we >> > do >> > come up with something for v2, it will be even longer before it becomes >> > mainstream (and as I mentioned earlier we will still be stuck with code >> > written to v1 for much longer again). >> >> I don't see how it will be longer. is="" is not getting acceptance >> as-is. So all this would result in is not getting custom elements >> across browsers until v2 is done. > > > I think Dimitri responded to this better than I could. > >> >> > Here's where we differ, because: >> > - I don't think it's a wart. I've given this a great deal of thought and >> > I >> > keep ending up back at the current syntax when I try to think of >> > reasonable >> > alternatives, even assuming we could magically fix all the >> > implementation >> > issues with any alternative proposal. >> >> I think if we figured out how the behavior of current elements is >> composed and how to address the styling problem we'd be much closer to >> an agreement. And I think everyone agrees those need to be solved, so >> I'm a bit lost as to why we don't focus on those. > > > I agree that those problems need to be solved (in particular, the styling > issue also comes into play when using is=), but I think that these are > multiple pieces of the same puzzle. > > The primitives are critical for creating novel types of elements, which > won't be able to benefit from type extensions in any case. Styling is > critical for getting people to use native elements with or without type > extensions. > > Allowing developers to extend native types means that users benefit from not > relying on custom element developers who just want to create a button with > some fancy rendering (beyond what can be achieved using CSS alone), or > custom behaviour, remembering to re-implement all of the accessibility > affordances which are built in to an HTML button. It also means that > developers benefit from not having to do the extra legwork for > accessibility. > > We see time after time after time that accessibility is fighting an uphill > battle because it isn't on developers' radars as a priority for v1. This > causes constant regressions in functionality for people who rely on > assistive technology. The promise of the HTML platform is that it should be > accessible if we use the native elements as they were designed to be used. > Part of my day job is helping make sure that the browser I work on upholds > its part of that bargain. > > You could argue that what we need is a way to wrap all of the accessibility > affordances of a button into a mix-in object; I really don't see a much more > efficient way to do that than extending a button element, either in terms of > creating the spec or in terms of using the object. > >> > - I don't think shipping in one browser is "nothing". People (both >> > framework >> > authors and web page authors) are already writing code using is=. >> >> Well, I disagree. E.g. Microsoft had a ton of features shipping in >> Internet Explorer 5.0 that were used and never ended up as-is (or at >> all) in other browsers. In the long run it's pretty close to >> "nothing". > > > I think Dimitri's response applies here as well. > > Many thanks, > > Alice >
Received on Thursday, 11 June 2015 20:41:32 UTC