WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

#20579 closed enhancement (fixed)

Adding HTML5 Input Types default styling to bundled themes

Reported by: georgestephanis Owned by: lancewillett
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.4
Component: Bundled Theme Keywords: has-patch
Focuses: Cc:

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)

Attachments (9)

20579.diff (3.4 KB) - added by georgestephanis 3 years ago.
20579.2.diff (4.2 KB) - added by georgestephanis 3 years ago.
Added in filter to use html5 input fields in comment forms. :)
20579.3.patch (11.7 KB) - added by bpetty 3 years ago.
20579.4.patch (10.6 KB) - added by bpetty 3 years ago.
20579.4-refresh.diff (10.5 KB) - added by DrewAPicture 3 years ago.
20579.5.twentytwelve.diff (2.2 KB) - added by lancewillett 3 years ago.
20575.5.twentyten.dif (1.2 KB) - added by lancewillett 3 years ago.
20575.5.twentyten.diff (1.2 KB) - added by lancewillett 3 years ago.
20575.5.twentyeleven.diff (1.4 KB) - added by lancewillett 3 years ago.

Download all attachments as: .zip

Change History (47)

@georgestephanis3 years ago

comment:1 @sabreuse3 years ago

  • Cc sabreuse@… added

comment:2 @helenyhou3 years ago

  • Component changed from Themes to Bundled Theme
  • Type changed from defect (bug) to enhancement

comment:3 @emiluzelac3 years ago

  • Cc emil@… added

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!

comment:4 follow-up: @georgestephanis3 years ago

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

comment:5 in reply to: ↑ 4 @emiluzelac3 years ago

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!

@georgestephanis3 years ago

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

comment:6 @mordauk3 years ago

  • Cc pippin@… added

comment:7 @helenyhou3 years ago

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

comment:8 @nacin3 years ago

  • Milestone changed from Awaiting Review to 3.5

comment:9 @ocean903 years ago

Related: #15080

@bpetty3 years ago

comment:10 @bpetty3 years ago

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.

comment:11 @bpetty3 years ago

  • Cc bpetty added

comment:12 @obenland3 years ago

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

@bpetty3 years ago

comment:13 @bpetty3 years ago

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.

comment:14 @sabreuse3 years ago

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.

comment:15 @mercime3 years ago

  • Cc mercijavier@… added

comment:16 follow-up: @lancewillett3 years ago

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.

comment:17 @nacin3 years ago

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

comment:18 follow-up: @nacin3 years ago

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

comment:19 @georgestephanis3 years ago

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.

comment:20 in reply to: ↑ 16 ; follow-up: @bpetty3 years ago

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.

comment:21 in reply to: ↑ 18 @bpetty3 years ago

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.

comment:22 @DrewAPicture3 years ago

  • Summary changed from Adding HTML5 Input Types default styling to twentyten and twentyeleven to Adding HTML5 Input Types default styling to bundled themes

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?

comment:23 @bpetty3 years ago

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.

comment:24 follow-up: @georgestephanis3 years ago

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

comment:25 in reply to: ↑ 24 @lancewillett3 years ago

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

comment:26 in reply to: ↑ 20 @lancewillett3 years ago

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.

comment:27 @lancewillett3 years ago

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

comment:28 @georgestephanis3 years ago

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

comment:29 @lancewillett3 years ago

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.

Last edited 3 years ago by lancewillett (previous) (diff)

comment:30 @georgestephanis3 years ago

Well, and twentyten isn't actually shipping with 3.5

comment:31 @lancewillett3 years ago

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.

comment:32 @lancewillett3 years ago

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

comment:33 follow-up: @bpetty3 years ago

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.

comment:34 in reply to: ↑ 33 ; follow-up: @lancewillett3 years ago

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.

comment:35 in reply to: ↑ 34 @bpetty3 years ago

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

comment:36 @lancewillett2 years ago

In 22897:

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

comment:37 @lancewillett2 years ago

In 22898:

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

comment:38 @lancewillett2 years ago

  • Owner set to lancewillett
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.