Disabling auto-complete in a form

[jc_gmk]

Is there any way to disable a text field (in a standard HTML form) from using the browsers auto-complete function?

[djr33]

Well, you can randomize the fieldname, if that happens to work. I'm not sure about a workaround.

[jc_gmk]

No it's got to stay the same because there is a PHP page collecting the data.

Any other Ideas, I thought maybe some javascript could do it?

[jscheuer1]

If you make it a password, it will disable auto-complete, but the text entered will be represented by dots or other placeholder characters:


<input type="password" name="whatever">

If it is a text area and has no name, that should also do it, and show the entered text normally:


<input type="text">

Now, it is possible that you could use a name and script the name to be removed - say, onmouseover and onkeydown. The name could then be restored onchange or perhaps onblur. This gets tricky though - would need to be tested in various browsers, because the elements collection of a form is more persistent then regular HTML elements. If this is mission critical, it wouldn't be a good idea because it would require javascript enabled on the client side.

A simpler solution that should easily work is:


<input type="hidden" name="the_name_you_really_want">
<input type="text" onchange="this.form.elements['the_name_you_really_want'].value=this.value;">

But it still requires javascript enabled. If a non-javascript enabled browser uses that, their data will not be passed along. You could script to write out the above and have a noscript alternative with the name hard coded to the text element. This means that those with javascript disabled would still get auto-complete if they have it on their end.

[djr33]

Ah. Creative solution, John. I like it.

[Twey]

It would be easier to randomise the field name. You can pass the name of the field to your PHP script in a hidden form element.
<input type="text" name="<?php echo ($field_name = 'm' . mt_rand()); ?>">
<input type="hidden" name="m_field" value="<?php echo $field_name; ?>">And your PHP script:
$val = $_GET[$_GET['m_field']];

[djr33]

that won't take user input; I think you've confused passing a value through a form with php and removing the autocompleting feature on forms.

[Twey]

What do you mean it won't take user input? It's an <input>. I think you've misunderstood my code?

[jscheuer1]

I think I understand and like your idea Twey. There could be two problems though. With a truly random name, there are the odds that it will be the same sometimes, activating auto-complete. Now, I know the potential range is vast, but no range is vast enough to preclude a repeat number. Haven't we before used (in javascript) a number based on the date in such circumstances to guarantee a non-repeatable value? My PHP isn't the best by any means, but if basing a number upon the date can be done in javascript, it can probably be done in PHP. If not a pure number, then certainly a unique string. PHP does have a date object or something like one, right?

The other concern I have for this approach is the relative ease or difficulty there would be in actually integrating it into the existing PHP code for jc_gmk. To be of value, jc_gmk would have to be able to make use of it. I get the impression though that jc_gmk isn't all that comfortable or even aware of how to 'get under the hood' with the PHP code involved here.

Still a very good idea if I have understood it correctly.

However, as long as it would be OK for non-javascript enabled browsers to have access to auto-complete, javascript might offer an easier 'works most of the time' solution.

[Twey]

That's true: perhaps:
<input type="text" name="<?php echo ($field_name = 'm' . md5(time())); ?>">
<input type="hidden" name="m_field" value="<?php echo $field_name; ?>">

[djr33]

OH. I did miss that. I read that as something like $$field_name, passing the previous value of the field through the form.

I agree, then. That's a good solution.

[jc_gmk]

Thanks for you ideas.

However I decided to google it further (Before you gave me all these ideas)

and I came up with this simple solution:



<input type="text" name="something" autocomplete="off" />


Seems to work fine!

[Twey]

This is invalid code, however, and is not part of any (X)HTML specification, including the working draft of HTML5 at the time of writing.

[djr33]

But which browsers does it work on, then? Heh.

One thing to consider is that "auto complete" is not part of the standard HTML specifications either; I doubt that turning off the image toolbar for IE is "valid html" but it is certainly valid practice; if all browsers that support an auotcomplete method also support such a workaround, I don't see a problem. It wouldn't be included in the html specifications if the function isn't standard, would it?

[Twey]

I think just IE and Firefox.

[djr33]

