Re: Minimum viable custom elements

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.

With the imperative form you can pretty clearly grok it and avoid a class
of errors which you couldn't otherwise.  Still, getting this right in
implementation is actually really hard and, as such, will require a lot of
debate - similarly, because it's kind of 'mix in' oriented (that is, what
you have is 'features of a button which are, unfortunately potentially
based on complicated DOM which isn't a button) it's still further
complicated to figure out the right thing to base off of... Only in a
vanishingly small number of cases like the oft repeated 'custom button' is
this not the case, but even there you can imagine that if you really need
to extend a button, you're asking for 'more than a button' and it might get
swampy.

Let's imagine you have none of that though and you want a custom button
which involves some dom that isn't just 'button'.  How would you write it?
Most likely through composition - that is, it would likely -contain- a
button.  This is considerably simpler and in many ways more intuitive and
it has approximately the same accessibility benefit as far as I can tell.
It's probably not 'the best we can do' but it might not be a bad start if
we had to start there.

With regard to 'what about if you have javascript turned off' - again,
there are a class of problems where there are easy to employ patterns and a
class of problems where that is just not the case and can't be.  I think we
have to be very cautious about that.  If you have a custom element with a
src="" attribute, for example, the best you are going to be able to do is
graceful degradation with the stuff kinda already built into HTML - things
like noscript and unknown element stuff.  As for pre-renderers, what I've
described isn't so complicated that I think pre-renderers can't get it
right, but maybe I am misunderstanding.






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