Adding HTML5 Input Types default styling to bundled themes

Description

Just cross-applying pre-existing rules to new input field types, and adding in one minor one to normalize input[type="search"] in webkit (that was previously tested, applied, and committed on the back-end)

Just being a little more consistent, the patch just uploaded supports all the same HTML5 input types that the last patch covered, except they are covered for every rule they should be supported in instead of just a few key ones.

Well, since Nacin mentioned that this should still actually update Twenty Ten as well, here's an updated patch that adds styles, but doesn't touch the comments form, and we can discuss the approach on using HTML5 comment forms separately.

The .4 patch fixes an issue that was reported on #15080 (switching the comment form to HTML5 badly threw off the styling of the form in Twenty Eleven). +1 to committing this one in addition to the #15080 fix.

I think a smarter approach to this would be to use a CSS selector to blacklist the input types we don't want to apply styles to: checkbox, radio, submit, button, color, file ... so something like input[type^=checkbox]. That'd make it much cleaner, and also benefit us when newer types are added in the future -- they'll look great without having to be explicitly added to the stylesheet.

Note: I also think we take a pragmatic approach, and just patch up the most common and the ones most likely to occur in WordPress output: email, url, password, text and just leave the rest to plugins or child themes to add if needed.

I think a smarter approach to this would be to use a CSS selector to blacklist the input types we don't want to apply styles to: checkbox, radio, submit, button, color, file ... so something like input[type^=checkbox].

Except that input[type^=checkbox] does not mean "not this type", it represents an input element with the type attribute whose value begins with the prefix "checkbox". In fact, there isn't even a CSS3 selector that works for doing a blacklist on attribute values.

Maybe you're thinking about jQuery [type!="checkbox"] selectors? Even if we did use that (and we shouldn't), we'd still need to specify 10 different types.

That'd make it much cleaner, and also benefit us when newer types are added in the future -- they'll look great without having to be explicitly added to the stylesheet.

That's assuming all new input types added in the future used a regular text box style input that these styles are designed for. That's exactly 13 out of the 23 current ones. It's impossible to say, but that might indicate maybe a little more than a 50/50 chance.

Note: I also think we take a pragmatic approach, and just patch up the most common and the ones most likely to occur in WordPress output: email, url, password, text and just leave the rest to plugins or child themes to add if needed.

I really did want to go this direction at first, but when it comes down to it, it's the theme's responsibility for styling everything. And if you look at this from a plugin developer's point of view, it's impossible to just assume that one style is going to fit all themes, nor is it possible to know if another theme is already providing these styles for other purposes as well.

That's just for normalization, it's not a theme. Every style there can either apply to the search field only, button types only (and on the button types, they do specifically name all of them off just like we're doing here with textfield types), or all inputs entirely.

It generally seems agreed that the HTML5 input type styles need to be in these themes, obviously for the most common ones at least (email, url, text, password - all planned to be used in core for existing frontend forms).

I still don't see a solution here that actually works for blacklisting the type styles, there isn't even a patch here that does it. So I don't think that's an issue moving forward.

To clarify, this has nothing to do with choosing specific ones per theme, every theme needs the same selector set, they just need those selectors on the textfield input styles already specified for each each theme.

So, I think the only issue being debated here is whether to provide the additional HTML5 input type styles (besides email, url, text, and password) for form inputs not being used by core so that plugins can use them with the default theme without requiring the end user to manually create a child theme with the styles when they install one of those plugins.

We already need to provide at least 4 of the types, and it's an incredibly simple patch, it's just that it only seems a little verbose since this patch is adding them for 3 different themes all at once. It's really not any different or more verbose than providing the vendor-prefixed background gradients though.

In fact, there isn't even a CSS3 selector that works for doing a blacklist on attribute values.

Oh, you're right about [att^=val] -- that is "begins with". I was thinking of :not() which is in CSS3 but no support in IE8 and early IE versions. See ​http://www.w3.org/TR/css3-selectors/#negation. But, even then it doesn't look like it takes multiple selectors as arguments.

Search is one other field that is used in core that will eventually make the transition to using the HTML5 search input type at some point down the road, so I don't see any reason we shouldn't also get the -webkit-appearance: textfield; fix for Safari in there along with -webkit-search-decoration so that the versions of the themes released with this fix are ready to go when the update with that switch is eventually pushed out years from now.

Search is one other field that is used in core that will eventually make the transition to using the HTML5 search input type at some point down the road, so I don't see any reason we shouldn't also get the fix for Safari in there

No thanks ... as I mentioned earlier, it's an edge case and not necessary right now. We can cross that bridge when we get to it down the road.

No thanks ... as I mentioned earlier, it's an edge case and not necessary right now. We can cross that bridge when we get to it down the road.

That's the point. I'm looking through a telescope at the bridge right now, and even if we can cross it, we'll have less options open on how we do it if this isn't in here now. From the point in time that this is finally added to the default themes, or the default themes all add searchform.php (which Twenty Twelve hasn't, at least Twenty Eleven did though), the next step might be waiting another 3+ years until those themes are in wide use before a switch to the HTML5 search input type can be considered again.

It's a fix to a bug we don't have yet, but we will, and there's very few clean options open without making things more difficult than they need to be. I'm just trying to be a little pro-active and leave one more option open for when we get there. Without it, we might end up making less-than-ideal changes to support it later (probably still will for the sake of other themes, but it's not like adding these here is actually hurting anyone).