Re: Custom Elements: is=""

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

>
> On Jun 8, 2015, at 3:23 PM, Alice Boxhall <aboxhall@google.com> wrote:
>
> 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:
>> 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.
>
>
> Sorry, I don't follow.
>
> >> - 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.
>
>
> Perhaps I should have said "we can't _always_ make assumptions about how
> to expose that element to AT."
>
> Consider creating a date picker in the time we haven't added type=date
> yet.  Inside the shadow DOM of this color picker may contain various
> buttons and controls to move between months and pick a date.  Treating the
> entire control as a text field will provide a very poor user experience.
>

Ah, I see what you're saying now, thanks for clarifying.

In this case, the custom element author can add semantic markup inside
Shadow DOM just as the browser does for a date picker currently - no
assumptions need to be made, since even in the case of type extensions the
Shadow DOM is available to the accessibility tree. I don't think it will
ever treat the entire control as a text field.


> All the use cases I can think of that let UA can safely make assumptions
> about the ARIA role of the element involves tweaking the appearance, which
> is better served by better styling mechanisms for form controls.
>

I don't think it's an either/or question between is= and styling mechanisms
for form controls. I actually think we need both.

> >>> 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?
>
>
> See our replies on the topic on public-webapps.  I don't have a time to
> collect all our replies or restate all the problems we have with is=
> syntax.  (Perhaps I should put up a document somewhere to reference since
> someone brings up the same question every six months or so, and I'm getting
> sick and tried to even say that I don't have a time to re-iterate the same
> points over and over...)
>

If you did have time to put together such a document at some point, it
would be much appreciated!

I do absolutely realise that it's important to address the existing
concerns, but I've been having a really hard time trying to figure out
exactly what those are. (It's also unfortunately really difficult to search
for 'is=' when search engines strip out punctuation from search terms.)

> >> - 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.
>
>
> Well, not everything people propose as a standard becomes a standard.
> When a proposed standard is rejected, however, people tend to come up with
> an alternative proposal to address those issues.  As far as is= syntax is
> concerned, I haven't heard of any proposals to "fix" it so as to address
> everyone's concerns.
>
> If you're really passionate about this feature, I suggest you can go dig
> all the discussions we've had in the last three years and see if you can
> resolve all the concerns raised by various participants of the working
> group.  Now, some of those concerns we and others have raised may not be
> relevant, and they may have changed their positions and opinions on
> matters.  Regardless, I don't think keep saying you like (or that you think
> we need) this feature without proposing "fixes" to raised concerns is
> productive.
>
> - R. Niwa
>
>