Change History (67)

I looked into this a few weeks ago, saw some things I did not like and decided to forget about it for now.

I do not recollect exactly what the things I did not like were, but something that stands out is that more and more browsers(1) start acting on these input types. One important thing they do is validation. They do that in different ways, and sometimes things go very wrong:

I tested in opera 10.62 and both .in and .eu domains work fine. I think that was an old bug.

It is not that old (it was reported 3 months ago) and, in any case, I only mentioned it as an example. There are more issues and strange bits of behaviour. If you play a bit with desktop browsers that understand these types, you’ll see that current implementations are not such that you would want to trust them with your user’s experience. This thing is new and we should expect issues to keep popping up while it is new.

I know about the iPhone keyboard adjustment and I agree that it is a smart and useful thing, but mobile themes can, and do, take care of that. Both WPtouch and WPtouch Pro, for example, use the new input types. WPtouch since March 2010; WPtouch Pro since its first release.

Sites that want to use xhtml or html4 should be required to filter the content. Twenty Ten is html5.

comment_form is not a Twenty Ten function. It is a core function meant for all themes.

Expecting themes to use filters so that they generate valid XHTML 1 or HTML 4 does not seem like a sound approach to me.

The submitted patch is not valid HTML5 but irregardless, the HTML5 specification is still under development, browser support is not universal, and the core should not be imposing a particular DOCTYPE on users. Anyone who wants to use HTML5 now should know enough to be able to write their own form.

There isn't going to be some magic moment where everyone is officially encouraged to start using new HTML features. After Firefox 4 and Internet Explorer 9 are released, things are going to get interesting. We can make these calls on a case-by-case basis.

Out of curiosity, how well does 15080.patch​ work when the theme in use does not use an HTML5 doctype in various browsers? Need to consider that various themes could be using any of HTML4, XHTML, or HTML5 assuming this change is going to be globally done. Also consider that this would technically be breaking compatibility for older themes possibly.

I'd love for this to be a global change like the patch here, but in the interest of compatibility, this might still be best handled per theme as implemented in older patches on #20579.

I like this conceptually, but some third party themes may be styling the comment form how twentyten and twentyeleven currently do -- input[type=text] -- which would break if we did this, as the css rules aren't in place to handle it.

Personally, I'd like to see the theme itself dictate a transition to html5 input types.

So a problem I noticed with 15080.args.diff from georgestephanis is that we don't add the pattern attribute to the html5 fields or the novalidate attribute to the form field (see earlier discussion on concerns with browsers auto validating). I've added that along with also adding the required property when we are in html5 comments and the field is required.

Just added 15080.3.diff -- a retooling of Jorbin's last patch. Still uses the input_builder function (slightly tweaked) as well as tidies up some of the arguments, whitespace, misspellings, and such.

I see us migrating to a form building class down the road, and at that point, the input_builder function (possibly better namespaces wp_input_builder) can just map to a class method. And if we don't -- hey -- at least we're not pining for the fjords in the meanwhile.

In the interest of getting HTML5 support in, I'd like to propose a simpler solution. It follows the example $req sets, checks whether html5 was specified as the format, and outputs the corresponding input types. I moved away from adding the pattern parameter since we don't want to validate the form anyway.

In the interest of getting HTML5 support in, I'd like to propose a simpler solution. It follows the example $req sets, checks whether html5 was specified as the format, and outputs the corresponding input types. I moved away from adding the pattern parameter since we don't want to validate the form anyway.

Feedback welcome!

I think the The reason for the use of the null pattern was that some browsers didn't support the novalidate attribute on the form and attempted to do validation. if I had to guess, it was a version of Opera. According to a cursory glance of the internet, it is fine in Opera 11.

Otherwise this patch looks like the best route until we can get a proper form builder in.

With regard to HTML5, can I just point out that not all assistive technology supports HTML5 yet - which is perfectly reasonable considering it's still only a draft spec. So any patch needs to ensure that all aspects of the form are still accessible to these users.

Hi sscovil, the paragraphs are still inside the form, I'm not sure I follow? In instances where these help texts would be used, there will be no corresponding form element to bind it to. What are 'author' and 'name'?

I want to add that many themes will style labels inside the comment form with a selector like #commentform label, adding labels in places where previously weren't any will break backwards compatibility.

Hi Konstantin, thanks for the response. Having paragraph tags inside the form is fine, as long as the text within them is wrapped in a label or input tag. I'm not sure if using a span tag would have the same effect, but I can look into it...

On second thought, I suppose using a span tag presents the same potential compatibility issue with themes. Unfortunately, as it stands, the comment form itself has a compatibility issue with screen readers...so I'm open to suggestions.

I will be meeting with the WP Accessibility group tomorrow and can bring any questions posted here to some folks who rely on screen readers and are more familiar with SR web form issues.

Adding labels seems like an entirely different conversation then the one at hand. Also one that has similar backwards compatibility concerns as were expressed above. I think we should open a separate ticket to discuss that and commit georgestephanis's most recent patch 15080.6.diff

No - it isn't. The spec actually says" The label element may contain at most one descendant input element". The keywords being "at least one". It is perfectly valid to have more than 1 label attached to a form control. The "Your email address..." line applies directly to the email input. The "You are logged in as" line should, logically, be associated to the Name input whilst the allowed tags content needs to be associated with the textarea.

All text within form tags must be within labels - otherwise SR users will be forced to make 2 passes (one on forms mode, the other in virtual cursor/reading mode). That, of course, assumes that the users are even aware that there is plain text in the form. Most will have no idea that this additional, informational, content is present as most SRs enter forms mode automatically on hitting the form tag or the first form control.