Re: Custom Elements: is=""

Did anyone have any further thoughts on this? My concerns haven't changed.

On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall <aboxhall@google.com> wrote:

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