Re: Custom Elements: is=""

GitHub has been using tag extensions in a few places for progressive
enhancement. Form and button elements have been the most useful things
to extend the behavior of. "is=" syntax aside, I do agree extending
complex native element prototypes in general has alot of associated
undefined behavior. If "is=" is going to be dropped, we'll probably
revert back to annotating these elements with special class names or
data- attributes and avoid custom elements for these use cases.

On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall <aboxhall@google.com> wrote:
>
> On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>
>> On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall <aboxhall@google.com>
>> wrote:
>> > - 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 don't see how it is a regression compared to the current situation.
>
>
> Exactly: this describes the current situation, which I think is
> unsatisfactory.
>
>> > - 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.
>>
>> Most examples of custom elements to date are not actually with is="",
>> simply because custom tag names are much more appealing. The
>> ergonomics don't back up the message.
>
>
> Polymer have a whole suite of elements which use is=:
> https://elements.polymer-project.org/browse?package=gold-elements
>
> When you refer to "ergonomics", are you talking purely about the syntax? Or
> about the set of issues involved in using native elements compared to (lower
> case c) custom elements: essentially, whether or not you're ceding some
> control over styling and behaviour to the browser?
>
>> > - 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).
>>
>> I don't see how it will be longer. is="" is not getting acceptance
>> as-is. So all this would result in is not getting custom elements
>> across browsers until v2 is done.
>
>
> I think Dimitri responded to this better than I could.
>
>>
>> > 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 think if we figured out how the behavior of current elements is
>> composed and how to address the styling problem we'd be much closer to
>> an agreement. And I think everyone agrees those need to be solved, so
>> I'm a bit lost as to why we don't focus on those.
>
>
> I agree that those problems need to be solved (in particular, the styling
> issue also comes into play when using is=), but I think that these are
> multiple pieces of the same puzzle.
>
> The primitives are critical for creating novel types of elements, which
> won't be able to benefit from type extensions in any case. Styling is
> critical for getting people to use native elements with or without type
> extensions.
>
> Allowing developers to extend native types means that users benefit from not
> relying on custom element developers who just want to create a button with
> some fancy rendering (beyond what can be achieved using CSS alone), or
> custom behaviour, remembering to re-implement all of the accessibility
> affordances which are built in to an HTML button. It also means that
> developers benefit from not having to do the extra legwork for
> accessibility.
>
> We see time after time after time that accessibility is fighting an uphill
> battle because it isn't on developers' radars as a priority for v1. This
> causes constant regressions in functionality for people who rely on
> assistive technology. The promise of the HTML platform is that it should be
> accessible if we use the native elements as they were designed to be used.
> Part of my day job is helping make sure that the browser I work on upholds
> its part of that bargain.
>
> You could argue that what we need is a way to wrap all of the accessibility
> affordances of a button into a mix-in object; I really don't see a much more
> efficient way to do that than extending a button element, either in terms of
> creating the spec or in terms of using the object.
>
>> > - I don't think shipping in one browser is "nothing". People (both
>> > framework
>> > authors and web page authors) are already writing code using is=.
>>
>> Well, I disagree. E.g. Microsoft had a ton of features shipping in
>> Internet Explorer 5.0 that were used and never ended up as-is (or at
>> all) in other browsers. In the long run it's pretty close to
>> "nothing".
>
>
> I think Dimitri's response applies here as well.
>
> Many thanks,
>
> Alice
>

Received on Thursday, 11 June 2015 20:41:32 UTC