name reference

[Chameleon]

This code does not working in Mozilla. Works fine in IE.
--------------
<input type=text value=100 name=textbox>
<script>
alert(textbox);
</script>
--------------
This perhaps, because of Microsoft policy to globalize all tag names.

Is there any method for cross-browser fix without using getelementbyid?
Is there any method to pass values from outside of <script>, inside?
(something like "global" in php functions)
Javascript must be kept inside <script> tag

 

[Justin McConnell]

This code does not working in Mozilla. Works fine in IE....
Is there any method for cross-browser fix without using getelementbyid?

You'll want to wrap the input in a form tag with a name, then access it
through the document object. Something like...

<form name=aform>
<input type=text value=100 name=textbox>
</form>
<script>
alert(document.aform.textbox);
</script>

 

[Crazy Code Ninja]

Hi,

getElementById is really the preferred way, but for older browsers you
can use:

alert( document.forms[0].elements['textbox'].value );

but you need to wrap your input fields with <form></form>, and the code
above assumes you only have one <form></form> in the page.

There is a downside to having <form></form>, when user presses ENTER on
an input field (e.g. text box), the browser would try to submit the
form, so you'd need to handle this as well.

I won't discuss this here as I have no time, but have a look at
www.quirksmode.org, it has very good articles about cross-browsers
javascript event handling which will help in solving this problem
(e.g.: detect if ENTER key is pressed in an input field, and ignore it
so the browser doesn't try to submit the form).

I created a function for selecting input field that looks like (I don't
have it with me so this is just on top of my head):

function get_field_object(id)
{
// if browser supports getElementById
if( document.getElementById )
return document.getElementById(id);
else
return document.forms[0].elements[id];
}

then use it like:

<script>
var t = get_field_object("textbox");

// if object is valid
if( t )
alert( t.value );
else
alert('Couldnt find object.');
</script>

I hope that helps a bit.

Kind Regards,

Sid
http://www.onlinesid.com/blogs

 

[Ge'rard Talbot]

Chameleon wrote :

This code does not working in Mozilla. Works fine in IE.
--------------
<input type=text value=100 name=textbox>
<script>
alert(textbox);
</script>
--------------
This perhaps, because of Microsoft policy to globalize all tag names.

Is there any method for cross-browser fix without using getelementbyid?
Is there any method to pass values from outside of <script>, inside?
(something like "global" in php functions)
Javascript must be kept inside <script> tag

Using Web Standards in Your Web Pages
Accessing Elements with the W3C DOM
http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access

explains it all.

Ge'rard

 

[Matt Kruse]

getElementById is really the preferred way

Not really. Then you need to generate a unique ID for each input field and
add bloat to your page.

alert( document.forms[0].elements['textbox'].value );
but you need to wrap your input fields with <form></form>

which you need to do anyway to create valid html.

, and the
code above assumes you only have one <form></form> in the page.

Which is a bad practice. Use form names instead of indexes.

For more info, see http://www.JavascriptToolbox.com/bestpractices/

 

[RobG]

Matt Kruse said on 16/03/2006 11:07 AM AEST:

Crazy Code Ninja wrote: [...]

alert( document.forms[0].elements['textbox'].value );
but you need to wrap your input fields with <form></form>

which you need to do anyway to create valid html.

Not at all - there is no requirement for input elements to be inside
form elements. They can appear anywhere in the body that an inline
element can appear.

 

[Crazy Code Ninja]

Right, I should have said its my preferred way from my experience.

Having said that, I still think it's not good if you have several input
fields with the same ID. If you have that many input fields in one page
that you have difficulty in not having unique IDs for each of them,
then its a sure sign that you should have split your page.

IDs should be unique, unlike class names. It will make maintenance
easier, server side scripting wise, CSS wise, as well as Javascript
wise.

Which is a bad practice. Use form names instead of indexes.

I was just warning him about my (quick crude simple) example, that it
assumes he has only one form.

getElementById is really the preferred way

Not really. Then you need to generate a unique ID for each input field and
add bloat to your page.

alert( document.forms[0].elements['textbox'].value );
but you need to wrap your input fields with <form></form>

which you need to do anyway to create valid html.

, and the
code above assumes you only have one <form></form> in the page.

Which is a bad practice. Use form names instead of indexes.

For more info, see http://www.JavascriptToolbox.com/bestpractices/

 

[Gérard Talbot]

Matt Kruse wrote :

Not really. Then you need to generate a unique ID for each input field

This is exactly what the HTML 4.01 recommendation says, btw:
"Applications should use the id attribute to identify elements."
http://www.w3.org/TR/html401/interact/forms.html#adef-name-FORM

and

add bloat to your page.

alert( document.forms[0].elements['textbox'].value );
but you need to wrap your input fields with <form></form>

which you need to do anyway to create valid html.

Not at all, as pointed out Rob.

Which is a bad practice. Use form names instead of indexes.

As I pointed to you before, name attribute has been formally deprecated
in XHTML 1.0.
"in XHTML 1.0, the name attribute of these elements (a, applet, form,
frame, iframe, img, and map) is formally deprecated"
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10
So, unless you're using lots of forms in a single page (why would you
need several forms in the same page is beyond my comprehension), using
indexes is not a big deal.
Matt, you propose *best* javascript practices that, in my humble
opinion, are not as portable as they can be.... at least, on this name
versus index issue. Best practices should always promote valid, safe,
sound practices which will work reliably across browser, across
different DTDs and across code context.

