[Javascript] Microsoft proprietary DOM vs Standards (Was: IE work-a-round question (re: checkbox

[liorean]

> > From: david at dorward.me.uk
>  > > > DOM 1 reached recommendation status in 1998
> > >
> > > Sorry but I don't recall if it's first recommendation included the
> > > "document.getElemen..."
> > > statement in its apearence.
> > If you don't recall, then why not look?

On 19/04/2008, Troy III Ajnej <trojani2000 at hotmail.com> wrote:
> http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-36113835
>
> I was being educated.
> Because I already did a re-check while writting!
> Please view the:
> http://www.w3.org/TR/DOM-Level-2-Core/core.html
> > > It was DOM Level 2 that invented e different statement for
> > > the same purpose and reached recommendation status only a month
> > > before 2001.
> >
> > Incorrect, see above.
>
>  Correct all the way! It was a re-invetnion of the wheel. It was
> "getElementsByTagName"
> that was proposed in Level 1 not the ID. To be more exact, this link (se
> below), will
> navigate you strait to the paragraph of our matter in discussion,
>
> http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId
>
>  same page as the above. Where it explicitely states: "getElementById
> introduced in DOM Level 2"
> This, -once again - proves that "document.getElementById" is Level 2, and
> was ~introduced~ only a
> month before 2001 respectively.


DOM1Core introduced getElementsByTagName on Document.
DOM1HTML introduced getElementById, getElementsByName on HTMLDocument.
DOM2Core introduced getElementById on Document.

Thus, DOM2Core didn't introduce document.getElementById because in
browsers, document was an HTMLDocument, which means they had the
DOM1HTML interfaces to go by.


>  > > Eventhough FX didn't hesitate to implement it, but did it maliciously.
>
> > Firefox implemented the standard ... maliciously. That makes no sense
> > whatsoever.
>
> The "it" language var cited above meant "reference by ID", I never said "FX
> implemented the standard",
>  why do you alter my words? -So it does make sense!

No it's still total gibberish.

>  > > Same goes with the famous .innerHTML.
> >
> > Firefox implemented innerHTML because lots of websites used it
> > (because Microsoft implemented instead of promoting the standard, and
> > IE was commonly used). I don't see any maliciousness there either. I
> > don't see Firefox's implementation breaking when you edit the inside
> > of tables either.
>
>  O really!
> Why did FX implement the NON-STANDARD innerHTML?

Because live web content wanted to use the feature, and the W3C DOM
had not standardised anything even close to as practical for
programmers.

> Why did FX support the NON-STANDARD reference by ID? While providing error
> mesage:
> "Element rreferenced by Name/ID use standard getElementById() instead".
> I'ts obviously malicious!

Firefox didn't even exist at the time getElementById was standardised.
Meanwhile, using ids as variable names were never standard and is a
problem that has plagued us for a long time.

>  Today this message doesn't turn your Error Console button into red, but it
> used to.
> And what about innerHTML, it doesn't even yeld a soft error nor a warnig
> message!
>  Does it mean that innerHTML has become a standard?!!

A de facto standard, even if not a de jure standard. (Yet!)

Why try to demonise introduction of features that no standard covers?
If there is something you want to be able to do, but there is no
standard for it yet, do you think it's reasonable to submit the idea
to a standards committee, have it draft and get consensus for the
feature, and take it to CR before you try to implement? Heck no! You
make a prototype implementation to build a spec proposal from, then
you submit that spec, and keep yourself open to changing the interface
as the standardisation process goes on.

Introducing a feature is only malicious if:
- It directly competes with a current standard achieving the same thing.
- It breaks significant amounts of live content. (Significant can be
as low as fractions of a per cent here, because the web is so
massive.)
- You don't spec it out publicly, so authors don't know exactly how it works.
- You don't make it behave in the most natural way for most given usages.
- You don't submit it to a standards body but instead force your
competitors to reverse engineer your implementation.
- You continually change the way it's implemented.

> FX never met a W3C standards and never will. It's a pure demagogy and you
> know that.

NOBODY has proven full conformance to ANY web standard. Mozilla has a
considerable adoption of a considerable amount of web standards,
however. Much larger than Microsoft has.

As it stands, Mozilla is fairly standards compliant. Various standards
are supported to various degrees, and there's bugs in the
implementations, sure. To say that it's pure demagogy is patently
false though - there is a public bug database which proves Mozilla has
a considerable effort poured into meeting the W3C standards.

> > > > It lent itself to write-only code, they didn't consult with anyone
> > > > before implementing it, the standards group (including Microsoft)
> > > came
> > > > up with something better.
> > >
> > > :) Like What?
> >
> > document.getElementById
>
>  Let's see...
>
>  > > And what do you understand with "write-only"?
>  > That when someone comes along to read the code, it is not obvious
> > where the variable is being declared (since it is generated by being
> > associated with an HTML document, not from within the script itself).
> > This results in code which is hard to edit.
>
>  Nonsense...
> Complete nonsense.
>  First of, -where do you look before assigning your vars? Or do you
> arbitrarily try to
> assing whatever comes to your mind, hopping that it will call the object you
> are aiming to,
>  by guess or something?

You of course look in all the scripts you have, as well as what
objects are implemented on the Window object of each browser. However,
having the set of properties that are defined on window change because
you use some names or ids on elements within the document, now that
lends to write-only code.

If the script cannot be authored without explicit knowledge of the
document that it's linked or embedded in, then that's bad design of
the system.

Another example of this is the
if-variable-is-not-found-default-to-creating-a-new-global-variable
behaviour of JavaScript.

>  "MyElement" is not a variable, it's the actuall object you are referrening
> to, -and there
> will be no guess nor any place for confussion.That way you can never go
> wrong about.
>  On contrast, what makes the element referrencing a real pain is a
> completely independent
>  naming convention of vars that refer to them.

Elements shouldn't be global variables in the first place. Sure, there
are better designs than the one the DOM uses which could have been
adopted, but having every named element as a global when the script
writer doesn't necessarily know anything about the document is
madness.

>  MyElement.width="value" compared to:
> var anyName =
> document.getElementById("MyElement").width="value"
>  is actually what makes it almost impossible to edit some one else's
> document. You'll have to
> digg in three different places to find out what is the correct id/name of
> the element referred from
> this var; where was it declared; find the original name/id of it; find it in
> HTML; check if
> there is everything right than go through CSS to find that there was some
> banal typing error
> causing your function to fail or to act as not expected.

The script source shouldn't depend on the document, and the other way
around. That's bad separation of concerns. Hardcoding names of
elements is bad software engineering.

>  > > What do you mean with "they didn't consult with anyone"?
> >
> > That they implemented it rather then proposing it to the standards
> > group that they are, and were, a member of.
>
>  I allready pointed out that IE4 was allready out and running for thee long
> coding years before
> they even came up with any proposal.

Wrong. The first DOM proposal reached FPWD only a month after IE4 was
first released - Microsoftian Scott Isaacs was an editor for the early
drafts, later replaced by the current Platform Architect for Internet
Explorer and HTML WG co-chair Chris Wilson. Granted, it took until
1998-07-20 for the getElementsById method to appear, but Microsoft
never proposed document.all or this global variable binding in that
WG, from what I could see.

>  Douring the time you are talking about, W3C was bussy cleaning the mess
> they've created with the
> GIF format and pattents and were intensely preocupied with PNG developement.
> They didn't even turn
>  their eyes on the matters we are talking about.

Are you aware that you're talking about the period when Netscape,
Microsoft and loads of other interests were spewing out more proposals
than they ever have? Most were rejected of course, but this period was
when things really happened in the W3C: HTML/XHTML, CSS and DOM were
actively developed and everybody was involved in everything.

> > > Do you understand that this acusation is a direct answer to the
> > > question: -Who was, and still is hollding up the web???
> >
> > I don't really care what it is in answer to. It is packed full of
> > factual errors.
> >
>  As we can clearly see, the facts are all in the right place.

Yes, but they don't support your argument.

>  > > Don't forget that it was only in December 1997 that HTML 4.0 added
> > > support for tables.
> > > Can you imagine? -Tables!
> >
> > Right. Yes. HTML 4.0. Of course.
> http://www.w3.org/TR/REC-html32#table

Wasn't that his point?

> > The whole situation with HTML at the time was a mess. It didn't help
> > that browser vendors ran around implementing <font>, <blink> and
> > <marquee> instead of trying to develop something good. So HTML 3 was
> > scrapped and HTML 3.2 came along to document what they had some up with.
>
> So, as you see, they were not capable of even dealing with such a
> fundamental need like tables
> at the time, but you expect them to address things like how to manipulate
> the DOM?!

Tables were in HTML 3.2 as well as in the 1995 HTML 3.0 proposals,
which Netscape implemented a good chunk of.

<uri:http://www.w3.org/MarkUp/html3/maths.html>

> > > W3C recommended "document.getElement" a month before 2001, while
> > > IE4-was allready three years old and running.
> >
> > Incorrect, see above.
>
>  Correct all the way, as you can see from above too. -They should have used
> the same policy as they
> did with other coding practices and embrace what was allready a standard in
> the coding "world". If it
> weren't for them taking sides...

Wrong, as I explained above. DOM1HTML and DOM1Core contained the
getElement{sByTagName|ById|sByName} methods in 1998 already.

> For more than three years, coders around the world got used to "MyElement"
> solution with no alternative
> recommendation. Accusing IE for being non-compliant is a pure demagogy.

Actually, Microsoft has a better alternative solution in document.all.
Netscape and DOM1HTML had the purpose specific collections that IE3
copied from Netscape2/3.
Microsoft didn't have to expose elements with names or ids as global
variables for backwards compatibility, there was already a precedent
of using collections on the Document which they and Netscape both
supported, so introducing the global variables for each and every
element with name or id was entirely unnecessary. It just broke
code...

>  One can not write you a ticket for exceeding speed-limit yesterday while
> driving 70mph, simply because
>  today the speed limit for that road is reduced to 60mph by God himself,
> shortly known as W3C & his felow
>  cancelor FX.

True. Microsoft simply made a bad decision and in the process
prevented Netscape from doing corrections to their slightly broken
early designs by demanding that everything they both implemented was
kept as-is.

>  > > So it was, still is, and allways will be, W3C.
>
>  Mean time, while W3C was holding back the web, coders turned to using Flash
> and other plugin alternatives
> filling the vacuume they (W3C) almost puposedly created. In 2001 flash
> couldn't do anything more fancier
>  than IE4.1 filters could do, -today html and scripting has become a simple
> tool for hidding url's of flash
>  content from pages that every day more and more rely on third party
> plugins. There are 30% of pages completely
>  built in flash. Other 40% are hybrids, and all because W3C is still holding
> back the web...

The W3C wasn't holding back the web by any measure. What held back the web was:
1. Netscape scrapping version 5 thereby giving Microsoft years of calm
to marginalise them.
2. Netscape releasing version 6 before it was production quality, thus
throwing the last chance they had at using their
old-but-not-forgotten, well-liked brand by making it an old-and
forgotten-except-by-those-that-dislike-it brand.
3. Microsoft stopping any resemblance of progress in browser space.
4. Total domination of the W3C activities by non-browser-makers.


Browser makers are regaining dominance in W3C activities. The HTML5
WG, WebAPI WG, CSS WG, SVG WG and others have been started or in some
cases finally woken up and begun pushing technologies that have
end-users, live content and browser implementation interoperability as
priorities instead of walled garden enterprise specs such as the WS-*
space, the mobile forum WAP space etc. And that's not the only part of
the web standards world that has been revived. TG1, or TC39, is living
and making progress on ECMAScript 4. (And ECMAScript 3.1/3.x). In IETF
the HTTP people are working too.

And most of all, browsers have actually begun pushing the borders of
web technology forwards again. Because on the web, the ultimate
decision maker for which technology survives and which dies is the
user, and the browser is the gatekeeper.
-- 
David "liorean" Andersson