Re: Minimum viable custom elements

> On Jan 30, 2015, at 10:22 AM, Alice Boxhall <aboxhall@google.com> wrote:
> 
> On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren <annevk@annevk.nl <mailto:annevk@annevk.nl>> wrote:
> On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
> <faulkner.steve@gmail.com <mailto:faulkner.steve@gmail.com>> wrote:
> > In this radio and checkbox example (view in chrome)
> > https://rawgit.com/alice/web-components-demos/master/index.html <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 <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 <http://www.polymer-project.org/components/paper-radio-button/demo.html> which has a fancy animation for changing states.

It doesn’t but how does custom elements solve that problem?  This example doesn’t even seem to use “is” and manually sets ARIA attributes.  Could you clarify exactly which accessibility issues custom elements would solve in this example?

> 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.

Indeed.  It would be really useful to solve this problem either with a CSS property like -webkit-appearance or decorator.  Perhaps Tantek or Fantasai could enlighten us.

Relevant URLs:
https://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=appearance&search=Search <https://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=appearance&search=Search>
https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html <https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html>
https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html
https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html

- R. Niwa