Disabling auto-complete in a form

[Twey]

You could say, it validates as strict. Then you would move from dishonest to merely deceptive.

No, it's still invalid. Like I said, just because the validator can't tell that it isn't valid doesn't mean it is valid. The validator is not authoritative, merely a tool to help the Web designer quickly spot errors in his/her code.

A tag like this causes no harm.

It was an attribute we were discussing, not a tag.

I despise the idea of a strict validation and conformity

You despise, then, essentially the Web? You'd prefer to see us go back to the days of the Netscape/IE wars where it took ridiculous amounts of effort to write a page that worked between those two browsers, let alone any others? With sufficient deviation from the standards the Web will break down.

However, to have any reasonable way to standardize code so that it is generally legible and understandable by another user, it simply must have some sort of standardization. As such, what then is the solution?

To follow the standards, of course. There are mechanisms to safely add vendor extensions in CSS (prefixing the property with -vendor-name-); perhaps HTML needs something similar. I think, however, it would be overly open to abuse. The Javascript here is a scripted example of such, but again it is very easily (and frequently) abused, creating pages that aren't very portable between browsers.

Is this really a harmless deception?

It isn't harmless deception, it's outright lying to a client about the quality of work done, and at least my work ethics would prevent me doing this on a purely moral basis.

What's the point of a strict standard when a bit of bending is ok?

It isn't. That's the point.

Personally, I'd suggest that additional attributes be allowed, but I guess that means any random attribute which IS invalid would be allowed as well.

Yes. You'd also immediately double the size of any conforming HTML parser as it tried to keep up with the burst of suddenly-existent attributes.

[BLiZZaRD]

No, it's still invalid. Like I said, just because the validator can't tell that it isn't valid doesn't mean it is valid. The validator is not authoritative, merely a tool to help the Web designer quickly spot errors in his/her code.

Then who is the authority here? If the validator tool can't spot invalid code, then is it really invalid?

I was in the forest the other a day and a tree fell right next to me. I didn't hear a thing.

By your rational here, Twey, you would imply that web designers should basically write code that will work only in Lynx, and therefore it will validate and work "properly" in each and every browser.

On the other hand as a web designer, if I can write codes, and applications and Flash intros and JS photo galleries and put them in my web page and the validator tells me that it is strict valid and each browser shows it exactly the same, then I have done my job.

It ceases to matter if I was smart enough to "trick" the validator and/or the browsers with tags or coding (et. al) to force-prove it is valid code.

[jscheuer1]

I was in the forest the other a day and a tree fell right next to me. I didn't hear a thing.

LOL! More like:

I was in the forest the other a day and a tree fell right on me. I didn't feel a thing.

