Degrade HTML5 Inputs

[scottgonzalez]

The new HTML input types are great, but they really suck when writing UI widgets. CSS3 System Appearance is important, but seemingly ignored by browser vendors.

Here are snippets from a long email thread related to this:

Scott González:
As you're probably all aware, in jQuery Mobile we degrade the new HTML input types to avoid getting the new UIs. I was going to email the WHATWG asking for a way to keep all the semantics and validation that comes with the new input types, but opt-out of the improved UIs. Then I found out about CSS3 System Appearance. Unfortunately, this doesn't seem to be well supported. Are you guys able to provide any insight into how the browser vendors feel about this spec (importance, priority, missing features, etc.)?

I don't like using the new input types because they're much harder to enhance and I know I'm not alone here. Having good support for falling back to text fields could go a long way.

Thanks.

Scott Jehl:
Just to add to this… we've set it up to degrade certain types to types other than "text" in some cases. For example, @type=range falls back to "number" once we append our slider, which allows us to keep the numeric keyboard and min/max attributes. Still, it means we have to deal with buggy @type=number implementations alongside our slider now… :/

Mike Taylor:
I can't speak for Opera beyond what I know--but Bruce Lawson is trying internally to get someone to work with Tentek Celik (now at Mozilla) as a co-editor of the CSS3 UI module, possibly Lachlan Hardy. As for how long it will take us to implement support for -o-appearance {} or just appearance {}, I have no idea, but I believe we'll get there.

Rey Bango:
From what I’ve read, most browser vendors are supporting what they believe are a consistent experience for these new controls and don’t recommend modifying the UI/UX because they want users to have a consistent experience regardless of which browser they use. So if a user launches Chrome, the experience they get from a datepicker should be similar to what they’d get in FF, Opera, IE or Safari.

Scott González:
The problem is that no matter how consistent the UI/UX is, I want to opt-out because it will never be good enough. I want to customize the UI to look like my app, layer on additional functionality, etc. All of this is possible today without the new input types. However, once the new input types are used, this becomes more difficult. For example, enhancing a text field into a datepicker is really common, but you can't do this with a date field because of the new UI. I really don't think that JS implementations of these input types are ever going to die, no matter how good the native implementations work. There's just too much functionality that users will want that won't be possible because the APIs would be too large to spec. Falling all the way back to text fields works, but then we lose all the other benefits, such as the new attributes/methods, built-in validation, type-specific virtual keyboards, etc.

So the end goal is still to have consistent UI/UX cross-browser, but not necessarily cross-site.

Paul Irish:
I've seen a lot of people use the prefixed -webkit-appearance to great effect.
http://trentwalton.com/2010/07/14/css-webkit-appearance/

But I have no seen a prefixed moz or o in action, so I imagine we're waiting there.
Still, this should get you pretty far on target devices.

Mike Taylor:
Scott, I think you should email the WHATWG, as you make great points. I'd love to point to your email internally and say, look--people want this, etc.

Rey Bango:
Yep agreed. I’d like to do the same.

Paul Irish:
Do eeet.

Scott González:
Sure, I can email WHATWG but I'm pretty sure the immediate response
will be either 1) this is a CSS issue and therefore doesn't belong in
this list or 2) this is already spec'd, lobby the browser vendors.

I know I can make a solid argument for having this feature, but
knowing that the functionality is already spec'd I'm not sure how to
proceed through WHATWG.

[scottgonzalez]

The new plan is for this to be handled with Web Components. We'll keep this open until there's at least one implementation which proves this works.

[tjvantoll]

I'm very curious how web components are supposed to solve these issues. All we have right now is vendor specific pseudo-elements that we can hide, which is no solution at all.

After talking with @scottgonzalez the only potential option seemed like replacing the browser provided shadow DOM with a custom one. But this doesn't work.

<input type="date">
<script>
    var input = document.querySelector( "input" );

    console.log( input.webkitShadowRoot ); // null

    // HierarchyRequestError: DOM Exception 3 
    input.webkitCreateShadowRoot(); 
</script>

The shadow DOM root on <input> elements is not exposed and is not replaceable. I have only tested in Chrome canary and Chrome stable, so this might be an implementation issue, but no other browser has support for shadow DOM yet.

Even if we are allowed to completely replace a shadow DOM, there are still questions of how that would integrate with other native functionality such as constraint validation.

[leobalter]

We'll keep this open until there's at least one implementation which proves this works.

@scottgonzalez have we got any update on this?

[scottgonzalez]

As far as I know, there is still no plan for how to handle things like <input type="date"> with custom elements.

[leobalter]

thanks. I'm leaving this open