Re: Custom Elements: is=""

On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

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

I believe the rest of my comment already addressed this.


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

This was in response to Anne's suggestion to "take baby steps". If this is
going to happen at all, I believe it needs to happen in V1 rather than
later, for the reasons I outlined.


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

That's simply not true at all. If someone replaces the rendered content of
a `<button>`, we know that their intent is to create an element which is
semantically a button, and may even be rendered as a button in some cases.
Similarly for `<input>` with a `type` attribute. This is no different to
using an ARIA role as far as assistive technology is concerned.


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

Any chance you could go into more detail on that? What exactly is it you
dislike about it?


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

No, but unlike the first two examples, this is a proposed web standard.

Thanks,

Alice