3 ms·

Validation is logic, it doesn't belong in markup. A rectangle to type text into is as far as the abstraction should go.

doytch 10y ago
No one's asking for bulletproof validation. What I want out of input[type="fancy"] elements is: 1. Better detection of the platform than I can do myself. That leads to a UI targeted at the platform (different default phone keyboards, etc). 2. Uniform UIs across websites. I hate having to learn a new calendar widget on every website, it's worse for regular users, not to mention any users that need accessibility features that are prooobably not included in most home-rolled (or even popular) widgets. 3. Basic validation. Just to help the user a bit. I'll validate it again on the back-end, and I might even be validating it myself on the front-end. But basic validation helps and, once again, that uniformity thing shows up again here since the user could be aware of how that widget reports errors on their platform already and could be looking for them.
grzm 10y ago
I'm torn. For the most part I agree with you. The niggling part that doesn't is where we decide where our level of abstraction is. It can be very convenient to be able to declare what the type is. If you don't do it in the markup, you're likely going to want this in some kind of library. And that library will need to be extensible or you've just shifted the problem, and now it's the library. So that part of it needs to be well thought out and portable. But in the end, I do think that the solution is more tractable in logic rather than markup. Though maybe markup tries to do too much. Look at all the additions to HTML5. It's great to be able to express so much more in the markup. Yet there are still going to be times where you're going to come across a situation that doesn't fit neatly into the existing elements. So you're going to add some extra domain-specific meaning to the markup you're using. You can work around this with class attributes, but that's just it: it's a work around. Enough rambling. I think there's a corresponding issue with display and behavior and the intersection of markup, CSS, and JavaScript, boiling down to inadequate separation of concerns.
matt4077 10y ago
Logic is also logic, so most texts (your comment excepted) shouldn't be allowed in markup. Note that nobody actually wants to embed the code for validation within the document, but you want to be able to properly identify a form-elements attributes so as to allow clients to make a smart choice about validation, presentation, defaults etc. JPEG decoding is also logic, but it's also pretty useful for client to know that the binary stream it's reading may best be handled with the jpeg library.

No one's asking for bulletproof validation. What I want out of input[type="fancy"] elements is: 1. Better detection of the platform than I can do myself. That leads to a UI targeted at the platform (different default phone keyboards, etc). 2. Uniform UIs across websites. I hate having to learn a new calendar widget on every website, it's worse for regular users, not to mention any users that need accessibility features that are prooobably not included in most home-rolled (or even popular) widgets. 3. Basic validation. Just to help the user a bit. I'll validate it again on the back-end, and I might even be validating it myself on the front-end. But basic validation helps and, once again, that uniformity thing shows up again here since the user could be aware of how that widget reports errors on their platform already and could be looking for them.

grzm 10y ago

I'm torn. For the most part I agree with you. The niggling part that doesn't is where we decide where our level of abstraction is. It can be very convenient to be able to declare what the type is. If you don't do it in the markup, you're likely going to want this in some kind of library. And that library will need to be extensible or you've just shifted the problem, and now it's the library. So that part of it needs to be well thought out and portable. But in the end, I do think that the solution is more tractable in logic rather than markup. Though maybe markup tries to do too much. Look at all the additions to HTML5. It's great to be able to express so much more in the markup. Yet there are still going to be times where you're going to come across a situation that doesn't fit neatly into the existing elements. So you're going to add some extra domain-specific meaning to the markup you're using. You can work around this with class attributes, but that's just it: it's a work around. Enough rambling. I think there's a corresponding issue with display and behavior and the intersection of markup, CSS, and JavaScript, boiling down to inadequate separation of concerns.

matt4077 10y ago

Logic is also logic, so most texts (your comment excepted) shouldn't be allowed in markup. Note that nobody actually wants to embed the code for validation within the document, but you want to be able to properly identify a form-elements attributes so as to allow clients to make a smart choice about validation, presentation, defaults etc. JPEG decoding is also logic, but it's also pretty useful for client to know that the binary stream it's reading may best be handled with the jpeg library.