Re: Custom Elements: is=""

And I'm still concerned that removing is= would severely harm the cases
where you need access to special parsing behavior like <template> and
<style>.

On Mon, Jun 8, 2015 at 2:16 PM, Alice Boxhall <aboxhall@google.com> wrote:

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