Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16251 > unrolled thread

document.elementname vs document.getElementById("id")

Back to article view | Back to comp.lang.javascript

Contents

  document.elementname vs document.getElementById("id") Denis McMahon <denismfmcmahon@gmail.com> - 2012-09-29 18:15 +0000
    Re: document.elementname vs document.getElementById("id") Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-29 22:17 +0200
    Re: document.elementname vs document.getElementById("id") dann90038@gmail.com - 2012-09-29 16:21 -0700
    Re: document.elementname vs document.getElementById("id") "J.R." <groups_jr-1@yahoo.com.br> - 2012-09-29 23:20 -0300
      Re: document.elementname vs document.getElementById("id") "J.R." <groups_jr-1@yahoo.com.br> - 2012-09-29 19:53 -0700
      Re: document.elementname vs document.getElementById("id") "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-09-30 11:02 +0300
        Re: document.elementname vs document.getElementById("id") Denis McMahon <denismfmcmahon@gmail.com> - 2012-09-30 13:10 +0000
        Re: document.elementname vs document.getElementById("id") Denis McMahon <denismfmcmahon@gmail.com> - 2012-09-30 13:14 +0000
          Re: document.elementname vs document.getElementById("id") "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-09-30 17:20 +0300
            Re: document.elementname vs document.getElementById("id") Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2012-09-30 21:09 +0200
              Re: document.elementname vs document.getElementById("id") "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-09-30 22:28 +0300
                Re: document.elementname vs document.getElementById("id") Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2012-09-30 21:53 +0200
              Re: document.elementname vs document.getElementById("id") Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-30 21:53 +0200
            Re: document.elementname vs document.getElementById("id") Denis McMahon <denismfmcmahon@gmail.com> - 2012-09-30 22:07 +0000
              Re: document.elementname vs document.getElementById("id") "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-01 06:23 +0300
                Re: document.elementname vs document.getElementById("id") Denis McMahon <denismfmcmahon@gmail.com> - 2012-10-01 08:11 +0000
                  Re: document.elementname vs document.getElementById("id") Stefan Weiss <krewecherl@gmail.com> - 2012-10-01 11:25 +0200
        Re: document.elementname vs document.getElementById("id") "J.R." <groups_jr-1@yahoo.com.br> - 2012-09-30 15:10 -0300
          Re: document.elementname vs document.getElementById("id") Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-30 20:43 +0200
      Re: document.elementname vs document.getElementById("id") Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-30 12:22 +0200
        Re: document.elementname vs document.getElementById("id") "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-09-30 13:44 +0300
          Re: document.elementname vs document.getElementById("id") Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-09-30 13:46 +0200
    Re: document.elementname vs document.getElementById("id") Dr J R Stockton <reply1239@merlyn.demon.co.uk.invalid> - 2012-09-30 20:10 +0100

Page 1 of 2  [1] 2  Next page →

#16251 — document.elementname vs document.getElementById("id")

Gaaah

I'm fairly certain there's a reason that I think this is a "bad" idea ... 
apart from anything else an element name parameter is not guaranteed to 
be unique within a document - but I haven't easily been able to find a 
suitable reference for why not to do this, anyone got one?

I'm arguing to replace using document.formname to identify forms with 
assigning an id to the forms involved and using document.getElementById
("formid").*, but the best arguments I can think of at the moment (more 
robust to future changes, better compatibility with developing standards, 
more maintainable) are butting up against "don't fix it until it needs 
fixing", whereas I prefer to prevent future breakage, rather than react 
to it.

I'm pretty certain that using document.getElementById("id") is better 
than using document.elementname, but at the moment I'm having trouble 
pointing to any sort of authoritative reference for this.

[1] It was document.all.formname which was breaking, a very senior coder 
(but not actually a web / js coder) "fixed" it by changing 
document.all.formname to document.formname, but I think the fix is almost 
as prone to future breakage as the original code was, and would prefer to 
see document.getElementById("formid") used instead, with approriate IDs 
allocated to forms.

Rgds

Denis McMahon

[toc] | [next] | [standalone]

#16252

Denis McMahon wrote:

> Gaaah

Feel better.
 
> I'm fairly certain there's a reason that I think this is a "bad" idea ...
> apart from anything else an element name parameter is not guaranteed to
> be unique within a document -

"Parameter"?

> but I haven't easily been able to find a suitable reference for why not to
> do this, anyone got one?
> 
> I'm arguing to replace using document.formname to identify forms with
> assigning an id to the forms involved and using document.getElementById
> ("formid").*, but the best arguments I can think of at the moment (more
> robust to future changes, better compatibility with developing standards,
> more maintainable) are butting up against "don't fix it until it needs
> fixing", whereas I prefer to prevent future breakage, rather than react
> to it.

The two are not semantically equivalent to begin with.

> I'm pretty certain that using document.getElementById("id") is better
> than using document.elementname, but at the moment I'm having trouble
> pointing to any sort of authoritative reference for this.

