Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell <bkardell@gmail.com> wrote:

>
>
> On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson <brucel@opera.com> wrote:
>
>> On 29 January 2015 at 14:54, Steve Faulkner <faulkner.steve@gmail.com>
>> wrote:
>> > I think being able to extend existing elements has potential value to
>> > developers far beyond accessibility (it just so happens that
>> accessibility
>> > is helped a lot by re-use of existing HTML features.)
>>
>> I agree with everything Steve has said about accessibility. Extending
>> existing elements also gives us progressive enhancement potential.
>>
>> Try https://rawgit.com/alice/web-components-demos/master/index.html in
>> Safari or IE. The second column isn't functional because it's using
>> brand new custom elements. The first column loses the web componenty
>> sparkles but remains functional because it extends existing HTML
>> elements.
>>
>> There's a similar story with Opera Mini, which is used by at least
>> 250m people (and another potential 100m transitioning on Microsoft
>> feature phones) because of its proxy architecture.
>>
>> Like Steve, I've no particularly affection (or enmity) towards the
>> <input type="radio" is="luscious-radio"> syntax. But I'd like to know,
>> if it's dropped, how progressive enhancement can be achieved so we
>> don't lock out users of browsers that don't have web components
>> capabilities, JavaScript disabled or proxy browsers. If there is a
>> concrete plan, please point me to it. If there isn't, it's
>> irresponsible to drop a method that we can see working in the example
>> above with nothing else to replace it.
>>
>> I also have a niggling worry that this may affect the uptake of web
>> components. When I led a dev team for a large UK legal site, there's
>> absolutely no way we could have used a technology that was
>> non-functional in older/proxy browsers.
>>
>> bruce
>>
>>
> Humor me for a moment while I recap some historical arguments/play devil's
> advocate here.
>
> One conceptual problem I've always had with the is="" form is that it adds
> some amount of ambiguity for authors and makes it plausible to author
> non-sense.  It's similar to the problem of aria being "bolt on" with mix
> and match attributes.  With the imperative form of extending you wind up
> with a tag name that definitely is defined as subclassing something
> "<super-button> 'inherits' from HTMLButtonElement and I'll explain how it's
> different".  With the declarative attribute form you basically have to
> manage 3 things: ANY tag, the base class and the final definition.  This
> means it's possible to do things like <iframe is="button"> which likely
> won't work.  Further, you can then proceed to define something which is
> clearly none-of-the-above.
>

The is@ only works on the element you defined it to apply to, so <iframe
is="button"> does nothing unless the element "button" was registered as a
type extension to "iframe". I don't see that as any more error prone than
writing <paper-buton> instead of <paper-button>.

Also fwiw most "share" buttons on the web are actually iframes, so <iframe
is="facebook-button"> makes total sense.

- E