Adding HTML5 Input Types default styling to bundled themes

[georgestephanis]

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)

[emiluzelac]

This is just great George, I did add this to my Theme, but not as much as you have in diff. Definitely good thing to do for sure!

[georgestephanis]

If you'd like to see the result of each of these rules, just paste the linked code into a new post --

​http://cl.ly/2E3M103q1V2s3k1Z0X1w

[emiluzelac]

Replying to georgestephanis:

If you'd like to see the result of each of these rules, just paste the linked code into a new post --

​http://cl.ly/2E3M103q1V2s3k1Z0X1w

Keep it up George I really like it!

[georgestephanis]

Added in filter to use html5 input fields in comment forms. :)

[helenyhou]

Closed #21757 as a duplicate, which also has a patch.

[ocean90]

Related: #15080

[bpetty]

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.

Also, since it's been 5 months, the updated patch skips Twenty Ten (maybe older sites really don't want the HTML5 additions), instead opting for updates to Twenty Eleven and now also Twenty Twelve.

One other addition is that this same change is now also handled in the editor styles for both themes.

Like the last patch, this fixes #15080 as well.

[obenland]

I'm no fan of str_replacing input types. This should be addressed in #15080 rather than in individual themes.

[bpetty]

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.

[sabreuse]

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.

[lancewillett]

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.

Here's a full list of the input types to cover: ​http://www.w3.org/TR/html-markup/input.html

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.

[nacin]

I agree with lancewillett's comment on all counts. I would also add "number" to that list.

[nacin]

It looks like HTML5 Boilerplate takes a similar approach: ​https://github.com/h5bp/html5-boilerplate/blob/master/css/normalize.css#L345.

[georgestephanis]

My only concern is legacy browsers that don't support the full range of regex selectors in css. As long as it degrades well for them, I'm happy.

[bpetty]

Replying to lancewillett:

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.

Replying to lancewillett:

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.

Replying to lancewillett:

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.

[bpetty]

Replying to nacin:

It looks like HTML5 Boilerplate takes a similar approach: ​https://github.com/h5bp/html5-boilerplate/blob/master/css/normalize.css#L345.

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.

[DrewAPicture]

It seems like there's still contention over whether to blanket-style all input types or cherry pick based on each theme's individual needs (blacklist). How can we move this ticket forward?

[bpetty]

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.

[georgestephanis]

So ... back to the original 20579.diff patch then?

[lancewillett]

Replying to georgestephanis:

So ... back to the original 20579.diff patch then?

Nope. I don't agree with bpetty that using a blacklist is out of the question. I'll work on a patch that uses attribute selectors to simplify the code.

That said, this isn't urgent for 3.5 -- really the only thing that we should fix now is Twenty Eleven, see part-way patch on #21757 (it's missing the dark.css rules).

[lancewillett]

Replying to bpetty:

Replying to lancewillett:

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.

[lancewillett]

Patch in 20579.5.twentytwelve.diff​ changes to blacklist method, only overriding the non-textual input types. Also adds better button support which wasn't there before.

I put up a quick test page at ​http://themebuster.wordpress.net/form-inputs-test/ for browser testing (this patch is applied there).

Should work in all browsers since no fancy attribute selectors were needed. :)

[georgestephanis]

Awesome, looks good. I forgot that IE7 supported attribute selectors. Tested it in IE7, 8, 9 -- all clean, except for your image input which is missing a src attribute. ;)

[lancewillett]

20575.5.twentyten.diff adds very basic support for Twenty Ten. I don't think we should go any further there, it risks breaking too much and there are now two newer default themes.

[georgestephanis]

Well, and twentyten isn't actually shipping with 3.5

[lancewillett]

20575.5.twentyeleven.diff adds basic support to Twenty Eleven -- no need to style extra input types in the comment form at this point since they are all "text" in core.

[lancewillett]

Philosophy and thinking behind these latest 3 patches:

1. Twenty Twelve is new enough to rework the selectors to style all inputs, then reset with a blacklist. The other two are too entrenched, in my opinion -- to rewrite the selectors now.
2. Some support is better than none, so Eleven and Ten get support for the most common: text, password, email, url, and number.
3. I don't think a default theme needs to blanket support every edge case (like the "search" type Webkit fixes) -- let's leave that to child themes and plugins to solve their specific problems

[bpetty]

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.

[lancewillett]

Replying to bpetty:

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.

[bpetty]

Replying to lancewillett:

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

[lancewillett]

In 22897:

Twenty Ten: style a few more input types, and fix missing quotes around types in selectors. See #20579.

[lancewillett]

In 22898:

Twenty Eleven: style a few more common input types. See #20579 and #21757.

[lancewillett]

In 22899:

Twenty Twelve: change form input selectors to only reset non-textual input types, allowing for broader support for newer HTML5 input types. Also add better button support. Fixes #20579.