One is standards-compliant [DOM2Core]/[DOM3Core]; the other is not [DOM0].  
One is accessing the ID namespace, the other one is accessing the id+name 
namespace [SO], and a property of the object referred to by `document'.  
That object has properties that are not holding a reference to a form 
element object.  Insofar the latter referencing is not only proprietary, it 
is also more error-prone.

> [1] It was document.all.formname which was breaking, a very senior coder
> (but not actually a web / js coder) "fixed" it by changing
> document.all.formname to document.formname, but I think the fix is almost
> as prone to future breakage as the original code was, and would prefer to
> see document.getElementById("formid") used instead, with approriate IDs
> allocated to forms.

They should have replaced it at least with document.forms["formname"] as 
specified in [DOM2HTML], [HTML5WD], [HTML5ED], and [WHATWG-HTML].  This 
would work both with names and IDs, with names being the most backwards-
compatible approach (down to [DOM0] as introduced with Netscape Navigator 
3.0 and Internet Explorer 3.0 [DOM2HTMLGloss]).

However, if there were two forms with the same name (valid) or same ID 
(invalid) in the document, the property value would (likely) be a NodeList 
of Elements, contradicting [DOM2HTML], and the first item with that name of 
a HTMLCollection per [HTML5WD], [HTML5ED] and [WHATWG-HTML] as defined in 
[DOM4] §8.2 and [WHATWG-DOM] §8.2, respectively¹.


PointedEars
___________
¹  It is actually *unspecified* in [DOM2HTML] what the namedItem() method of
   objects implementing the HTMLCollection interface is to return if there
   is more than one item with a matching `name' attribute.  Given that the
   return value is specified in [DOM2HTML] to be "*The* Node with a name or
   id attribute whose value corresponds to the specified string.  Upon
   failure (e.g., no node with this name exists), returns null.", the
   [DOM4]/[WHATWG-DOM] clarification was probably intended from the
   beginning.

   However, AFAIK it is implemented *differently* *everywhere* (from a
   NodeList to a HTMLCollection return value), even in browsers that claim
   to implement "HTML 5" (and whose vendors are represented in either the
   W3C WGs, or the WHATWG, or both).  Which will probably need to be fixed
   in the specifications instead of in the implementations, as following
   [DOM0] there are plenty of forms out there that have controls with the
   same name (for example, to make an array with the `[]' prefix in PHP),
   use client-side scripting to access them (e. g., for form validation),
   and would break otherwise.

References:

[SO]
<http://stackoverflow.com/questions/9158238/why-js-function-name-conflicts-
with-element-id/9160009#9160009>

[DOM2Core]
<http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html
#i-Document>

[DOM3Core]
<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html
#ID-getElBId>

[HTML4]
<http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#adef-id>

[DOM2HTMLGloss]
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/glossary.html>

[DOM2HTML]
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html
#ID-75708506>

[HTML5WD]
<http://www.w3.org/TR/2012/WD-html5-20120329/dom.html#dom-document-forms>

[HTML5ED]
<http://dev.w3.org/html5/spec/dom.html#dom-document-forms>
(Editor's Draft 2012-09-28)

[WHATWG-HTML]
<http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html
#dom-document-forms>
(Living Standard 2012-09-28)

[DOM4]
<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html>
(Editor's Draft 2012-07-07)

[WHATWG-DOM]
<http://dom.spec.whatwg.org/>
(Living Standard 2012-09-27)

[DOM0]
(Netscape) Client-side JavaScript 1.3 Reference (archived)
<http://docs.oracle.com/cd/E19957-01/816-6408-10/document.htm#1193750>

-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#16257

AFAIK document.all.SOMENAMEHERE was mainly IE stuff, later on added by other browsers for the sake of code compatibility, all along proprietary originally(one can say the same about much of the standards at some point though), however it never became standard.  On the other hand document.forms[FORMNAMEHERE] uses a forms stack which has been standard since js 1.3 if I recall correctly, might have been earlier.

As far as using the DOM engine to query for an object, my understanding from the past has been that DOM engine queries can be rather expensive comparatively to more optimized native objects in js.  At least semantically I can see from:

     document.forms[MYSHARONA];
     document.getElementById('MYSHARONA');

that the former has a narrower object stack to loop through.

As far as document.MYSHARONA to address an element in the document namespace, seems to me will just lead the parser to query more HTMLElements than necessary and yield a query just as expensive as the DOM one.

[toc] | [prev] | [next] | [standalone]

#16260

On 29/09/2012 15:15, Denis McMahon wrote:
> Gaaah
>
> I'm fairly certain there's a reason that I think this is a "bad" idea ...
> apart from anything else an element name parameter is not guaranteed to
> be unique within a document - but I haven't easily been able to find a
> suitable reference for why not to do this, anyone got one?

Perhaps you are thinking of an ID instead of a name attribute.

>
> I'm arguing to replace using document.formname to identify forms with
> assigning an id to the forms involved and using document.getElementById
> ("formid").*, but the best arguments I can think of at the moment (more
> robust to future changes, better compatibility with developing standards,
> more maintainable) are butting up against "don't fix it until it needs
> fixing", whereas I prefer to prevent future breakage, rather than react
> to it.

document.formname is okay with HTML 4. You may use the W3C Markup 
Validation Service to check if an element should have an ID.

> I'm pretty certain that using document.getElementById("id") is better
> than using document.elementname, but at the moment I'm having trouble
> pointing to any sort of authoritative reference for this.

I recall MSIE used to pollute the global namespace with elements' names 
or IDs, that is, we could get a reference to an element using 
document.elementname or document.elementID. See 
<http://webbugtrack.blogspot.com.br/2007/09/bug-162-global-namespace-pollution-in.html>

The W3C standards compliant browsers use document.getElementById("ID") 
which is DOM level 1 (1998). Interestingly, Firefox still allows 
references in the old way (document.elementID or formName.elementName) 
when a page is rendered in "quirks mode".

>
> [1] It was document.all.formname which was breaking, a very senior coder
> (but not actually a web / js coder) "fixed" it by changing
> document.all.formname to document.formname, but I think the fix is almost
> as prone to future breakage as the original code was, and would prefer to
> see document.getElementById("formid") used instead, with approriate IDs
> allocated to forms.

Yes, this sort of "fix" is error prone. But a form's ID is not required 
in HTML 4 - only XHTML pages should require IDs:
<http://www.w3.org/TR/xhtml1/diffs.html>


-- 
--
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#16261

On Saturday, 29 September 2012 23:20:12 UTC-3, J.R.  wrote:
> On 29/09/2012 15:15, Denis McMahon wrote:
> 
> > Gaaah
> 
> >
> 
> > I'm fairly certain there's a reason that I think this is a "bad" idea ...
> 
> > apart from anything else an element name parameter is not guaranteed to
> 
> > be unique within a document - but I haven't easily been able to find a
> 
> > suitable reference for why not to do this, anyone got one?
> 
> 
> 
> Perhaps you are thinking of an ID instead of a name attribute.
> 
> 
> 
> >
> 
> > I'm arguing to replace using document.formname to identify forms with
> 
> > assigning an id to the forms involved and using document.getElementById
> 
> > ("formid").*, but the best arguments I can think of at the moment (more
> 
> > robust to future changes, better compatibility with developing standards,
> 
> > more maintainable) are butting up against "don't fix it until it needs
> 
> > fixing", whereas I prefer to prevent future breakage, rather than react
> 
> > to it.
> 
> 
> 
> document.formname is okay with HTML 4. You may use the W3C Markup 
> 
> Validation Service to check if an element should have an ID.
> 
> 
> 
> > I'm pretty certain that using document.getElementById("id") is better
> 
> > than using document.elementname, but at the moment I'm having trouble
> 
> > pointing to any sort of authoritative reference for this.
> 
> 
> 
> I recall MSIE used to pollute the global namespace with elements' names 
> 
> or IDs, that is, we could get a reference to an element using 
> 
> document.elementname or document.elementID. See 
> 
> <http://webbugtrack.blogspot.com.br/2007/09/bug-162-global-namespace-pollution-in.html>
> 
> 
> 
> The W3C standards compliant browsers use document.getElementById("ID") 
> 
> which is DOM level 1 (1998). Interestingly, Firefox still allows 
> 
> references in the old way (document.elementID or formName.elementName) 
> 
> when a page is rendered in "quirks mode".
> 
> 
> 
> >
> 
> > [1] It was document.all.formname which was breaking, a very senior coder
> 
> > (but not actually a web / js coder) "fixed" it by changing
> 
> > document.all.formname to document.formname, but I think the fix is almost
> 
> > as prone to future breakage as the original code was, and would prefer to
> 
> > see document.getElementById("formid") used instead, with approriate IDs
> 
> > allocated to forms.
> 
> 
> 
> Yes, this sort of "fix" is error prone. But a form's ID is not required 
> 
> in HTML 4 - only XHTML pages should require IDs:
> 
> <http://www.w3.org/TR/xhtml1/diffs.html>
> 

TJ Van Toll is telling us that FF 14 and other recent versions of major browsers implement document.elementName either in quirks or strict mode:
<http://tjvantoll.com/2012/07/19/dom-element-references-as-global-variables/>

OMG.

--
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#16264

2012-09-30 5:20, J.R. wrote:

> On 29/09/2012 15:15, Denis McMahon wrote:
>> Gaaah
>>
>> I'm fairly certain there's a reason that I think this is a "bad" idea ...
>> apart from anything else an element name parameter is not guaranteed to
>> be unique within a document - but I haven't easily been able to find a
>> suitable reference for why not to do this, anyone got one?
>
> Perhaps you are thinking of an ID instead of a name attribute.

The question, including the Subject line, is somewhat confused, but the 
question is sufficiently clearly formulated in the text you quoted next:

>> I'm arguing to replace using document.formname to identify forms with
>> assigning an id to the forms involved and using document.getElementById
>> ("formid").*

So there's no "perhaps" about it: pages are now using <form ... 
name="foobar"> in HTML and document.foobar in JavaScript and would be 
using <form ... id="zipzap"> in HTML and 
document.getElementById('zipzap') in JavaScript.

The short answer is: change your habits but not existing code. For new 
pages, use the modern, logical way. For old pages, remember that any fix 
will introduce errors with a nonignorable probability, so don't do fixes 
just to "clean things up"

> document.formname is okay with HTML 4.

Actually, no. Check it out, from the specs or using a validator. HTML 4, 
i.e. 4.0, does not allow the name attribute for <form>, and the spec 
says nothing about allowed constructs in JavaScript. HTML 4 is 
effectively forgotten, and better kept that way. And HTML 4.01 has just 
a few changes from it, but they include this part: <form ... name="..."> 
is valid in HTML 4.01.

> You may use the W3C Markup
> Validation Service to check if an element should have an ID.

How would you do that? The id attribute is not *required* in any version 
of HTML.

>> I'm pretty certain that using document.getElementById("id") is better
>> than using document.elementname, but at the moment I'm having trouble
>> pointing to any sort of authoritative reference for this.

It should not be hard to find an authoritative reference: HTML 4.01 
spec, describing the <form> element, says the following about the name 
attribute:

"This attribute names the element so that it may be referred to from 
style sheets or scripts. Note. This attribute has been included for 
backwards compatibility. Applications should use the id attribute to 
identify elements."

http://www.w3.org/TR/html401/interact/forms.html#adef-name-FORM

> Interestingly, Firefox still allows
> references in the old way (document.elementID or formName.elementName)
> when a page is rendered in "quirks mode".

You are confusing support to document.foobar (when accessing a <form> 
element that has name="foobar") with issues like making id attribute 
values properties of the document object. The topic is confusing enough 
without such distractions.

> Yes, this sort of "fix" is error prone. But a form's ID is not required
> in HTML 4 - only XHTML pages should require IDs:
> <http://www.w3.org/TR/xhtml1/diffs.html>

The id attribute is not required in any version of HTML, including any 
version of XHTML.

The language of W3C documents is sometimes sloppy and may mislead you if 
you read it carelessly and without reading the context. What
http://www.w3.org/TR/xhtml1/diffs.html#h-4.10
(as well as the HTML 4.01 spec clause I mentioned earlier) is trying to 
say that you should not use the name attribute of a <form> element to 
refer to the element (which is the only reason for having that attribute 
in the first place) but some other, more logically designed way of 
identifying an element. The id attribute just happens to be the most 
handy tool for the purpose in simple cases.

There are many other ways to identify an element, and you may need to 
use one e.g. when you just cannot modify the HTML source of a document 
for some reason. For example, most pages have just a single form 
element, and then you can simply use

document.getElementsByTagName('form')[0]

This is however not quite as robust as using an id attribute, since some 
day someone might add another <form> element and place it before yours. 
(In balance, someone might also add another element with the same id 
attribute. That would be a reportable markup error, e.g. would be 
flagged by a validator, but how many people actually validate their 
markup after each and every change?)

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#16271

On Sun, 30 Sep 2012 11:02:52 +0300, Jukka K. Korpela wrote:

> "This attribute names the element so that it may be referred to from
> style sheets or scripts. Note. This attribute has been included for
> backwards compatibility. Applications should use the id attribute to
> identify elements."
> 
> http://www.w3.org/TR/html401/interact/forms.html#adef-name-FORM

Many thanks, that's the bit I was having trouble finding.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#16272

On Sun, 30 Sep 2012 11:02:52 +0300, Jukka K. Korpela wrote:

> The short answer is: change your habits but not existing code. For new
> pages, use the modern, logical way. For old pages, remember that any fix
> will introduce errors with a nonignorable probability, so don't do fixes
> just to "clean things up"

Ah

But the existing code is broken: document.all.formname

Very Senior Coder but not a web guy thinks that because it works now on 
his browser of choice, document.formname is a valid fix

I'm arguing that the correct fix is to convert broken 
document.all.formname to document.getElementById("formid") and assign ids 
to forms as appropriate.

i.e. this isn't cleaning things up for the sake of it, this is fixing 
currently broken code.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#16274

2012-09-30 16:14, Denis McMahon wrote:

> But the existing code is broken: document.all.formname

It does not work on modern browsers in "standards mode". But if the 
pages now use such constructs and generally work in browsers, then the 
pages are apparently processed in "quirks mode". So fixing the construct 
is irrelevant as long as you are not changing the mode - and such a 
change is a major effort and usually pointless for legacy pages.

> Very Senior Coder but not a web guy thinks that because it works now on
> his browser of choice, document.formname is a valid fix

Is a fix needed at all? That is, on which browsers do the pages fail to 
work, and do you know why?

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#16278

"Jukka K. Korpela" <jkorpela@cs.tut.fi> writes:

> 2012-09-30 16:14, Denis McMahon wrote:
>
>> But the existing code is broken: document.all.formname
>
> It does not work on modern browsers in "standards mode".

s/modern browsers/Firefox

(as far as mainstream desktop browsers are concerned)

> But if the
> pages now use such constructs and generally work in browsers, then the
> pages are apparently processed in "quirks mode". So fixing the
> construct is irrelevant [...]

That is patently bad advice.

[toc] | [prev] | [next] | [standalone]

#16280

2012-09-30 22:09, Eric Bednarz wrote:

> "Jukka K. Korpela" <jkorpela@cs.tut.fi> writes:
>
>> 2012-09-30 16:14, Denis McMahon wrote:
>>
>>> But the existing code is broken: document.all.formname
>>
>> It does not work on modern browsers in "standards mode".
>
> s/modern browsers/Firefox

Well, if it generally works on modern browsers except Firefox in 
"standards mode", the question "why fix it?" is even more emphatic.

>> But if the
>> pages now use such constructs and generally work in browsers, then the
>> pages are apparently processed in "quirks mode". So fixing the
>> construct is irrelevant [...]
>
> That is patently bad advice.

Oh, why?

If pages now work in "quirks mode", then there is seldom any good reason 
to spend time in "fixing" them to work in "standards mode". Part of this 
is the complexity of "quirks mode". There can be a wide range of 
problems lurking around if you switch to "standards" mode. It is much 
more productive to concentrate on keeping the content OK and on creating 
new pages (and in the latter, you would of course use as 
"standard-conforming" techniques as possible).

(If, however, someone is really considering the effort of converting an 
existing site from "quirks" to "standards", then he could consider 
changing document.all.formname to document.formname. But this would be a 
rather trivial part of the job.)

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#16282

"Jukka K. Korpela" <jkorpela@cs.tut.fi> writes:

> 2012-09-30 22:09, Eric Bednarz wrote:
>
>> "Jukka K. Korpela" <jkorpela@cs.tut.fi> writes:

[document.all collection]

>>> It does not work on modern browsers in "standards mode".
>>
>> s/modern browsers/Firefox
>
> Well, if it generally works on modern browsers except Firefox in
> "standards mode", the question "why fix it?" is even more emphatic.
>
>>> But if the
>>> pages now use such constructs and generally work in browsers, then the
>>> pages are apparently processed in "quirks mode". So fixing the
>>> construct is irrelevant [...]
>>
>> That is patently bad advice.
>
> Oh, why?

The page being in "quirks mode" was your conclusion, based on your own
false assumption. You might be right by accident, of course, that
happens a lot in client-side scripting (my rule of thumb is: three
strikes and the offender starts writing a GP library :-).

[toc] | [prev] | [next] | [standalone]

#16281

Eric Bednarz wrote:

> "Jukka K. Korpela" <jkorpela@cs.tut.fi> writes:
>> 2012-09-30 16:14, Denis McMahon wrote:
>>> But the existing code is broken: document.all.formname
>> It does not work on modern browsers in "standards mode".
> 
> s/modern browsers/Firefox
> 
> (as far as mainstream desktop browsers are concerned)

ACK, it does work, for example, in Chromium 21 in document.compatMode === 
"CSS1Compat" (Standards Compliance Mode).  One should get rid of it (or at 
least does not prefer the corresponding branch) anyway.  One, it is 
comparably inefficient; two, it is comparably error-prone; three, it is 
*proprietary*.
 
>> But if the pages now use such constructs and generally work in browsers,
>> then the pages are apparently processed in "quirks mode". So fixing the
>> construct is irrelevant [...]
> 
> That is patently bad advice.

ACK.  It is primarily the undocumented, or poorly documented, uncertainties 
of the different Quirks/Compatibility Modes of different browsers and 
versions that bite you later, particulary with client-side DOM scripting.  
What is working today may very well break tomorrow.  Not so with Web 
standards (of whatever flavor), as today's browser vendors do strive to make 
their software *more* standards-compliant.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#16287

On Sun, 30 Sep 2012 17:20:53 +0300, Jukka K. Korpela wrote:

> 2012-09-30 16:14, Denis McMahon wrote:

>> Very Senior Coder but not a web guy thinks that because it works now on
>> his browser of choice, document.formname is a valid fix

> Is a fix needed at all? That is, on which browsers do the pages fail to
> work, and do you know why?

Very Senior Coder decided it needed fixing because it was broken on his 
choice of browser / platform, so he made it work for him. The web page is 
a combined runtime tracker and source code display.

I won the argument of to fix or not to fix by sending him the list of W3C 
validator errors in the end - the page is served as xhtml 1.0 strict. In 
the process of making it validate, I brought other things into line with 
better practice as previously mentioned.

If we're serving a page claiming to be validated xhtml 1.0 strict, then 
IMO it had damn well better validate. The framework on this website wraps 
all web pages in the doctype and claims validation, so my position is 
that doctype compliance is essential. If other stuff gets scooped up in 
the process of making any non compliant pages compliant, that's a bonus 
that shouldn't hurt anything!

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#16293

2012-10-01 1:07, Denis McMahon wrote:

> Very Senior Coder decided it needed fixing because it was broken on his
> choice of browser / platform, so he made it work for him.
[...]
> I won the argument of to fix or not to fix by sending him the list of W3C
> validator errors

This seems to say that you persuaded him to fix it after he had fixed 
it. Apparently, Very Senior Coder was at some point using a Firefox 
version that refuses to recognize document.all in "standards" mode. Or 
maybe he was fixing something completely different and happened to 
change document.all.formname to document.formname en passant. It often 
happens that we think we fixed something by doing something specific but 
actually changed a lot of things and the thing that fixed our problem 
was a different one.

> If we're serving a page claiming to be validated xhtml 1.0 strict, then
> IMO it had damn well better validate.

Whether it validates or not has as such nothing to do with how it works 
on browsers. The presence of a doctype only affects the mode of the 
browser (mainly "quirks" vs. "standards"), but for this, it is 
completely immaterial whether the markup conforms to the document type 
definition.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#16295

On Mon, 01 Oct 2012 06:23:13 +0300, Jukka K. Korpela wrote:

> 2012-10-01 1:07, Denis McMahon wrote:
> 
>> Very Senior Coder decided it needed fixing because it was broken on his
>> choice of browser / platform, so he made it work for him.
> [...]
>> I won the argument of to fix or not to fix by sending him the list of
>> W3C validator errors
> 
> This seems to say that you persuaded him to fix it after he had fixed
> it. Apparently, Very Senior Coder was at some point using a Firefox
> version that refuses to recognize document.all in "standards" mode. Or
> maybe he was fixing something completely different and happened to
> change document.all.formname to document.formname en passant. It often
> happens that we think we fixed something by doing something specific but
> actually changed a lot of things and the thing that fixed our problem
> was a different one.

He said the only change he made was in the js, changing 
document.all.formname to document.formname. The RCS logs tend to confirm 
that this was the only change he made:

rcsdiff -r1.9 -r1.8 .../runtime_browser.c
===================================================================
RCS file: .../RCS/runtime_browser.c,v
retrieving revision 1.9
retrieving revision 1.8
diff -r1.9 -r1.8
270c270
<               "document.choose_runtime.innerHTML = "
---
>               "document.all.choose_runtime.innerHTML = "

The previous change to the file was in 2009, and the subsequent one was 
my xhtml validation fixes, so I'm pretty sure that what he said he did 
was what he actually did. ;)

The argument I won was to not use the name attribute in the form at all, 
because we're serving the pages as xhtml 1.0 strict and there is no name 
attribute for a form element in that dtd!

>> If we're serving a page claiming to be validated xhtml 1.0 strict, then
>> IMO it had damn well better validate.
> 
> Whether it validates or not has as such nothing to do with how it works
> on browsers. The presence of a doctype only affects the mode of the
> browser (mainly "quirks" vs. "standards"), but for this, it is
> completely immaterial whether the markup conforms to the document type
> definition.

Agreed, but if the page is broken, making sure the (x)html is valid to 
the dtd is always a good starting point.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#16297

On 2012-10-01 10:11, Denis McMahon wrote:
> The RCS logs tend to confirm that this was the only change he made:
> 
> rcsdiff -r1.9 -r1.8 .../runtime_browser.c
> ===================================================================
> RCS file: .../RCS/runtime_browser.c,v
> retrieving revision 1.9
> retrieving revision 1.8

Oh look, RCS... I sense the Very Senior Coder's hands at work again.
It seems that not only your DOM access methods were outdated, but also
your development toolchain ;)

It's true that fixing things that still work may introduce new bugs;
that's the downside of actively maintaining something. The upside is
that you don't have to "throw it all away and rewrite it" every five years.

If somebody's paying for the maintainance, I'd say go for it and do it
right. If they're too cheap to pay for it, let them suffer the periodic
catastrophes.

> we're serving the pages as xhtml 1.0 strict

Are your really sure about that? The typical case is that the web
developers use XHTML, believing it to be "as strict as you can get", but
then the documents are served as text/html, which pretty much defeats
the whole purpose.


- stefan

[toc] | [prev] | [next] | [standalone]

#16276

Em 30-09-2012 05:02, Jukka K. Korpela escreveu:
> 2012-09-30 5:20, J.R. wrote:
>
>> On 29/09/2012 15:15, Denis McMahon wrote:
>>> Gaaah
>>>
>>> I'm fairly certain there's a reason that I think this is a "bad" idea
>>> ...
>>> apart from anything else an element name parameter is not guaranteed to
>>> be unique within a document - but I haven't easily been able to find a
>>> suitable reference for why not to do this, anyone got one?
>>
>> Perhaps you are thinking of an ID instead of a name attribute.
>
> The question, including the Subject line, is somewhat confused, but the
> question is sufficiently clearly formulated in the text you quoted next:
>
>>> I'm arguing to replace using document.formname to identify forms with
>>> assigning an id to the forms involved and using document.getElementById
>>> ("formid").*
>
> So there's no "perhaps" about it: pages are now using <form ...
> name="foobar"> in HTML and document.foobar in JavaScript and would be
> using <form ... id="zipzap"> in HTML and
> document.getElementById('zipzap') in JavaScript.
>
> The short answer is: change your habits but not existing code. For new
> pages, use the modern, logical way. For old pages, remember that any fix
> will introduce errors with a nonignorable probability, so don't do fixes
> just to "clean things up"

ACK. I committed this mistake a few months ago, updating legacy 
client-side JavaScript code, HTML markup and CSS in an "ancient" 
intranet system, in order to have pages rendered in strict mode. After 
that update, unexpected problems arose like strange client-side JS 
errors, because almost all intranet pages (classic ASP) were in quirks 
mode...

>> document.formname is okay with HTML 4.
>
> Actually, no. Check it out, from the specs or using a validator. HTML 4,
> i.e. 4.0, does not allow the name attribute for <form>, and the spec
> says nothing about allowed constructs in JavaScript. HTML 4 is
> effectively forgotten, and better kept that way. And HTML 4.01 has just
> a few changes from it, but they include this part: <form ... name="...">
> is valid in HTML 4.01.

ACK.

>> You may use the W3C Markup
>> Validation Service to check if an element should have an ID.
>
> How would you do that? The id attribute is not *required* in any version
> of HTML.

That's why I referred to the "W3C Validator", because it can tell if an 
ID attribute is required or not. Besides, W3C Validator works with XHTML 
pages too.

>>> I'm pretty certain that using document.getElementById("id") is better
>>> than using document.elementname, but at the moment I'm having trouble
>>> pointing to any sort of authoritative reference for this.
>
> It should not be hard to find an authoritative reference: HTML 4.01
> spec, describing the <form> element, says the following about the name
> attribute:
>
> "This attribute names the element so that it may be referred to from
> style sheets or scripts. Note. This attribute has been included for
> backwards compatibility. Applications should use the id attribute to
> identify elements."
>
> http://www.w3.org/TR/html401/interact/forms.html#adef-name-FORM
>
>> Interestingly, Firefox still allows
>> references in the old way (document.elementID or formName.elementName)
>> when a page is rendered in "quirks mode".
>
> You are confusing support to document.foobar (when accessing a <form>
> element that has name="foobar") with issues like making id attribute
> values properties of the document object. The topic is confusing enough
> without such distractions.

I think that Denis McMahon was dealing exactly with this problem: using 
document.formname to identify forms (please reread his first post).

>> Yes, this sort of "fix" is error prone. But a form's ID is not required
>> in HTML 4 - only XHTML pages should require IDs:
>> <http://www.w3.org/TR/xhtml1/diffs.html>
>
> The id attribute is not required in any version of HTML, including any
> version of XHTML.

ACK. Sorry for the mistake.

>
> The language of W3C documents is sometimes sloppy and may mislead you if
> you read it carelessly and without reading the context. What
> http://www.w3.org/TR/xhtml1/diffs.html#h-4.10
> (as well as the HTML 4.01 spec clause I mentioned earlier) is trying to
> say that you should not use the name attribute of a <form> element to
> refer to the element (which is the only reason for having that attribute
> in the first place) but some other, more logically designed way of
> identifying an element. The id attribute just happens to be the most
> handy tool for the purpose in simple cases.
>
> There are many other ways to identify an element, and you may need to
> use one e.g. when you just cannot modify the HTML source of a document
> for some reason. For example, most pages have just a single form
> element, and then you can simply use
>
> document.getElementsByTagName('form')[0]
>
> This is however not quite as robust as using an id attribute, since some
> day someone might add another <form> element and place it before yours.
> (In balance, someone might also add another element with the same id
> attribute. That would be a reportable markup error, e.g. would be
> flagged by a validator, but how many people actually validate their
> markup after each and every change?)
>

[toc] | [prev] | [next] | [standalone]

#16277

J.R. wrote:

> Em 30-09-2012 05:02, Jukka K. Korpela escreveu:
>> 2012-09-30 5:20, J.R. wrote:
>>> You may use the W3C Markup Validation Service to check if an element
>>> should have an ID.
>> How would you do that? The id attribute is not *required* in any version
>> of HTML.
> 
> That's why I referred to the "W3C Validator", because it can tell if an
> ID attribute is required or not.

As has been said before, an `id' attribute is *never* *declared* #REQUIRED 
on *any* element type of *any* version of HTML or XHTML.  You do not *have* 
*to* specify that attribute for Valid markup per se.

As a result, a markup validator can tell you that a specified `id' attribute 
or attribute value is _not_ Valid on an element because the element type 
does _not_ have that attribute declared or the value _cannot_ be produced by 
the grammar production for the attribute type.  It can tell you that if you 
refer to an ID in the markup (such as with the `for' attribute) that a 
corresponding ID was missing in the document.  And it can tell you that 
there are duplicate IDs, because that makes the document not Valid.

That is *different* from its telling you that you have not put an `id' 
attribute when you should have, these use-cases aside.

More importantly, a *markup* validator parses your script code as CDATA or 
PCDATA.  It is oblivious of the requirements of the Document *Object* Model 
API.  It cannot tell you that you should have used an `id' attribute instead 
of or in addition to a `name' attribute because that was state-of-the-art 
now.  You would need a DOM validator (or a competent person) for that.

> Besides, W3C Validator works with XHTML pages too.

That much is true.  However the W3C Validator cannot tell you how XHTML is 
parsed by a real user agent such as a Web browser.  It is oblivious of the 
different rendering modes as well.
 
>>> Interestingly, Firefox still allows references in the old way
>>> (document.elementID or formName.elementName) when a page is rendered in
>>> "quirks mode".
>>
>> You are confusing support to document.foobar (when accessing a <form>
>> element that has name="foobar") with issues like making id attribute
>> values properties of the document object. The topic is confusing enough
>> without such distractions.
> 
> I think that Denis McMahon was dealing exactly with this problem: using
> document.formname to identify forms (please reread his first post).

Since both document.all.foo and document.foo apply both to elements with 
`id' and `name' "foo", and there is no markup in the OP, your assumption is 
not supported by the OP.  Dennis may have simply chosen the wrong tool for 
the job.

Please trim your quotes to the relevant minimum and get a real name.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#16266

J.R. wrote:

> On 29/09/2012 15:15, Denis McMahon wrote:
>> I'm arguing to replace using document.formname to identify forms with
>> assigning an id to the forms involved and using document.getElementById
>> ("formid").*, but the best arguments I can think of at the moment (more
>> robust to future changes, better compatibility with developing standards,
>> more maintainable) are butting up against "don't fix it until it needs
>> fixing", whereas I prefer to prevent future breakage, rather than react
>> to it.
> 
> document.formname is okay with HTML 4.

No, it is not.  W3C DOM Level 2 HTML makes it clear that HTML 4(.01) 
documents are to be scripted using W3C DOM Level 2 HTML.  In that sense, 
Netscape's document.formname "is HTML 3.2 and before", as it predates HTML 
4.  Of course, you are confusing markup language and DOM API here.

> You may use the W3C Markup Validation Service to check if an element
> should have an ID.

That is beside the point.  All HTML elements can have an ID; `id' is one of 
the general attributes.  The W3C Markup Validation Service does not check 
ECMAScript-based source code for validity or plausibility.
 
>> I'm pretty certain that using document.getElementById("id") is better
>> than using document.elementname, but at the moment I'm having trouble
>> pointing to any sort of authoritative reference for this.
> 
> I recall MSIE used to pollute the global namespace with elements' names
> or IDs, that is, we could get a reference to an element using
> document.elementname or document.elementID. See
> <http://webbugtrack.blogspot.com.br/2007/09/bug-162-global-namespace-
pollution-in.html>
> 
> The W3C standards compliant browsers use document.getElementById("ID")
> which is DOM level 1 (1998).

DOM Level 1 has been obsoleted by DOM Level 2 more than a decade ago.

> Interestingly, Firefox still allows references in the old way
> (document.elementID or formName.elementName) when a page is rendered in
> "quirks mode".

If you had read my posting before replying you would know why.

>> [1] It was document.all.formname which was breaking, a very senior coder
>> (but not actually a web / js coder) "fixed" it by changing
>> document.all.formname to document.formname, but I think the fix is almost
>> as prone to future breakage as the original code was, and would prefer to
>> see document.getElementById("formid") used instead, with approriate IDs
>> allocated to forms.
> 
> Yes, this sort of "fix" is error prone.

So much, so good.

> But a form's ID is not required in HTML 4 - only XHTML pages should
> require IDs:

Utter nonsense.

> <http://www.w3.org/TR/xhtml1/diffs.html>

Nothing there supports your argument.  What is stated there instead is that 
the `id' attribute is of *type* ID in XHTML 1.0, as opposed to HTML 4.01 
where it is of type NAME, because XML requires that there be only one 
attribute with type ID on an element type.  As a result, anchors must adapt.  
But of course XHTML documents may have `name' attributes (of type CDATA) as 
well.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web