Re: Custom Elements: is=""

On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall <aboxhall@google.com> wrote:
> > I definitely acknowledge is= may not be the ideal solution to the latter
> > problem - it definitely has some holes in it, especially when you start
> > adding author shadow roots to things - but I think it does have
> potential.
> > I'd really like to be convinced that we either have a reasonable
> alternative
> > solution, or that it's not worth worrying about.
>
> I think it is worth worrying about, but I don't think it's worth
> holding up a minimal v1 of Custom Elements for. The way to get
> agreement among all parties is to do less. And then take baby steps
> from.
>

I can definitely see that logic.

My concerns with this in practice are:

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

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


> The way I look at this is that currently you have nothing, since only
> Chrome ships this. There's a chance to get three more browsers if you
> make some concessions on the warts. And then hopefully we can iterate
> from there in a more cooperative fashion.
>

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 don't think shipping in one browser is "nothing". People (both
framework authors and web page authors) are already writing code using is=.


> (The thread Steve shared about ARIA seemed like an equivalent effort
> by the way, to expose some of the semantics of native elements through
> simple attributes.)
>

Thanks for the pointer - I followed up on that thread with some thoughts on
that proposal.