Re: Minimum viable custom elements

On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn <esprehn@chromium.org>
wrote:

>
>
> 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>.
>
> In other words, if there are 350 elements in HTML - in 349 you could say
is="button" and it would do nothing.  This isn't possible with the pure tag
form, it either is or isn't the tag.  This is all I described - ambiguity
for authors and ability to author nonsense.  Maybe it is 'benign' nonsense
but it's nonsense and potentially frustrating in a way that misspelling a
tag isn't IMO.


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

youre somewhat locked into thinking that because it's how we've dealt with
things, don't you think?  I mean <button is="iframe"> might conceptually
work too, but we know that they're iframes for SOP/isolation reasons.  That
said, what exactly would you add to your custom element facebook-button
that adds value then?  ... Like... what could you legitimately do with that
that you couldn't do with <iframe class="facebook-button">?  Would it
actually submit a form in *your* page, would your focus act the same, etc?
I'm asking for real because I think the use-cases are on the small end of
limited

I'm not saying it's better or worse, I'm actually trying to take the devils
advocate position here because there might be something beneath it worth
thinking about...  It does seem that composition actually seems to let you
express something equally good without ambiguity more easily except insofar
as giving you a really first-class fallback option if you don't support JS,
but... I'm having a really hard time imagining more than 3-4 cases  where
that's really a useful thing.



> - E
>



-- 
Brian Kardell :: @briankardell :: hitchjs.com