Re: Minimum viable custom elements

The -webkit-appreance CSS is definitely another issue, so here's an example
with just JS behavior:

<input is="number-input" decimals="2">

This component would only allow numeric input, and insert decimals, commas,
etc. Let's just assume that devs want to do this kind of thing. Here's an
example I found of a such behavior:
http://opensource.teamdf.com/number/examples/demo-as-you-type.html

The best thing you get from using a Custom Element here is the component's
ability to automatically initialize (and destroy) itself. If it's inserted
into the page dynamically (via AJAX, templates in a SPA, or whatever), it
just sets itself up. If JS fails, you've still got an input. It was
succinct and easy to set up. And if the app wants to get or set the value,
it just does it the same way it always interfaces with an input.


Alternative 1: no Custom Element:

<input class="number-input" decimals="2">

The downside here is that there's no automatic initialization/destruction.
Which is ok if the element is never dynamically inserted, but not so great
when it is - you're going to have to call a function to initialize it.


Alternative 2: regular Custom Element:

<number-input decimals="2"></number-input>

When this thing initializes, let's say it adds a native <input> as a child
(or in a shadow root), so that it doesn't have to manually add all the
necessary accessibility items Steve has pointed out. Of course, you get
nothing if JS fails. As a backup, you could certainly ask page authors to
add the <input> themselves - but that's starting to defeat the goal of
having simple declarative custom elements (if that is indeed a goal). Maybe
it wouldn't be the end of the world though:

<number-input decimals="2"><input></number-input>

Brian also mentioned the possibility of server-side rendering of the
createdCallback, but that certainly won't be feasible for everyone's
server-side environments.

Additionally - you'll need to create an API on the <number-input> so the
app can get and set the value. Of course you'd be doing this anyhow with
any regular Custom Element - but it'd be nice to skip if you could.


Anyhow - point is just that I see value in the ability to add Custom
Element callbacks to native elements. Thanks for all your work on
everything here!


Chris Bateman



On Fri, Jan 30, 2015 at 10:46 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
> > In this radio and checkbox example (view in chrome)
> > https://rawgit.com/alice/web-components-demos/master/index.html
> > (which has been referenced several times in this thread, but no one has
> > critiqued to my knowledge) all of the above are evident, while at the
> same
> > time appearing to overcome the issue of standard control fugliness
>
> The only way it overcomes that is by relying on a proprietary
> extension called -webkit-appearance that is not standardized and does
> not work reliably across browsers. Furthermore, it's not at all clear
> to me why that example needs custom elements to begin with. If we
> assume this proprietary extension exists, we can just do this:
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
>
> Which is much much simpler and requires none of the HTML imports,
> shadow tree, and all that script. It's also fully accessible and
> backwards compatible to the same extent. And shows that the real
> tidbit here is -webkit-appearance and not custom elements at all.
>
> (For identical styling you need to move the background-image line into
> a distinct input:checked selector block. I messed up a bit with copy
> and pasting.)
>
>
> --
> https://annevankesteren.nl/
>
>