Which other browsers have an autocomplete feature that do not support it, then?

Safari doesn't autocomplete, for example.

[Twey]

Yes it does -- look under Preferences->Autofill apparently. Konqueror also does; Opera does; Dillo does... I think most modern browsers do.

[djr33]

Ah. Seems it was just disabled for me. Never paid much attention, there. It does have a "from address book feature", as well.

[jscheuer1]

One question we usually ask in cases like this that we didn't here is "Why?" I was tempted to several times, not sure why I didn't.

Generally, if the user has auto-complete on, they can distinguish between an appropriate suggestion and one that simply wouldn't be acceptable for them in a given situation. Unless it's a quiz, even if it is, what's the harm in auto-complete?

[jc_gmk]

Thanks for all the info! :)

In answer to your question John, the reason why I want to disable it is because I have created an order form which could have upto 100 input lines.

All of the input fields have the same name e.g.



<input type="text" name="quantity[]">
<input type="text" name="quantity[]">
<input type="text" name="quantity[]">


As our customers use this form on a day to day bases the "quantity" field get very full of different auto-complete suggestions.

It's not essensial that I disable it, it just stops long lists appearing everytime they click in one of the boxes.

[tech_support]

One question we usually ask in cases like this that we didn't here is "Why?" I was tempted to several times, not sure why I didn't.

Generally, if the user has auto-complete on, they can distinguish between an appropriate suggestion and one that simply wouldn't be acceptable for them in a given situation. Unless it's a quiz, even if it is, what's the harm in auto-complete?
Also, most "web 2.0" websites/applications have it "disabled", like chat sites.

[djr33]

When used as a feature, not as a "form", that's quite true, or when typing in sensitive data, like a bank account number, which wouldn't be a password, but would be better to not just pop up.

[jscheuer1]

Does 'web 2.0' really mean anything? I see you quoted it as if it did to some people, but not to others.

I played around with the old autocomplete="no" concept and it worked in FF and Safari. Opera doesn't seem to have the feature to begin with, at least not that I can tell. I have it off in IE, but I'm sure it works for that browser.

I would venture to guess that virtually all browsers that have the feature, whatever they call it, would respect the non-standard autocomplete="no" attribute. Those that don't respect it, most of their users must be used to it happening at odd times. Those that don't have the feature are no problem in this context.

If there is an issue of strict compliance, the attribute may be added via javascript, but that will cut down on compliance. Non-javascript enabled browsers with the feature will still auto-complete.

[Twey]

Does 'web 2.0' really mean anything? I see you quoted it as if it did to some people, but not to others.It's a ridiculous buzzword. Generally speaking, it means "a site that uses XHR for no good reason," but sometimes it also means "a site that uses way too much eye-candy and stupid flashy effects." See also Prototype (http://www.prototypejs.org/).
If there is an issue of strict compliance, the attribute may be added via javascript, but that will cut down on compliance.It's not compliant then anyway. Just because the validator can't pick it up doesn't mean it's valid.

[jscheuer1]

If there is an issue of strict compliance, the attribute may be added via javascript
It's not compliant then anyway. Just because the validator can't pick it up doesn't mean it's valid.

Without saying is how that goes. It's funny though, even before I saw this, I was wondering if you could do a:


if (/(string)|(boolean)/.test(typeof el.autocomplete))
el.autocomplete='no';

or something like that. If you could, I'm sure, although not valid, it would be in the spirit of valid code.

Also, what I meant by using javascript to validate, that was just to get the green screen, for whatever reason.

[Twey]

If you could, I'm sure, although not valid, it would be in the spirit of valid code.Mm. Perhaps:
if(typeof el.autoComplete !== "undefined")
el.autoComplete = false;
Also, what I meant by using javascript to validate, that was just to get the green screen, for whatever reason.There's no point in this at all. The validator is just a tool that helps you achieve validity, not a dictator that demands perfect conformance; trying to outfox it in this way is self-defeating.

[jscheuer1]

Mm. Perhaps:
if(typeof el.autoComplete !== "undefined")
el.autoComplete = false;

Possibly. Being non-standard though, if we wanted to know as much about this approach as we could, I think we would have to try it out in as many browsers as we have available to us.