Oh, what am I do do with you other folks? If I say code validates as strict, it validates as strict (unless I'm simply mistaken and have missed something). Now, is it really valid or not? With someone who doesn't know the difference, and who is being unreasonable about it, I think (this has never come up) I would take a 'don't ask, don't tell' approach. To any reasonable person I would say, "The bulk of the code is valid, only this small part is not, but it is widely used and the only way to do this one thing - I have arranged it so that it still passes validation, even with that non-standard bit included."

[Twey]

Then who is the authority here? If the validator tool can't spot invalid code, then is it really invalid?

The specification is the authority.

By your rational here, Twey, you would imply that web designers should basically write code that will work only in Lynx, and therefore it will validate and work "properly" in each and every browser.

Only in Lynx? Certainly not. A properly-designed site will work in Lynx, yes, but that's not to the exclusion of other browsers and other features of other browsers.

On the other hand as a web designer, if I can write codes, and applications and Flash intros and JS photo galleries and put them in my web page and the validator tells me that it is strict valid and each browser shows it exactly the same, then I have done my job.

Certainly, if you test it in every single current and future browser and it works in all of them. A time machine may be required, but hey, it's less effort than validating it for real, right?

With someone who doesn't know the difference, and who is being unreasonable about it, I think (this has never come up) I would take a 'don't ask, don't tell' approach.

If s/he doesn't know the difference, how can s/he be unreasonable about it?

[djr33]

You despise, then, essentially the Web? You'd prefer to see us go back to the days of the Netscape/IE wars where it took ridiculous amounts of effort to write a page that worked between those two browsers, let alone any others? With sufficient deviation from the standards the Web will break down.

Spoke to quickly... I meant to say I don't like the obsession with simply meeting these standards for the sake of only standards, when it seems this is arbitrary in some cases and even limiting in others.

It isn't harmless deception, it's outright lying to a client about the quality of work done, and at least my work ethics would prevent me doing this on a purely moral basis.

This is running that stop sign in the desert in order to save your child, who's dying of thirst in the back seat.

At what point is it really worth sacrificing something on your site, or using a completely roundabout and, really, more wrong way?

Certainly, if you test it in every single current and future browser and it works in all of them. A time machine may be required, but hey, it's less effort than validating it for real, right?

Specious. That implies that standards are magic-- and it suddenly works. That's clearly not the case, with IE alone.

Standards are not magic and not definitive. Browsers may ignore some rules and/or add others, and, in reality, this happens all the time. Standards also aren't exactly standard when one browser displays one standard in a different manner than another browser displays the same standard.

A perfect standard would be great, but I don't like having a limiting standard, especially when it isn't entirely accurate.

I'd rather have invalid code that works and makes for a great site in all browsers than one that happens to be valid and work in all.

Many things are quite important-- proper code formatting. Valid source with no line breaks and no tabs... awful. But that's still valid.
How about having the basic elements required to make a page? Sure!
And most of the things that are validated? Well, of course.
But what about those weird exceptions?
And the things that DON'T work right, but are valid?
How about very important codes like this that aren't included?

I don't like a limiting standard; I think that HTML should be a language, much like modern day speech, which has new words added every day.

What possible reason is autocomplete="no" not valid? Nothing, except that it specifically is not included. Why? Well... they didn't think of it when they made the standard, and it may not be yet included in all browsers.

When is XHTML coming? No, it's not? HTML 5.0? No?
Hmm... what's next, and when.

And should we wait until that mysterious point in time to have webpages that have decent functionality?

The trouble with html, javascript, etc., is that they are very limited. With PHP, ASP, other server programming languages, and especially 'real' programming languages-- C#, Java, etc., there's no limit. You can create something one way or another and it works. Javascript is much more flexible than HTML. Imagine a strict validator for JS, and it also disallows any custom functions. Javascript, though, does have the same problem, but not as extremely as html.

HTML is a set of rules which can be applied. Add a div. Add a line of text. Add formatting. That is all. With other languages, one can be creative. With html, one cannot. In fact, the only way to even attempt this is to use Javascript.

Hmm.... weird, eh?


So... fantasy vs. reality:
A perfect validator would be great. It's not.
Unlimited coding options would be great-- except, in reality, it would just end up a mess.
So... where does that leave us, the shall I say "sensible" designers?
We use common sense and limit our use of code so it works and is "standard"/ok enough, but we do want options.

[jscheuer1]

If s/he doesn't know the difference, how can s/he be unreasonable about it?

Like so:

"The code must validate as strict! Nothing else is acceptable!"

Here comes that tree again, yipes!

If that sort of person thinks that validating and actually conforming are the same thing, and can't get it straight in a detailed discussion with me, and can't see the wisdom in using the odd non-standard thing for a particular purpose . . .

It really is a hypothetical though. My way of acquiring clients would tend to screen out people like that. Once I have you as a client, your experience with me will tend to make you give me a lot of leeway in how I do your site.


Standards are wonderful, but a pain in the butt at times too. Once you get familiar with working with them, they aren't nearly as onerous as they often seem at first, which can be pretty onerous seeming. They are not the solution for avoiding time travel though, because they too change over time. And, they are after all only the product of fallible humans, so can be at times stupid.

One also has to guard against being so caught up in learning the 'proper' way to do things that one never does anything.

I'll settle for simply making my style of coding more universally accessible over the life of my career. Understanding the standards helps with that, but it isn't the be all and end all of it.

[Twey]

Spoke to quickly... I meant to say I don't like the obsession with simply meeting these standards for the sake of only standards, when it seems this is arbitrary in some cases and even limiting in others.

It's never a case of meeting the standards for their own sake. Meeting the standards brings a whole bunch of benefits to the developer and the user, such as a reasonable guarantee that code will work in all current and future browsers -- and that if it doesn't, the browsers are at fault.

I don't like a limiting standard; I think that HTML should be a language, much like modern day speech, which has new words added every day.

English, not any modern-day speech. A large number (possibly a majority) of languages have some form of governing body that regulates what becomes part of the language and what doesn't. The big difference between a human language and XML is that the human long-term memory has, to the best of our current knowledge, no upper limit on its capacity. An HTML parser, however, must work within the system specifications of the machines it should run on. Can you imagine having an HTML specification with as large a vocabulary as English? It would let you write just about whatever you wanted, but it would require a cluster of supercomputers even to parse, let alone render!

What possible reason is autocomplete="no" not valid? Nothing, except that it specifically is not included. Why? Well... they didn't think of it when they made the standard, and it may not be yet included in all browsers.

Well for a start, it doesn't fit with the rest of the HTML specification. Boolean attributes in HTML generally take only one possible value, which is their own name; i.e. <input type="text" autocomplete="autocomplete"> to enable autocompletion, or perhaps <input type="text" noautocomplete="noautocomplete"> if it were enabled by default. Traditionally, they're just shortened such that they don't require a value:<input type="text" noautocomplete>.

When is XHTML coming? No, it's not? HTML 5.0? No?

It's come already, and is implemented in all major browsers except IE. HTML5 (which specification includes has an XHTML variant, by the bye) is still a Working Draft, and as such is only sporadically implemented in recent browsers (Fx3 implements a fair few features from it, but by no means the whole thing).

The trouble with html, javascript, etc., is that they are very limited. With PHP, ASP, other server programming languages, and especially 'real' programming languages-- C#, Java, etc., there's no limit. You can create something one way or another and it works. Javascript is much more flexible than HTML. Imagine a strict validator for JS, and it also disallows any custom functions. Javascript, though, does have the same problem, but not as extremely as html.

That's because PHP, ASP, and Javascript are all programming languages. HTML is not a programming language. It is a document markup language. It isn't Turing-complete, and it's never going to be -- that would again be mere bloat for the purpose for which HTML is designed. However, even programming languages have their standards, and failure to comply with them, again, causes all sorts of difficulties for the developer and the user.

So... fantasy vs. reality:
A perfect validator would be great. It's not.

Eh? It would indeed be great.

Unlimited coding options would be great-- except, in reality, it would just end up a mess.
So... where does that leave us, the shall I say "sensible" designers?
We use common sense and limit our use of code so it works and is "standard"/ok enough, but we do want options.

Ask for a modification to the standard then. The fact remains that if you start adding non-standard code in willy-nilly, what you are writing ceases to be HTML and becomes a babble that, if the errors aren't too severe, can be error-corrected into HTML.

[djr33]

Can you imagine having an HTML specification with as large a vocabulary as English?

Oh, certainly not. But the idea of growing is a good one, not that it must grow infinitely. Out of necessity, even those closely controlled languages do add some way to represent a new and needed concept, like "computer".

babble that [...] can be error-corrected into HTML.

Hmm... not really.
Error correcting implies it is wrong. Really, it's not "wrong", but just not standardized (wrong only if that is how you define it).
It is interpreted as such.
It's not "HTML 4.0 Strict", no, but it may be something that works better in browsers. Then is it "erroneous"?

[Twey]

It's not HTML at all. HTML today is a collection of specifications maintained by the W3C and, for the earlier ones, the IETF. Anything conforming to those specifications is HTML. Anything else is not: if it's intended to be interpreted as HTML, then yes, it is wrong and erroneous.

[djr33]

That's an exclusive definition. What about an inclusive one?

Are '1, 2, 3, a' numbers?

Just because 'a' isn't a number, that makes the rest not numbers, and worthless? Weird.