Re: Custom Elements: is=""

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