Can we make it easy to decorate native HTML UI?

disclaimer: I do not understand the complexities of how browsers implement UI stuff and therefore how hard it is to implement a solution and the scope of my thinking about this issue is limited by this.

Over on the w3c webapps mailing list there has been discussion about 'minimum viable custom elements. One of the current features in the custom elements spec is the ability to subclass elements using is="". This is not liked by some implementers and looks like it will go away. The benefit of being able to subclass is that it allows developers to re-use the features built in to existing elements. This is useful from an accessibility perspective as it does not involve having developers re-implement the accessibility stuff already built-in. A downside to is= is that it does not resolve the issue of being able to decorate native elements as desired, so developers are very likely to continue to eschew subclassing in favour of remaking.

I had a look at some of the major web component libraries (polymer core and paper, bosonic etc.) (and like custom JavaScript UI libraries, jQuery UI etc.) a good 50% of the widgets they provide are remakes of native controls (buttons, checkboxes, radio buttons, slider, progress, select etc). Related discussion article emulating failure

I think if we could provide a relatively simple and attractive method to allow the use of native HTML controls to provide the ‘engines’ for custom elements, it could be of great benefit.

I created a simple (visually crude) example of what i mean using <canvas>. I am not putting this forward as a possible solution, but it does for me, illustrate the benefits of being able to use a native control without concern for the limitations of its visual display.

I don’t know if a solution should be provided in via CSS (appearance for example) or HTML, but I do think that the solution should be relatively simple to use (for web devs) and relatively simple to implement (for browser devs). We should be speccing and implementing reasons for web developers to use native controls not speccing and implementing reasons for not.

disabuse welcome!

It seems that fixing appearance:none by writing tests for it and getting it in all browsers will go a long way towards addressing this concern. Coupled with getting pseudo-elements to address the various components of a form control might make this good enough.

Thanks for addressing this issue with custom elements and your persistence to do so. It’s essential to be able to plug into native elements, either by extending them using custom elements or by decorating them with CSS. Failing to do so will cause a flood of crappy components on the web. I’d hate to see that happen. I’d also hate to reimplement basic browser functionality each time a native component comes to life.

Is there a way regular web developers like myself can make your message resonate in places that matter?

The info on the CSS wiki notes that appearance:; has been around since 2004. It would be good to understand what has prevented it from making it into CSS Recc - so any rethinking needed to overcome the obstacles could be done.

The main problem is lack of interest I think. The CSS WG has several times rejected working on form controls (they are out of scope because of their complexity) and nobody is really picking it up.

Were someone to define the layout model of form controls and how CSS properties ought to effect that I’m sure we can find implementers willing to clean up their act.

It’s essential to be able to plug into native elements, either by extending them using custom elements or by decorating them with CSS.

“plug into” could mean a lot of things - I guess my position on this depends on what you mean. A number of discussion (steve linked to some of the threads above) seem to have shown that it’s not actually necessary to extend in the programmatic sense in order to create a custom element which uses built in instead of bolt on functionality. In factm Steve showed one such example more or less above which uses composition. Composition is very often preferable to inheritance anyway. So, for example, you could create a custom element which used a native control child as input and that has pretty much all of the same advantages that extending does and maybe some more too in the sense that when you create richer controls that claim to actually be something else, you somewhat break the sense of what precisely is doing the acting as what. So we’re talking about:

<input is="x-check">

<!-- vs --->

<x-check>
    <input type="checkbox">
<x-check>

Both types of advice are pretty easy to give/describe.

Of course, you can do all of these things today, there are some examples, steve shared one.The problem historically is mostly that they are receipe based or require some very particular library or framework. On the flip side, people have created considerably easier ways to get it wrong.

So, the benefit of custom elements is that it can make it just as easy to do the right thing (as a page author, not a custom element author).

I know this sounds a little like handwaving away because there have been some prominent initial examples of custom elements which failed the accessibility test, but developers really do all want to do the right things - they’ve got other shit to do and it saves them time (and money) to reuse something where someone else has done the hard work. I truly believe that custom elements, without extending, is still a phenomenal game changer in that the community can work together to figure it out and some amount of experimentation is good - failure is an essential ingredient to eventual success.

CSS WG is way over-stretched and, to be entirely honest, it’s harder than you’re imagining to get this right. IMHO, if they took it up, they might likely not get it right and it would very likely take a long time. Conversely, we can work together to build increasingly excellent custom elements in the meantime and provide useful information necessary to help them get it right.

Jan Miksovsky provided an approach that may or may not have legs https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0618.html