Also, what I meant by using javascript to validate, that was just to get the green screen, for whatever reason.
There's no point in this at all. The validator is just a tool that helps you achieve validity, not a dictator that demands perfect conformance; trying to outfox it in this way is self-defeating.

I dunno, you'd be surprised at the reasons some folks come up with for it.

I find that both visually and psychologically, I just prefer the color green. As long as I know what I did to get it to validate, what's the harm in sparing myself the stress of the red screen? I even sometimes go so far as to have some image tags display:none in IE and then use IE conditional comments to make otherwise duplicate image tags for them with the galleryimg="no" attribute set.

The most compelling reason for some would be to satisfy some relatively clueless client.

In limited testing it looks like the 'typeof' approach isn't going to work. In Opera which has 'The Wand' and supposedly/perhaps respects autocomplete=no for its use, which is different than the general autocomplete feature on other browsers, the typeof is always 'string'. In FF it is only 'string' if present - 'undefined' if absent from the tag, in IE it's always 'string'.

[Twey]

I even sometimes go so far as to have some image tags display:none in IE and then use IE conditional comments to make otherwise duplicate image tags for them with the galleryimg="no" attribute set.And why not? That's perfectly valid. You're just taking advantage of a browser-dependent feature (as we do with the conditional Javascript above).
The most compelling reason for some would be to satisfy some relatively clueless client.I'm fairly sure that's a dishonest business practice.

[jscheuer1]

Dishonest, it would all depend. If you don't come right out and say it's valid strict or whatever, I think you're covered. You could say, it validates as strict. Then you would move from dishonest to merely deceptive. If the rest of the code really is valid, it is a harmless deception (white lie) in my opinion.

I don't know what I would do, it's never come up. I think I would try to explain the situation, but not be so adamant about it so as not to give myself the room to use the white lie if the client were firmly entrenched.

[djr33]