For more info, see http://www.JavascriptToolbox.com/bestpractices/

Gérard

 

[Crazy Code Ninja]

Not really. Then you need to generate a unique ID for each input field

This is exactly what the HTML 4.01 recommendation says, btw:
"Applications should use the id attribute to identify elements."
http://www.w3.org/TR/html401/interact/forms.html#adef-name-FORM

I'd still put name tag for older browsers, this is just my preferrence,
for example:

<input type="text" id="text1" name="text1" />

ofcourse this is a good practice (IMO) if you generate your html code
using server side script, otherwise leave it out to avoid having
different id/name.

Regards,

Sid

 

[Randy Webb]

Crazy Code Ninja said the following on 3/15/2006 11:06 PM:

I'd still put name tag for older browsers, this is just my preferrence,
for example:

<input type="text" id="text1" name="text1" />

ofcourse this is a good practice (IMO) if you generate your html code
using server side script, otherwise leave it out to avoid having
different id/name.

Then you need to re-read what has been deprecated. Its name attributes
on FORM's, not on the elements of forms.

 

[Randy Webb]

Gérard Talbot said the following on 3/15/2006 10:53 PM:

Matt Kruse wrote :


This is exactly what the HTML 4.01 recommendation says, btw:
"Applications should use the id attribute to identify elements."
http://www.w3.org/TR/html401/interact/forms.html#adef-name-FORM

I don't think my thoughts about the specs need to be repeated. But, for
curiosity sake, give all your form elements an id with no name, submit
it to the server, and let us know what you get?

Crippling form submission for the sake of complying with the specs isn't
a good idea.

and add bloat to your page.

alert( document.forms[0].elements['textbox'].value );
but you need to wrap your input fields with <form></form>

which you need to do anyway to create valid html.

Not at all, as pointed out Rob.

Agreed, but, I have never understood what an input element without a
form is good for in the absence of scripting.

As I pointed to you before, name attribute has been formally deprecated
in XHTML 1.0.
"in XHTML 1.0, the name attribute of these elements (a, applet, form,
frame, iframe, img, and map) is formally deprecated"
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10

For a long time, I posted code that looked like this:

document.forms['formNAMEnotID'].elements['elementNAMEnotID'].property

And I changed it to the following:

document.forms['ID'].elements['elementNAMEnotID'].property

Because of what you quoted (It was pointed out to me by Lasse).

But, to use XHTML as a defense/reason to use the ID on a form instead of
the NAME isn't a good argument. Witness IE's behavior with XHTML. (I
know, people reply with "content negotiation").

So, unless you're using lots of forms in a single page (why would you
need several forms in the same page is beyond my comprehension), using
indexes is not a big deal.

Multiple forms on the same page have there uses. What if you wanted a
search engine portal for 10 different search engines? You would have 10
different forms so you could post them to 10 different search engines.

