Re: Custom Elements: is=""

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

Nothing new.

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

Web developers are already writing their own "custom elements" as a bunch of nested div's.  How does introducing custom elements make it worse?

The argument that it'll make things worse between v1 and v2 is moot because we haven't agreed on anything. is= syntax may never be realized due to various issues associated with it.

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

In the case of stylizing elements, it doesn't really matter if authors attach a shadow DOM on top of a builtin input element or to a div because as soon as the shadow DOM replaces the rendered contents, we can't make assumptions about how to expose that element to AT.

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

FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly) spec'ed.

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

Some developers are always going to use a feature only implemented by a single browser (ActiveX in Trident, NaCl in Chrome, current web components implementation in Chrome). In fact, why would any browser vendor ship a feature that's not going to be used by anyone? However, that doesn't mean the feature will be standardized or adopted by other browser vendors.

- R. Niwa

Received on Monday, 8 June 2015 22:13:06 UTC