Re: Custom Elements: is=""

We also have an extension of form which collects values from both native
and custom inputs.

On Thu, Jun 11, 2015 at 1:41 PM, Joshua Peek <josh@joshpeek.com> wrote:

> 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
> >
>
>