it is a harmless deception (white lie) in my opinion.I despise the idea of a strict validation and conformity; if something works*, it works, and should be valid. A tag like this causes no harm.
(*consistently, in either all browsers, or it causes no harm in those in which it doesn't work)
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?
Is this really a harmless deception?
What's the point of a strict standard when a bit of bending is ok?

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.

//shrug

[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 conformityYou 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. :rolleyes:

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.

[BLiZZaRD]

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?


Holding the future into account is nonsensical. Even Sylvia Browne can't see what will work in the future for web design.

I think the track came off though and the validation tools are not the focus of the blame here. Obviously we can not have a code, HTML or otherwise that has every tag or element or prose work perfectly. There would be an insane amount of man hours and conformity to try and make a validation tool or even a language work perfectly.

But the focus should be on the browsers, methinks. Why can't the browsers change to meet the standards.

If they stopped offering "Quirks" mode for example, it would then push designers to make a page that works. Why have transitional and strict, why not only have one. If the page doesn't work it is broken, so fix it.

include <embed> in validation, or supply us with a tag that works all over.

Monopolizing conglomerates battling each other for product use is what makes this debate pretty worthless. If IE and Firefox and Konq and all the others had a "build to" standard then we wouldn't have this topic to discuss.

[djr33]

If they stopped offering "Quirks" mode for example, it would then push designers to make a page that works. Why have transitional and strict, why not only have one. If the page doesn't work it is broken, so fix it.I agree, completely.

With one exception-- what about features like auto complete? Would you want all of those stripped from the browsers? How should one deal with such a feature, then, if it isn't standard, and, therefore, the code to deal with it isn't?

How old is HTML 4, and when will it be replaced? That, and a few other things, are perfect examples of what need to be updated. But.... just don't use them because they aren't valid by those old standards?

Sure, you can't predict the future, but you must adapt when it comes-- and HTML isn't adapting. The browsers are, for better, and for worse standardization. If all the browsers were to update in the same manner, it would be great. In fact, this could be helped with an actual update to HTML itself; then the browsers could all go in the same direction, rather than just taking a best guess path, or running around like a headless chicken, in IE's case.


Important to note two sides to this:
1. Unstandardized features.
2. Poor/nonstandard coding.

The former should be added and standardized. The latter is just wrong. And, wouldn't any "proper" workaround, though technically valid, fall into that? ;)

[jscheuer1]

Quirks must remain for now. Otherwise there would be tons (millions, at least) of pages on the web that wouldn't render properly, many, many that would be totally illegible. Many of these pages were coded to the standards in effect when they were made. A time may come when this is no longer true, but I wouldn't hold my breath.

Another value of quirks is that for the designer who knows it, really knows it, it can be a valid (not by the validator, but meaning 'highly effective') way of doing pages that are cross browser.

[Twey]

In denary, yes, 'a' is not a number. Therefore, the number 12a456 is indeed worthless for parsing as a number.
Holding the future into account is nonsensical. Even Sylvia Browne can't see what will work in the future for web design.One of the purposes of the standards is to provide some protection against the future, however. If we follow the standards, we know with a fair amount of certainty that browser vendors aren't going to decide they don't like HTML any more and come up with their own markup language.
If they stopped offering "Quirks" mode for example, it would then push designers to make a page that works. Why have transitional and strict, why not only have one. If the page doesn't work it is broken, so fix it.I'd say yes to that. It would indeed break a lot of the Web as it is now, however, and I think that perhaps a lot of people are too conservative to be prepared to start from scratch.
include <embed> in validation, or supply us with a tag that works all over.You're missing the point here. The standard does indeed supply a tag that should work universally, <object>. It just happens that a lot of browsers have bugs that prevent <object> from working properly.
Another value of quirks is that for the designer who knows it, really knows it, it can be a valid (not by the validator, but meaning 'highly effective') way of doing pages that are cross browser.Again, yes, if said designer is aware of every intricacy of every browser. Quirks mode follows no standard, so browsers are free to interpret HTML under quirks mode however they wish, even if it's completely different to every other browser out there. If I really felt like being irritating, I could write a quirks-mode-only browser that took an HTML document and displayed a PNG image of a slice of pie.

[BLiZZaRD]

You're missing the point here. The standard does indeed supply a tag that should work universally, <object>. It just happens that a lot of browsers have bugs that prevent <object> from working properly.


I didn't miss the point, that was my point. Valid pages aren't the problem here, it's making one page that works in umpteen different browsers the same way.

Why won't IE accept <embed>? They feel it is wrong? They feel they are superior? Why won't FF define <object> ? Same reasons?

Again, my point is that the argument should be directed towards the browsers not the "valid" markup.

If Browsers as a whole would conform to one standard the rest would go by the way side.

[jscheuer1]

The double object/object tag (valid) for Flash (and many other types of multimedia content) works just as well as the object/embed tag pair (invalid), as long as you know what you are doing. I've even seen a single embed work for Flash in IE, Opera and FF, but it had very limited attribute choices and was still invalid. Don't get me started on 'click to activate'.

When I use Flash on my client's sites, it is sparingly. So I just use whatever works. But I know how to write out a valid object/object tag (or at least where to go to double check how), if I need to. If I'm in one of my 'moods', I'll do it anyway, because I figure it will likely save me work in the long run.

It is all a bit much in my opinion though. Definitely makes it more complicated than it really has to be.

<applet>

Watch out for that Treeeeee . . . !

</applet> :eek:

[Twey]

Why won't IE accept <embed>? They feel it is wrong? They feel they are superior? Why won't FF define <object> ? Same reasons?Fx does accept <object>. The biggest difference between it and IE is, as I understand it, the use of the classid attribute. The HTML specification says that the classid attribute should specify an URI to identify a player. Unfortunately, instead of using one of the existing, standardised URI forms, Microsoft decided that it would be a great laugh to formulate their own clsid: URI format. They don't implement <embed> because it's non-standard (and in fact impossible to describe in the language in which DTDs are written).
Again, my point is that the argument should be directed towards the browsers not the "valid" markup.But it's because people take this attitude that you have to write the ridiculous two-element mess to get a basic embedded Flash object to work. It's a vicious circle.

[BLiZZaRD]

It's a vicious circle.


That I agree with 100% :D