Make rewriting of errror message texts by element title attribute optional.

[dbroz]

I would really like if the error message text is the error message text and that it does not get rewritten because I may have a title attribute on my element. Semantically they may not have to have the same value or meaning. The offending code is in the markInvalid() method.

[ericelliott]

The HTML5 spec recommends the use of the title attribute to store form validation user feedback. The point of the title attribute is to provide hints to the user about how to interact with the element, so the semantic meaning is correct.

[dbroz]

Yes you are somewhat right, however I have hit a problem as noted by the spec where I have a situation where the error message is additional to how the pattern is used on the input, and it is truly an error message, and not just a pattern description.

Please read the spec.

http://www.w3.org/TR/html5/common-input-element-attributes.html#attr-input-pattern "When a control has a pattern attribute, the title attribute, if used, must describe the pattern. Additional information could also be included, so long as it assists the user in filling in the control. Otherwise, assistive technology would be impaired." ... "UAs may still show the title in non-error situations (for example, as a tooltip when hovering over the control), so authors should be careful not to word titles as if an error has necessarily occurred."

I would go further and say the spec is clear about this issue with this statement: "When a control has a pattern attribute, the title attribute, if used, must describe the pattern. Additional information could also be included.."

supported by this statement: "...careful not to word titles as if an error has necessarily occurred."

It does not mean that the title must be used as an error message, but only as a pattern description, so when validating the error message can be different to the pattern description via addition. So using the title as a error message should be optional, or at least hookable so that additions can be made.

[ericelliott]

The flexibility you're looking for is already there.

H5Validate does not set the title attribute at all. You can set it to anything you want. It only optionally displays it for you when the field is invalid.

If you don't like how it behaves, you can hook the events and display anything you want in your own error divs.

It is completely compliant with the spec in this regard. On Oct 2, 2012 12:45 AM, "David Broz" notifications@github.com wrote:

Yes you are somewhat right, however I have hit a problem as noted by the spec where I have a situation where the error message is additional to how the pattern is used on the input, and it is truly an error message, and not just a pattern description.

Please read the spec.

http://www.w3.org/TR/html5/common-input-element-attributes.html#attr-input-pattern "When a control has a pattern attribute, the title attribute, if used, must* describe the pattern. _Additional information could also be included , so long as it assists the user in filling in the control. Otherwise, assistive technology would be impaired." ... "UAs may still show the title in non-error situations (for example, as a tooltip when hovering over the control), so authors should be *careful not to word titles as if an error has necessarily occurred._"

I would go further and say the spec is clear about this issue with this statement: "When a control has a pattern attribute, the title attribute, if used, must\ describe the pattern. Additional information could also be included.."

supported by this statement: "...careful not to word titles as if an error has necessarily occurred."

It does not mean that the title must be used as an error message, but only as a pattern description, so when validating the error message _can_be different to the pattern description via addition. So using the title as a error message should be optional, or at least hookable so that additions can be made.

— Reply to this email directly or view it on GitHubhttps://github.com/dilvie/h5Validate/issues/48#issuecomment-9061553.

[dbroz]

Yes but what it does do is if the the title attribute is set and if you have a error div it will rewrite the contents of the error div with with the title atrribute content. This is clearly not to HTML5 spec as error messages are NOT the same as pattern descriptions. I do believe title attributes are also used as tool-tips in browsers, setting a title tag to an a error message (an error that they may not have) could confuse users.

I would further suggest that error messages could be put in a "data-h5-error-msgs" attribute instead of using the title attribute. That way you can really keep them separated, and keep to the spec.

As it stands I cannot have BOTH a pattern description set in the title attribute and a different error message set in the error div. I can only remove the title attribute to get my error message, or get my title attribute (pattern description) set as my error message. Removing the title attribute to get a true error message forces me to compromise on semantics by not including the pattern description.

[ericelliott]

Please create a jsfiddle that illustrates an example of h5Validate doing what you don't want it to do, along with your proposed behavior and desired result.

Otherwise, the current default behavior of h5Validate is based on research, usability studies, and feedback from thousands of users of production code.

The spec was right to say that you should provide a description that instructs users on how to create a valid input, and that instruction is exactly what a user needs to see when they enter invalid input.

If you have a problem, I'm inclined to think that you need to revise your title text - NOT display a scary error message to users.

If you really insist on deviating from data-driven best practice, you can still do that by hooking the event API and showing / hiding your own error divs. I am not inclined, however, to make it trivial to deviate from best practices, or further clutter the API for one guy's special use case. On Oct 2, 2012 9:34 AM, "David Broz" notifications@github.com wrote:

Yes but what it does do is if the the title attribute is set and if you have a error div it will rewrite the contents of the error div with with the title atrribute content. This is clearly not to HTML5 spec as error messages are NOT the same as pattern descriptions. I do believe title attributes are also used as tool-tips in browsers, setting a title tag to an a error message (an error that they may not have) could confuse users.

I would further suggest that error messages could be put in a "data-h5-error-msgs" attribute instead of using the title attribute. That way you can really keep them separated, and keep to the spec.

— Reply to this email directly or view it on GitHubhttps://github.com/dilvie/h5Validate/issues/48#issuecomment-9077400.

[dbroz]

I don't need to do a jsfiddle, this is quicker to explain:

<label>Find a big 10 digit prime number</label>
<input data-h5-errorid="myid" type="text" pattern="[0-9]{10}" title="Please enter a 10 digit number" />
<div id="myid" style="display:none">Error: The number is not a prime!</div>

"Please enter a 10 digit number" is a clear pattern description. It does not suggest error. "Error: The number is not a prime!" is a clear error message.

On a ajax autocomplete callback I check if the number is prime, if it is not prime I trigger the validation error, and it substitutes "Please enter a 10 digit number" as my error message.

Of course I can script myself around this default behaviour, but it still doesn't make the default behaviour correct.

If it is an API issue, by default keep the current behaviour but offer a configuration switch to disable it.

[ericelliott]

A switch seems like a good compromise.

[dbroz]

((sorry this is a little off-topic but relevent))

If you are following semantic versioning by Tom Preston-Werner from github http://semver.org/ (and I really suggest you have a read as it offers a good methodology on how to deprecate changes to an API through versioning and how to approach versioning in general) you can still make API changes until v1.0.0, at that point the code is considered to be production ready and any further API changes should be backwards compatible or carefully deprecated. Under semantic versioning it is expected that software developed under v1.0.0 does not have a stable API. i.e use at your own risk. Developers should already know this when incorporating software under v1.0.0. Once you hit v1.0.0 however the API should be more or less in stone.

So don't worry too much if your API is slightly changing at this stage. The stability expectation of the software is not that high yet. Of course it is important to think about establishing the API, maybe you want to start laying out a roadmap of what you want the public API to finally look like for v1.0.0 and set some milestones to reach it, I notice that you are not using milestones.

IMHO it has a while to go yet before h5validate can be considered production stable (missing features, unsupported attributes and too many todo's in the code), not to say that anyone shouldn't put it in production, because the more people who use it, the further it will develop and mature. It is a consistent way to validate across browsers that do not support HTML5 validation.

[ericelliott]

Nobody else has expressed an interest in this feature, with millions of users and thousands of people implementing h5Validate on their website. Closing.