Matt, you propose *best* javascript practices that, in my humble
opinion, are not as portable as they can be.... at least, on this name
versus index issue.

And if someone comes along behind you and adds a form before this one,
it breaks your code. With a name/ID attribute, that doesn't happen.
Which one is the better practice? There is no ambiguity with
document.forms['formID'] when there is with document.forms[#]

Best practices should always promote valid, safe,
sound practices which will work reliably across browser, across
different DTDs and across code context.

That alone makes the forms['formID'] a better practice than forms[#].
But, if it is going to be "across different DTD's" then you have to do
something different. Does HTML3.2 allow ID's on forms?

 

[Gérard Talbot]

Randy Webb wrote :

Gérard Talbot said the following on 3/15/2006 10:53 PM:

I don't think my thoughts about the specs need to be repeated.

I do not keep a log of what everyone says about this or that... so you
may have to repeat... and I'm getting old too


But, for

curiosity sake, give all your form elements an id with no name, submit
it to the server, and let us know what you get?

Of course, it does not make sense. Name/value pairs of form controls are
submitted to the server: that's why name was not deprecated for input,
select and form controls submitting data.
Maybe I may have totally misunderstood that quote from the spec. The
quote might refer only to the form element, not to its contained
elements. I don't know.

Crippling form submission for the sake of complying with the specs isn't
a good idea.

and add bloat to your page.

alert( document.forms[0].elements['textbox'].value );
but you need to wrap your input fields with <form></form>

which you need to do anyway to create valid html.

Not at all, as pointed out Rob.

Agreed, but, I have never understood what an input element without a
form is good for in the absence of scripting.

As I pointed to you before, name attribute has been formally
deprecated in XHTML 1.0.
"in XHTML 1.0, the name attribute of these elements (a, applet, form,
frame, iframe, img, and map) is formally deprecated"
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10

For a long time, I posted code that looked like this:

document.forms['formNAMEnotID'].elements['elementNAMEnotID'].property

And I changed it to the following:

document.forms['ID'].elements['elementNAMEnotID'].property

Because of what you quoted (It was pointed out to me by Lasse).

But, to use XHTML as a defense/reason to use the ID on a form instead of
the NAME isn't a good argument.

No, it's the other way. If you're using XHTML, then you can't "name"
your form. You have to access your form with the ordinal index. So,
using the ordinal index instead of the name attribute is more code
portable. That's all I'm saying. I don't necessarly want to promote
XHTML... but then again, there are people who (rightly or wrongly) use
XHTML.

Witness IE's behavior with XHTML. (I

know, people reply with "content negotiation").


Multiple forms on the same page have there uses. What if you wanted a
search engine portal for 10 different search engines? You would have 10
different forms so you could post them to 10 different search engines.

It's rather rare webpage situation... don't you think?

E.g.:
http://www.javascripttoolbox.com/bestpractices/
http://www.javascripttoolbox.com/
http://www.javascripttoolbox.com/lib/
http://www.javascripttoolbox.com/lib/mktree/
http://www.javascripttoolbox.com/lib/objectposition/
all have only 1 form element.

http://www.javascripttoolbox.com/lib/dynamicoptionlist/
has 2 form elements, with the first one without the name attribute.

http://www.javascripttoolbox.com/lib/checkboxgroup/
and
http://www.javascripttoolbox.com/lib/dragiframe/
both have 2 form elements, with both ones without resorting to the name
attribute. Both pages have a google search form.

And if someone comes along behind you and adds a form before this one,

This makes no sense to me. Unless several several people are developing
a same single website. Again, this is not common.
In a workplace, when coding practices are defined, this sort of issues
is explicited for all people adding code or removing code. Usually, only
1 person does make change and he documents these.

