Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 8: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.)
>

Sure, that works for this example (which was created in a huge rush at the
last minute before a talk, like probably 90% of my productive work), but I
don't believe it wouldn't work for
http://www.polymer-project.org/components/paper-radio-button/demo.htmlwhich
has a fancy animation for changing states.

So, I naively ask, what's stopping us from standardising something like
-webkit-appearance: none? I think that a bunch of the most common
accessibility issues we see today come from people (quite justifiably)
re-implementing standard HTML elements in order to get the styling they
need - with or without using Custom Elements.