search

ericelliott / h5Validate

An HTML5 form validation plugin for jQuery. Works on all major browsers, both new and old. Implements inline, realtime validation best practices (based on surveys and usability studies). Developed for production use in e-commerce. Currently in production with millions of users.
576 stars 125 forks source link

Use data-attribute instead or as alternative to class #9

Closed tobaco closed 12 years ago

tobaco commented 13 years ago

it would be great, if we could use the HTML5-data-attribute to specify the validation-pattern.

e.g. data-h5="phone" instead of class="h5-phone"

ericelliott commented 13 years ago

I agree. This is a great suggestion. I will implement this in a future version.

ericelliott commented 13 years ago

One note of caution. Using a class lets you add custom styles for different field types. For example, you can attach a phone icon to a phone input, or an @ symbol to an email input field (so far, we're shying away from using the new input types until they are fully implemented in current-generation popular browsers).

The data- attributes, in contrast, should not be used for things that you might want to style for the user. data- should only be used for data that is used only internally, and not presented to the user.

billsaysthis commented 12 years ago

Any thoughts on this now we're ten months on? Also, in case you hadn't realized it, you can use a selector like [data-h5=phone] to add styling per type.

ericelliott commented 12 years ago

I don't this this is worthy of core support in h5Validate. I believe it would encourage developers to use the data-* attributes when class attributes would be more semantically appropriate.

It's a bad idea to do css matching on the data-* attributes, as it subverts the semantic definition of what data-* is for. data-* should be used to store internal application variables that have to do with the dom. For example, associating elements with each other, or associating elements with variable names in your JavaScript models.

Because it's important to indicate to the user the input type that you're expecting, class is really the appropriate way to do this.

billsaysthis commented 12 years ago

Not reopening, decision is certainly yours, but I disagree with the rationale of "It's a bad idea to do css matching on the data-* attributes."

I disagree because I don't think of this so much as css matching, though there is a bit of that, but as enabling JS validation functionality. In this other light data-* attributes are right in line with the rest of the second paragraph's rationale.

Also I feel it's core-worthy since it gives developers using this library flexibility to suit their development needs and styles.

Thanks!

ericelliott commented 12 years ago

Hi Bill,

I think the next thing I want to focus my time on is writing unit and integration tests. If you'd like to submit a pull request, I'd be happy to consider it.

ericelliott commented 12 years ago

Or even if you can give me a really convincing use-case or too, maybe it'll spark my interest in this feature. =)

billsaysthis commented 12 years ago

I agree that tests are a higher priority. There really only seems like one place where the class is used as a selector (in the bindDelegation function) but I'm not too experienced at writing library quality JS code so I could be wrong--if this is correct I can submit a patch. The use case is more philosophical, in that to me this is about JavaScript functionality and so using CSS classes feels wrong though as a subjective choice I recognize not everyone will agree.

ericelliott commented 12 years ago

Hi Bill. Now that you mention it, that bit should probably be refactored entirely. It looks like this is going to happen only on startup, so if you dynamically add new elements after delegation, they won't have the appropriate patterns attached. The required refactor is a bit intrusive, so it looks like I'll need to take it on, after all.