it breaks your code. With a name/ID attribute, that doesn't happen.
Which one is the better practice? There is no ambiguity with
document.forms['formID'] when there is with document.forms[#]

There is room for ambiguity *if* you have more than 1 form element, *if*
someone else is adding another form *before* without noticing the form
issue. I'd say right here that this is extraordinary rare.

Best practices should always promote valid, safe, sound practices
which will work reliably across browser, across different DTDs and
across code context.

That alone makes the forms['formID'] a better practice than forms[#].
But, if it is going to be "across different DTD's" then you have to do
something different. Does HTML3.2 allow ID's on forms?

I didn't propose id for forms.
One thing is for sure: best javascript practices - whatever they are -
should work in strict DTD (HTML 4.01 or XHTML). Coding for transitional
DTD is already not the best markup coding practice. Best javascript
practices has to be harmonized, coherent, consequent with (and based on)
best markup coding practices to begin with.

Gérard

 

[Randy Webb]

Gérard Talbot said the following on 3/16/2006 12:07 AM:

Randy Webb wrote :

I do not keep a log of what everyone says about this or that... so you
may have to repeat... and I'm getting old too

I have read the specs so many times that when I see people quote them I
almost know where to go find it before they tell me. But I still
wouldn't give you 10 cents American for all of them. They are a good
guideline but that is it. I prefer to know what the Browser's behavior
is compared to what it should be

But, for

Of course, it does not make sense. Name/value pairs of form controls are
submitted to the server: that's why name was not deprecated for input,
select and form controls submitting data.
Maybe I may have totally misunderstood that quote from the spec. The
quote might refer only to the form element, not to its contained
elements. I don't know.

From reading that section, and then the section following it on inputs,
I would say it is definitely in relation to the FORM element itself and
not its elements.

<!ENTITY % InputType
"(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
FILE | HIDDEN | IMAGE | BUTTON)"
<!-- attribute name required for all but submit and reset -->

And then in the attlist there is no ID. But further below that it says
"Attributes defined elsewhere" and lists the ID.

So, since it says that form elements are required to have a name it
wouldn't make sense for them to be deprecated

No, it's the other way. If you're using XHTML, then you can't "name"
your form. You have to access your form with the ordinal index.

Or it's ID

So, using the ordinal index instead of the name attribute is more code
portable. That's all I'm saying. I don't necessarly want to promote
XHTML... but then again, there are people who (rightly or wrongly) use
XHTML.

I think both of our opinions are right and both are wrong. The solution
is what best fits the situation

Witness IE's behavior with XHTML. (I

It's rather rare webpage situation... don't you think?

Probably so. When I wrote that I was thinking about a page I wrote for a
friend that orders parts. He has 11 vendors he uses and has to search
all 11 one at a time. I wrote him one that combines them all into one
page. But, it has 12 different forms it uses so he can search
individually and a "search them all" form. But for a web situation, the
most I have seen in practical use is 4 - my bank's website. It has one
for me to login, it has a Google search box (why I want to go to my
banks site to search Google is beyond me though), one for me to contact
the webmaster if I can't login and the fourth is a "I lost my password"
form.

This makes no sense to me. Unless several several people are developing
a same single website. Again, this is not common.
In a workplace, when coding practices are defined, this sort of issues
is explicited for all people adding code or removing code. Usually, only
1 person does make change and he documents these.

I want your job then. I don't get assignments that say "Here is the
page, this is what I need". It's more along the lines of "I want a
snippet/widget that does this, here's your deadline, here's your money,
where's my damn code".

it breaks your code. With a name/ID attribute, that doesn't happen.
Which one is the better practice? There is no ambiguity with
document.forms['formID'] when there is with document.forms[#]

There is room for ambiguity *if* you have more than 1 form element, *if*
someone else is adding another form *before* without noticing the form
issue. I'd say right here that this is extraordinary rare.

I don't. But it still goes back to "The best solution depends, directly,
on the situation". And if you want a "General Best Practice", you either
use the forms NAME or ID to access it. Then, it works in *all*
situations where the form has a NAME/ID.

Best practices should always promote valid, safe, sound practices
which will work reliably across browser, across different DTDs and
across code context.

That alone makes the forms['formID'] a better practice than forms[#].
But, if it is going to be "across different DTD's" then you have to do
something different. Does HTML3.2 allow ID's on forms?

I didn't propose id for forms.

Not directly. You said "Best practices should always promote valid,
safe, sound practices " and that makes forms['formID'] a better -
general - practice than forms[#] because it will work in more situations
than forms[#] will. That was my only point.

One thing is for sure: best javascript practices - whatever they are -
should work in strict DTD (HTML 4.01 or XHTML). Coding for transitional
DTD is already not the best markup coding practice. Best javascript
practices has to be harmonized, coherent, consequent with (and based on)
best markup coding practices to begin with.

I totally agree. But there still has to be a limit somewhere. Otherwise,
you lose the ability to keep a document "general" in scope. I had a
conversation with Richard a long time ago about this same thing. I wish
I could find the thread but I can't. But it was based on best practices
in general and the example that I used was changing the source of an
image. I can write for weeks on end about pre-loading, changing, and
loading images and would probably still miss some of the caveats and
problems with it. But to stay general, you have to limit yourself
somewhere and say "This is it". You change the source of an image by
using the images collection and changing it's src property. This is the
same principle. Somewhere, somehow, you have to limit yourself or you
end up making your guidelines so convoluted that you lose your general
audience by making it *too* complex by including all the caveats/problems.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

Please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers. <URL: http://www.safalra.com/special/googlegroupsreply/ >

 

[Matt Kruse]

Maybe I may have totally misunderstood that quote from the spec. The
quote might refer only to the form element, not to its contained
elements. I don't know.

As Randy pointed out, I think that is true.

I stand corrected. I had always believed it was invalid, but after looking
at the DTD I see I am wrong.

Agreed, which is why I guess I assumed they would need to be contained in a
form element.

Well first of all, I think XHTML is worthless. Second, few people are using
it and if they are then they probably already know how to reference a form.
Third, I think XHTML itself should be deprecated

No, it's the other way. If you're using XHTML, then you can't "name"
your form. You have to access your form with the ordinal index. So,
using the ordinal index instead of the name attribute is more code
portable.

In that case, though, I would recommend using the ID instead of the ordinal
index. I will make a note to update my best practices document with a
side-note for xhtml.

I use it regularly. Often a google search bar, for example, uses a separate
form. Also, I find it convenient to have multiple forms if a page shows
multiple logical groups of fields which can be edited for a big entity. Each
section can be updated separately (perhaps using "ajax") and each separate
form can have its own validation, etc. Also, in portals or other "mixed
content" applications, the designer of a section of the page may have his
own form and have no knowledge of what else may be on the page.

http://www.javascripttoolbox.com/lib/dynamicoptionlist/
has 2 form elements, with the first one without the name attribute.

Name isn't required. It's only useful when you actually want to reference
the form object, which I don't do on the page.

I think the best solution, as I said, is to make an exception for xhtml. For
regular html use, I think a form name is still the best practice. I do plan
to make a round of revisions to my best practices document, actually, to
make it more robust and to take into consideration the comments I've
received.

 

[Gérard Talbot]

Matt Kruse wrote :

Gérard Talbot wrote:

Well first of all, I think XHTML is worthless.

Matt, your appreciation or preference for XHTML is not the issue here.
If someone uses XHTML 1.0, then he can't safely use your best javascript
practices: that was my point.

Second, few people are using
it

That could be debatable (few is how much? %tage) and, anyway, that's
irrelevant to the issue addressed.

and if they are then they probably already know how to reference a form.

I disagree with your assumption here. You'd be surprised to see how many
XHTML-based documents are generated by DreamWeaver or Nvu nowadays where
amateur web authors, even paid ones, don't know how to reference a form.

Third, I think XHTML itself should be deprecated

[snipped]

I personally do not use XHTML. I personally do not recommend to use
XHTML. But that's not the issue here.

Gérard

 

[Crazy Code Ninja]

<rant>

I try to use xhtml practices as I can (e.g.: follow xml closing tag
rule, use lowercase, accessibility, etc), but I don't pressure myself
to conform to xhtml standard, I don't even use doctype! (gasp! oh the
horror, the 'd' word) Ok, so I won't ever win any medal for www
standard conformance, but who cares!

I don't see quirks-mode being abandoned in the future coz there is no
way people are going to fix all those billions old pages on the net!
Abandoning backward compatibility is suicidal for any browser.

</rant>

 

[Thomas 'PointedEars' Lahn]

Crazy Code Ninja wrote:

Please provide attribution of quoted material.
<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>

"Applications" refers to HTML user agents of course, not "Web
applications" (with client-side scripting). Otherwise it would
be completely ignored that such a recommendation forced "Web
applications" (such as that of the OP) to use not backwards
compatible referencing.

Understand that the HTML Specification is primarily for HTML
implementors, not "Web application" developers:

I'd still put name tag for older browsers,

this is just my preferrence, for example:

<input type="text" id="text1" name="text1" />

That is a `name' attribute, within the start tag of an `input' element.
It is entirely redundant here. And the HTML 4.01 Specification makes it
clear what should be considered with IDs:

<URL:http://www.w3.org/TR/html401/struct/links.html#anchors-with-id>

Using a `name' attribute or not for those elements does not have anything
to do with "older browsers"; the forms-elements referencing defined by W3C
DOM 2 HTML is both standards compliant and backwards compatible. You are
required to name your form controls if you want their value to be
submitted. That is why there is still a `name' attribute for form controls
in HTML 4.01 Strict, XHTML 1.0 Strict and even in the Forms modules of
XHTML 1.1.


PointedEars

 

[Thomas 'PointedEars' Lahn]

<rant>

I try to use xhtml practices as I can (e.g.: follow xml closing tag

"XHTML practices" is utter nonsense.

rule, use lowercase, accessibility, etc), but I don't pressure myself
to conform to xhtml standard, I don't even use doctype!

A DOCTYPE declaration is required for _all_ SGML-based markup languages,
not only XHTML.

(gasp! oh the horror, the 'd' word) Ok, so I won't ever win any medal
for www standard conformance, but who cares!

Obviously you do not care about your visitors as you do not care about
interoperability. But then, who cares about you.


PointedEars

 

[Crazy Code Ninja]

Don't take my post out of context, I also said:

I don't see quirks-mode being abandoned in the future coz there is no
way people are going to fix all those billions old pages on the net!
Abandoning backward compatibility is suicidal for any browser.

If quirksmode almost certainly will always exist, why should I spend so
much time trying to "fix" my pages and be limited? Oh to adhere to
standards?

Besides, why do we have many different DTDs for? There should only be
one, the one that works! and to me that's the quirksmode. We spend so
much time trying to be compliant to these standards, but one tiny
mistake and the browser will switch back to quirksmode anyway.

For example: trademe.co.nz has a doctype, they probably tried to
comply, yet the w3c validator said it isn't valid
(http://validator.w3.org/check?uri=www.trademe.co.nz), and if you look,
its invalid for some tiny insignificant mistakes, not for missing
closing tag, or something like that. So I guess the browser will render
it in quirksmode afterall.Time wasted trying to comply to a doctype.

Obviously you do not care about your visitors as you do not care about
interoperability. But then, who cares about you.

I care about my visitors and interoperability, I don't care about
standards.

I only put doctype if client especially ask for it, e.g.: government
agency. But even the government has wasted their money too, check this
out: http://validator.w3.org/check?uri=www.nzis.govt.nz

 

[Matt Kruse]

If quirksmode almost certainly will always exist, why should I spend
so much time trying to "fix" my pages and be limited? Oh to adhere to
standards?

You have a significant misunderstanding of quirks mode.

Quirks mode != valid HTML

The advantage of standards mode is that browsers like IE will behave more
closely to the standards and other browsers. So you can write your HTML
correctly once and have it work the same across more browsers. Having your
page in quirks mode retains fundamental differences which make it more
difficult to create cross-browser pages.

Just because a browser is in standards mode doesn't mean the HTML must
validate.

Besides, why do we have many different DTDs for?

Read up on the history of HTML.

We spend so
much time trying to be compliant to these standards, but one tiny
mistake and the browser will switch back to quirksmode anyway.

That's not true. Just because a document doesn't validate to strict dtd, for
example, doesn't mean it will trigger quirks mode.

For example: trademe.co.nz has a doctype, they probably tried to
comply, yet the w3c validator said it isn't valid
(http://validator.w3.org/check?uri=www.trademe.co.nz), and if you
look, its invalid for some tiny insignificant mistakes, not for
missing closing tag, or something like that. So I guess the browser
will render it in quirksmode afterall.
Wrong.

I only put doctype if client especially ask for it

Then you're doing your clients no favor!