W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Minimum viable custom elements

From: Alice Boxhall <aboxhall@google.com>
Date: Fri, 30 Jan 2015 10:22:42 -0800
Message-ID: <CAMQHGLx3u3Z4eOQ+RgCa8LtOKGkM43BvqfjTdLiJuvVfFnM6Tw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Steve Faulkner <faulkner.steve@gmail.com>, Ryosuke Niwa <rniwa@apple.com>, WebApps WG <public-webapps@w3.org>
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.html
which 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.
Received on Monday, 2 February 2015 15:27:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC