Tue Mar 26 05:48:59 2002

So anway after a day of looking through the scripts and figuring out what was what i finally figured out how to modify some of our product catagories.

You see its like this:
We had the company that would create our website and maintain it. However the time they would take was awful and they'd miss so many deadlines. Since I was handling the web development I would get yelled at a lot by the boss. Off course I was not happy so i kept screwing the web dev. company in the price. I told them for every week in the delay i would deduct from a percentage from the full ammount. The guy thought i was just putting pressure. To bad because when he finally got the site semi-completed I gave him the check with the ammount i promised i would deduct.
So that created some bad blood especially when I told him that he was a jack ass and did not understand the time line that corporations faced.
We actually need a website for our business, but like upper management, they fail to realise the cost it takes so decided to go for this cheap ass company before I even joined. Also explains why their network was all screwed up because they hired some moron who's idea of fixing a computer was to re-install the OS. :rolleyes:

Anyway, because of the bad blood caused and since the scripting and database was created by this guy any help on changes would mean i'd have to communicate with him. So now everytime we ask him something he'd say he'd do it for us at a price.

I told him to go fuck off. He takes other people's scripts (shopping cart programs) and modifies it for us.

Onward.

So we hired this guy last year that I found out used to work for a HUGE internet cable company plus one day i noticed he was modifying his own personal website in his spare time.
Bingo! Who needs a jack ass to screw me over when this guy can take care of our web site.
yay!!!

So basically any changes and modifications he would do, and the art work i'd take care off since he wasn't very experienced in the stuff.

BUT!

Upper managment decided to modify some catagerories and add new ones. Okay. Not to difficult.

Since I had the entire web site backed up on my server, we could play with the files. Plus the website it self is on our company ISP and not hosted by the other company that orginally created our website.
Originally that was the setup, but as I knew I was going to screw the guy over in the money section, I transfered out website domain to our DSL provider. The guy figured I was going to screw him over so demanded payment from me prior to moving the contents.
Fool! I had the upper hand since he hadn't finished the website in the first place. So no money till web site complete. I told him to move what ever he had currently and that i'd pay him a fraction of what was owed and the balance when the work was completed.

Going back.

Well the product database was done in Access, but the MAIN category ID isn't stored there.
Huh?
yet in the java scripts they were accessing some 'ID_PREFIX'. Eventually i figured out the main categories were stored in another script file which then accessed the mdb (access) database.

Yes I know this is simple, but the fact is:
a) We asked the guy for some info but he claims to have forgotten how he setup the scripts.
b) He asked for money to do something that ultimately was just adding three fucking lines to a script named: HM_ARRAY.js
c) I don't know java the language or the scripting context.
d) we don't even have access at work so i had to use excel and database query

In short, i'm extremely fucking glad that this cock sucker may decide to check out our website and see that we figured out how to do it. Plus the fact that i have been examining the scripts for a day that I've learned how he's designed the website so future changes and mod's will be a lot easier.

Fuck!

Infact I'm going to modify the site now to use java/dhtml to completely render our catagories.

Currently we are using images for our main catagories but scripts for to draw the sub cat.

Huh?

yay for me!

Tue Mar 26 06:04:51 2002

Horray for OW! :)

I'm proud of you for laying the perverbial Poopdown on his candy arse.  Way too go!

Nice work on deciphering the J-script and doing what that phool could not.

:)

Tue Mar 26 06:06:09 2002

INDEED!!!

Tue Mar 26 07:32:42 2002

Infact I'm going to modify the site now to use java/dhtml to completely render our catagories.

Tue Mar 26 12:24:48 2002

Tue Mar 26 20:37:18 2002

Use ASP wi VBS or J.

M.

(Edited by Madan at 12:38 pm on Mar. 26, 2002)

Tue Mar 26 21:36:29 2002

from Madan posted at 12:37 pm on Mar. 26, 2002

JavaScript sucks.

Given that, you know, ECMAScript is the only one widely available.

Use ASP wi VBS or J.

If you're writing ASPs, JScript is far and away the best common language to use; whilst you could use Perl or Python or Tcl (amongst others), JScript is the only decent language that's widely available.

Tue Mar 26 21:41:47 2002

JSCRIPT.

As for Javascript, no, you shouldn't use Javascript on its own, if you can help it. If you like, you can use it in ASP. But that's the point, browsers can be set to turn off client side scripts, in Javascript form and, while not all client-side code is bad, over-specialization or reliance on client side, especially for core-operation apps is dangerous.

Besides that Jscript != Javascript.

You of all fucking people should notice that.

M.

(Edited by Madan at 1:43 pm on Mar. 26, 2002)

(Edited by Madan at 1:44 pm on Mar. 26, 2002)

Tue Mar 26 23:13:33 2002

Tue Mar 26 23:23:16 2002

Until the bosses realized that a large portion of our users were blocking out Javascripts.

Surprise!

:rolleyes:

Besides, as Peter's so emphatically put it, "JScript is ECMAscript compliant and Javascript is not".

And no, Jscript is *not* Javascript.

M.

Wed Mar 27 03:09:33 2002

Thats what I gather so far. I could be wrong, so correct me, nicely. As in don't bitch at my imcompetence because I'm admiting I really have no clue to webservers at all other then some stuff here and there to know what to look at but not enough to do anything significant.

edit: forgot to add. I believe the html is being created in the asp and the asp code it self is passing and getting commands from the .js files.

I'll post some of the code later so maybe you can tell me what it is i am looking at.

I only figured out stuff because the programming syntax reminded of c/c++. i.e.
hm_idmenuprefix = hm_menu;

hm_popdown("elmenu" string'hm_idmenuprefix');
[
function
]

well something like that. So I just looked through the code backwards to see where it was getting the info/data from.

(Edited by OscarWilde at 10:13 am on Mar. 27, 2002)

Wed Mar 27 03:17:48 2002

HM_MenuIDPrefix = "HM_Menu"; //i thought this is where I should look but...
HM_ItemIDPrefix = "HM_Item";
HM_ArrayIDPrefix = "HM_Array";//.. the info ended up in a file named hm_arrays.js so i don't get the connection
// whole bunch of functions i truncated since its only an example

function HM_f_PopDown(menuname){
   if (!HM_AreLoaded || !HM_AreCreated) return;
menuname = menuname.replace("elMenu",HM_MenuIDPrefix);
   var MenuToHide = document.getElementById(menuname);
if(!MenuToHide)return;
   MenuToHide.isOn = false;
   if (!HM_ClickKill) MenuToHide.hideTop();
}
[/code]

Wed Mar 27 03:22:00 2002

[code]
           <tr>
               <td height="30" valign="bottom"><a href="#"       onMouseOver="HM_f_PopUp('elMenu1',event)"
     onMouseOut="HM_f_PopDown('elMenu1')"><img src="../images/icons/mnuaudio.gif" width="125" height="21" border="0"></a></td>
             </tr>
             <tr>
               <td  valign="bottom"><img src="../images/icons/pixel_cccccc.gif" width="125" height="1"></td>
             </tr>
             <tr>
               <td height="30" valign="bottom"><a href="#"       onMouseOver="HM_f_PopUp('elMenu2',event)"
     onMouseOut="HM_f_PopDown('elMenu2')"><img src="../images/icons/mnucd.gif" width="125" height="21" border="0"></a></td>
             </tr>
             <tr>
               <td valign="bottom"><img src="../images/icons/pixel_cccccc.gif" width="125" height="1"></td>
             </tr>
             <tr>
[/code]

Again I didn't include every line.

Wed Mar 27 13:12:18 2002

from Madan posted at 9:41 pm on Mar. 26, 2002

Not Java, you moron.

JSCRIPT.

As for Javascript, no, you shouldn't use Javascript on its own, if you can help it. If you like, you can use it in ASP. But that's the point, browsers can be set to turn off client side scripts, in Javascript form and, while not all client-side code is bad, over-specialization or reliance on client side, especially for core-operation apps is dangerous.

Besides that Jscript != Javascript.

You of all fucking people should notice that.

Wed Mar 27 17:20:04 2002

Then why not *write* JScript.  If you just write "J" who knows what you mean?  Do you mean the language J (APL but using ASCII)?  Do you mean Java?  Do you mean JavaScript?  Do you mean JScript?  It's impossible to tell.

You're not stupid. Neither is anyone else on this board. ASP uses scripting. Exactly why would I be talking about a compiled language in ASP?

Quote: As for Javascript, no, you shouldn't use Javascript on its own, if you can help it. If you like, you can use it in ASP. But that's the point, browsers can be set to turn off client side scripts, in Javascript form and, while not all client-side code is bad, over-specialization or reliance on client side, especially for core-operation apps is dangerous.
No, it simply requires that you say "this site requires scripting to be enabled".

Newsflash. Many people are logged in from systems that don't have it enabled and that don't have permission for such systems. Others are mistrustful. Yet others simply don't have browsers that handle it properly. While client side scripting can be useful for some things, mission critical ordering mechanisms are not one of those "things".

Quote: You of all fucking people should notice that.
So, Madan, tell me, what are the significant differences you've found between the two languages?

Appart from the "ava"?

How about the object models they support?
How about cross-appearance compatibility on various browsers, *still*?
Or HTML transferrence?

The syntax is very similar. Everything else, isn't.

m.

Wed Mar 27 22:29:56 2002

You're not stupid.

Neither is anyone else on this board. ASP uses scripting. Exactly why would I be talking about a compiled language in ASP?

Newsflash. Many people are logged in from systems that don't have it enabled and that don't have permission for such systems.

People without scripting are very much in the minority.

Others are mistrustful. Yet others simply don't have browsers that handle it properly. While client side scripting can be useful for some things, mission critical ordering mechanisms are not one of those "things".

Appart from the "ava"?
How about the object models they support?

How about cross-appearance compatibility on various browsers, *still*?

Or HTML transferrence?

If you're referring to Netscape 4.x's non-support of DOM level 1, you should know that that has nothing to do with J[ava]Script.  Nowhere did I mention DHTML or the DOM or anything like that.  I'm asking what significant differences you've found between JScript and JavaScript for the purpose of client-side scripting.  I'm not asking about the differences in the object models of various browsers -- that's completely different.

The syntax is very similar. Everything else, isn't.

Wed Mar 27 23:27:45 2002

And you haven't had all your fucking fingers cut off, but you still can't type complete words properly.

Kiss my ass. And learn how to read. I thought you limey stuckups were always big on R.I.F.

Quote: Neither is anyone else on this board. ASP uses scripting. Exactly why would I be talking about a compiled language in ASP?

Fuck alone knows.  Why not try writing what you mean instead of some fucked up code?

??? If you even knew how to express opinions without coming accross as a muddled ass, I might be able to answer this.

Quote: Newsflash. Many people are logged in from systems that don't have it enabled and that don't have permission for such systems.

Newsflash: No they're not.

No? So I guess KR, for example, you know the company I work for that has tens of thousands of employees. Many of their divisions WERE able to order and the Javascript was enabled and they WERE able to get it altered.

NO? Of course not, fucktard.

People without scripting are very much in the minority.

I never said most dickhead, I said a lot. A lot != most. Pull your head out of your ass and give the shit on your eyes time to dry off. Maybe then you can see what I'm typing.

Quote: Others are mistrustful. Yet others simply don't have browsers that handle it properly. While client side scripting can be useful for some things, mission critical ordering mechanisms are not one of those "things".

If it can be done client-side, do it client-side.  It makes for a better user experience (no slow round-trips to the server).  It makes more effective use of server resources.  It's win-win.

*added* if you're on crack... */added*

Quote: Appart from the "ava"?
How about the object models they support?

Nothing to do with the language.  They both support the same set of ECMAScript objects -- anything else isn't within the gamut of the language.

I never specified only the language. How a language is used/interpreted or it's effects on platforms are IMPORTANT. Talk about "putting words in one's mouth."

Quote: How about cross-appearance compatibility on various browsers, *still*?

How about you name me some real-life differences instead of hoping to make me back down with this vague bullshit.

!!!! I can't believe you're going to go there.

Netscape 6x and IE 6x will both show Jscript? No?
Netscape 6x and IE 6x will use/show Javascript the same? No?

Then fuck off.  Of course, even *if* we weren't talking about newer browsers, can you *IMAGINE* the problems wi straight vanilla Javascript on Netscape 3 browsers, which many people(as much as 5% of all HStore attendees) still use.

Oh wait, I forgot you're one of those assclown developers that says "fuck the minority". I'd rather be inclusive. That's what a webmaster worth his/her salt would do.

Quote: Or HTML transferrence?

What in the name of fuck does that mean?

If you're referring to Netscape 4.x's non-support of DOM level 1, you should know that that has nothing to do with J[ava]Script.  Nowhere did I mention DHTML or the DOM or anything like that.  I'm asking what significant differences you've found between JScript and JavaScript for the purpose of client-side scripting.  I'm not asking about the differences in the object models of various browsers -- that's completely different.

That's precisely what I fucking mean. Both Javascript and Jscript now support DOM ....*now*. Emphasis on now.

As for object model differences. That affects the development of the language and, ultimately, its effectiveness. If you want to debate scholarly, insulated "code only" bullshit, wiout taking the environement into account, be my guest but I have better things to do than agree with you that "syntax is the only importance in code evaluation".

M.

(Edited by Madan at 3:30 pm on Mar. 27, 2002)

Thu Mar 28 02:14:01 2002

I never said most dickhead, I said a lot. A lot != most. Pull your head out of your ass and give the shit on your eyes time to dry off. Maybe then you can see what I'm typing.

!!!! I can't believe you're going to go there.

Netscape 6x and IE 6x will both show Jscript? No?
Netscape 6x and IE 6x will use/show Javascript the same? No?

YES, they will both run the same scripts.

YES, the language is identical between the two browsers.

Then fuck off.  Of course, even *if* we weren't talking about newer browsers, can you *IMAGINE* the problems wi straight vanilla Javascript on Netscape 3 browsers, which many people(as much as 5% of all HStore attendees) still use.

Granted, the language specification has changed since Netscape 3, and if you're going to support Netscape 3 you will have to code to IIRC JavaScript 1.1 or something equally low-numbered.  But between NS 6 and IE 6?  No problems.

Oh wait, I forgot you're one of those assclown developers that says "fuck the minority". I'd rather be inclusive. That's what a webmaster worth his/her salt would do.

That's precisely what I fucking mean. Both Javascript and Jscript now support DOM ....*now*. Emphasis on now.

The existance and manipulatability of a DOM level 1 object model is independent of the language being used to script a document.

As for object model differences. That affects the development of the language and, ultimately, its effectiveness.

Neither of those languages has anything to do with the object model.

If you want to debate scholarly, insulated "code only" bullshit, wiout taking the environement into account, be my guest but I have better things to do than agree with you that "syntax is the only importance in code evaluation".

If you're going to criticize things, at least make sure to criticize the right fucking things.  If you don't it makes it impossible to tell what the fuck you're talking about.

I'm still left unclear about what your actual complaint is.  That pre-version 5 browsers don't support the DOM?  Is that what you're trying to say?

Thu Mar 28 22:32:02 2002

It's not even "a lot".  A few per cent.

I'm not going to sit here and argue this crap with you.

Even 5% would be too much and we both know it's much more.

Quote: !!!! I can't believe you're going to go there.

Netscape 6x and IE 6x will both show Jscript? No?
Netscape 6x and IE 6x will use/show Javascript the same? No?  

What the fuck are you talking about?

YES, they will both run the same scripts.

YES, the language is identical between the two browsers.

No, no they won't run the same scripts exactly. Not only do older browsers have trouble with new/old Javascript(a point which you *had* to address, dependent on the version syntax) but Netscape 6x does not interpret Javascript in the exact same means as IE 6. You believe that if you want. That would explain a lot.

Quote: Oh wait, I forgot you're one of those assclown developers that says "fuck the minority". I'd rather be inclusive. That's what a webmaster worth his/her salt would do.  

I'm all for being inclusive, except where being inclusive excludes others.  Supporting NS 3 and 4 falls into such a category.  Because those browsers have no or buggy support for CSS, which is necessary for easily-accessible pages, I won't support them.

Bullshit. CSS 1/2 isn't necessary for anything. If that's what you think, I feel sorry for people that browse your sites.

Then again, this is coming from the person that told me that "locking font size was not fair" but did so on his own page... Kudos. :rolleyes:

CSS makes the job easier because you can block specifications in the body, head or a css page but it doesn't make it any more compatible. It makes it less compatible, which is why I still won't use it. If assholes like MS and AOL could get their act together to make sure that CSS read *the same* on both new browsers AND that I was sure people didn't use >=4 browsers for both platforms, then I'd use it.  

It's more important to me to make the page accessible to someone with a screen-reader -- who can't help their disability -- than someone who for some fucked up reason wants to use Netscape 4.x or below -- who can cure their particular disability.

? What? Make some fucking sense. Not only aren't they mutually exclusive but the argument isn't even sensical.

Quote: That's precisely what I fucking mean. Both Javascript and Jscript now support DOM ....*now*. Emphasis on now.  

No, they don't.  JavaScript and JScript have *NOTHING* to do with the DOM.  Neither of their specifications mentions it.  Nor does ECMAScript.  The DOM specification is language-independent.  They are separate issues.

Last time I checked. DOM should affect the execution of Javascript. Especially when discussing the differences between IE and Netscape. Perhaps I was mistaken or maybe you're just off in another dimension but DOM is basically the execution of DHTML, which is scripts + HTML operations.

Gee, that *sounds* like it includes Javascript/Jscript.
Maybe you should go back to DOM's home at W3C and read up?

One more question. Do you honestly think that Netscape 6x and IE 6x have equal support(same support) for DOM?

Answer, no.

The existance and manipulatability of a DOM level 1 object model is independent of the language being used to script a document.

"The Core DOM APIs are designed to be compatible with a wide range of languages, including both general-user scripting languages and the more challenging languages used mostly by professional programmers. "

But how exactly does that deal with the problem of DOM interpretation by the browsers?

Quote: As for object model differences. That affects the development of the language and, ultimately, its effectiveness.

Didn't even touch this...

M.

Fri Mar 29 04:42:45 2002

No, no they won't run the same scripts exactly. Not only do older browsers have trouble with new/old Javascript(a point which you *had* to address, dependent on the version syntax) but Netscape 6x does not interpret Javascript in the exact same means as IE 6. You believe that if you want. That would explain a lot.

Bullshit. CSS 1/2 isn't necessary for anything. If that's what you think, I feel sorry for people that browse your sites.

How do you add aural cues to a page *without* CSS?

etc..

CSS makes the job easier because you can block specifications in the body, head or a css page but it doesn't make it any more compatible.

It makes it less compatible, which is why I still won't use it. If assholes like MS and AOL could get their act together to make sure that CSS read *the same* on both new browsers AND that I was sure people didn't use >=4 browsers for both platforms, then I'd use it.

? What? Make some fucking sense. Not only aren't they mutually exclusive but the argument isn't even sensical.

Last time I checked. DOM should affect the execution of Javascript.

Especially when discussing the differences between IE and Netscape. Perhaps I was mistaken or maybe you're just off in another dimension but DOM is basically the execution of DHTML, which is scripts + HTML operations.

Gee, that *sounds* like it includes Javascript/Jscript.
Maybe you should go back to DOM's home at W3C and read up?

One more question. Do you honestly think that Netscape 6x and IE 6x have equal support(same support) for DOM?
Answer, no.

"The Core DOM APIs are designed to be compatible with a wide range of languages, including both general-user scripting languages and the more challenging languages used mostly by professional programmers. "
But how exactly does that deal with the problem of DOM interpretation by the browsers?

Didn't even touch this...

Which isn't all that fucking surprising; the first revision of ECMAScript was released in June 1997; the DOM level 1 recommendation wasn't released until October 1998.  ECMAScript has received I think two subsequent revisions, one released in August 1998, the last in December 1999; only this third edition could have had its design influenced by the DOM -- but it didn't.

Sat Mar 30 23:49:09 2002

I mean a plain ol' JavaScript that will work in IE 6 but not Netscape 6.x

Did I say not work? No. I said work *differently*. Please *read* my posts. When I get on my work T-connection(Monday), I'll post some examples but I can't on 17 baud.

Quote: Bullshit. CSS 1/2 isn't necessary for anything. If that's what you think, I feel sorry for people that browse your sites.
How do you add style information to an HTML 4.01 Strict or XHTML 1.0 Strict page *without* CSS?

How do you add aural cues to a page *without* CSS?

I'm not using XHTML. You can use deprecated code(which works exactly the same if you know what you're doing) in 4.0(yes, I KNOW it's not 4.01) and it will still work/validate.

Quote: CSS makes the job easier because you can block specifications in the body, head or a css page but it doesn't make it any more compatible.
How wrong you are.  CSS has an important feature called cascading, which specifies, amongst other things, how different stylesheets from different sources override each other.

I wasn't talking about compatibility within the site, with format. Get a fucking clue. If you're suggesting that CSS1 looks and functions the same on Netscape 4, IE 5, IE 6 and Netscape 6.01 along with Mozilla or Mosaic or any of the hundrends of other browser/versions out there, then you've been smoking crack my friend. Moreso, I challenge you to create a page that works *perfectly* the same(*looks* the *same* on all browsers, using your preciously broken-for-now CSS1).

While I'm aware that W3C is trying to push their XHTML in DOM, I don't think actual application between various platforms/versions is at a reasonable place yet.

A great example was Sony's web site, which was using CSS1/XHTML and Javascript and which was *broken* until *yours truly* emailed their webmaster and told them that it doesn't work properly on a Mac IE 5 browser.

It has an allowance for, amongst other things, user stylesheets that override certain aspects of the document's stylesheet.  This means, for instance, that a user can override font sizes, or colours, or whatever else they need to make the page more accessible.

That's not what I'm talking about at all. And plain old HTML did that already. The main advantages I see in XHTML and CSS1 is *not* the above but, instead, the ability to apply an ASP-like include-paradigm in controlling the page, allowing for more speed and greater amounts of detail functionality. You can have multiple CSS1 definitions on a seperate page that can be changed and *bam!*: instant modifcation on 4500 pages. More than that, XHTML has been pushed by W3C as a "silver bullet" of  portables-compliant code for the future.

So a person can resize or recolor code with CSS1. Big fucking deal. They can do that with HTML too. What I find truly funny is that most people use CSS1 to *stop* customization of a page, not to help it along.  You know, like yours...or Risos... :rolleyes:

Quote: It makes it less compatible, which is why I still won't use it. If assholes like MS and AOL could get their act together to make sure that CSS read *the same* on both new browsers AND that I was sure people didn't use >=4 browsers for both platforms, then I'd use it.
Both Mozilla/Netscape 6.x and IE 6.x are at 95+% compatibility with CSS -- which is sufficient to make it perfectly useful.

You're not a web dev. That explains a lot.

Quote: ? What? Make some fucking sense. Not only aren't they mutually exclusive but the argument isn't even sensical.
Yes, they are, and yes, it is.

No they aren't. No it isn't.

Quote: Last time I checked. DOM should affect the execution of Javascript.
Then you'd better check again.

Gee, I did. Go to http://www.w3.org/DOM/

Quote: Especially when discussing the differences between IE and Netscape. Perhaps I was mistaken or maybe you're just off in another dimension but DOM is basically the execution of DHTML, which is scripts + HTML operations.
No, it isn't.  The DOM specifies the object model of a page.  The different kinds of object, the hierarchy they form, the methods and properties that each object make available.

I'm wrong? W3C doesn't think so. This is how they phrase it:

"What is the Document Object Model?

The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.

Why the Document Object Model?

"Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated. The W3C has received several submissions from members companies on the way in which the object model of HTML documents should be exposed to scripts. These submissions do not propose any new HTML tags or style sheet technology. The W3C DOM WG is working hard to make sure interoperable and scripting-language neutral solutions are agreed upon. "

Hmmm. But I suppose you know more than the implementers of the standard we're debating.

Quote: Gee, that *sounds* like it includes Javascript/Jscript.
Maybe you should go back to DOM's home at W3C and read up?
I'm not the one who needs to.  I'm not the one confusing scripting languages with an object model.

I'm not confusing anything. One depends on the other. And since a language depends on the object model, you better bet your ass it's important.

Quote: One more question. Do you honestly think that Netscape 6x and IE 6x have equal support(same support) for DOM?
Answer, no.
I'm sure there are differences, but they are few and far between.  I certainly can't name any off the top of my head.

Sorry, I don't like *waffles*. Maybe some french toast?

Quote: "The Core DOM APIs are designed to be compatible with a wide range of languages, including both general-user scripting languages and the more challenging languages used mostly by professional programmers. "
But how exactly does that deal with the problem of DOM interpretation by the browsers?
It doesn't, because that's not the issue.  The issue is the scripting languages, not the DOM."

No, because DOM *affects* the languages in their interpretation. If W3C wants a certain object model established and it alters the functionality between browsers(which you yourself admitted is probably likely), then it stands to reason that the usefulness/language itself are changed.

Which isn't all that fucking surprising; the first revision of ECMAScript was released in June 1997; the DOM level 1 recommendation wasn't released until October 1998.  ECMAScript has received I think two subsequent revisions, one released in August 1998, the last in December 1999; only this third edition could have had its design influenced by the DOM -- but it didn't.

I never said ECMAscript was dependent on DOM. Please quote me on that.

However, Javascript is now ECMA compliant. You and I both agree on this. What we don't agree on is the subsequent release of DOM and it's affects on said language...and others.

M.

(Edited by Madan at 3:55 pm on Mar. 30, 2002)

Sun Mar 31 01:41:06 2002

Did I say not work? No. I said work *differently*. Please *read* my posts.

I'm not using XHTML. You can use deprecated code(which works exactly the same if you know what you're doing) in 4.0(yes, I KNOW it's not 4.01) and it will still work/validate.

I wasn't talking about compatibility within the site, with format. Get a fucking clue.

If you're suggesting that CSS1 looks and functions the same on Netscape 4, IE 5, IE 6 and Netscape 6.01 along with Mozilla or Mosaic or any of the hundrends of other browser/versions out there, then you've been smoking crack my friend.

Moreso, I challenge you to create a page that works *perfectly* the same(*looks* the *same* on all browsers, using your preciously broken-for-now CSS1).

While I'm aware that W3C is trying to push their XHTML in DOM,

I don't think actual application between various platforms/versions is at a reasonable place yet.

A great example was Sony's web site, which was using CSS1/XHTML and Javascript and which was *broken* until *yours truly* emailed their webmaster and told them that it doesn't work properly on a Mac IE 5 browser.

That's not what I'm talking about at all. And plain old HTML did that already.

The main advantages I see in XHTML and CSS1 is *not* the above but, instead, the ability to apply an ASP-like include-paradigm in controlling the page, allowing for more speed and greater amounts of detail functionality. You can have multiple CSS1 definitions on a seperate page that can be changed and *bam!*: instant modifcation on 4500 pages. More than that, XHTML has been pushed by W3C as a "silver bullet" of  portables-compliant code for the future.

So a person can resize or recolor code with CSS1. Big fucking deal. They can do that with HTML too. What I find truly funny is that most people use CSS1 to *stop* customization of a page, not to help it along.  You know, like yours...or Risos... :rolleyes:

In any case, my site is perfectly customizable.

You're not a web dev. That explains a lot.

No they aren't. No it isn't.

Gee, I did. Go to http://www.w3.org/DOM/

Yup, you've guessed it -- the DOM doesn't affect how ECMAScripts execute.

I'm wrong?

W3C doesn't think so.

This is how they phrase it:
The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.

"Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated.

The W3C has received several submissions from members companies on the way in which the object model of HTML documents should be exposed to scripts. These submissions do not propose any new HTML tags or style sheet technology. The W3C DOM WG is working hard to make sure interoperable and scripting-language neutral solutions are agreed upon. "

Hmmm. But I suppose you know more than the implementers of the standard we're debating.

I'm not confusing anything. One depends on the other.

JavaScript does not depend on the DOM.  It predates it (maybe 1.4 post-dates it, but the language had the bulk of its functionality before anyone had even thought about the DOM).
JScript does not depend on the DOM.  Most versions predate it, and its spec doesn't mention it or require it.
ECMAScript does not depend on the DOM.  It predates it, and its spec neither mentions nor requires it.

The DOM does not depend on JavaScript.  It explicitly states that it's language neutral.
The DOM does not depend on JScript.  It explicitly states that it's language neutral.
The DOM does not depend on ECMAScript.  It explicitly states that it's language neutral.

And since a language depends on the object model, you better bet your ass it's important.

No, because DOM *affects* the languages in their interpretation.

If W3C wants a certain object model established and it alters the functionality between browsers(which you yourself admitted is probably likely), then it stands to reason that the usefulness/language itself are changed.

I never said ECMAscript was dependent on DOM. Please quote me on that.

However, Javascript is now ECMA compliant. You and I both agree on this. What we don't agree on is the subsequent release of DOM and it's affects on said language...and others.

You really need to distinguish between the language itself -- the things in its specification -- and object models/APIs that have bindings for that language.

Sun Mar 31 17:56:56 2002

Quote: Did I say not work? No. I said work *differently*. Please *read* my posts.
If a script doesn't work the same way, it doesn't work.  The script is meant to do one thing, after all, not two.  If it does two -- one thing for one browser, one for the other -- it doesn't work.

You're wrong. How the script relates to the browser is not all or nothing. As a developer, you should know that.

Quote: I'm not using XHTML. You can use deprecated code(which works exactly the same if you know what you're doing) in 4.0(yes, I KNOW it's not 4.01) and it will still work/validate.

And it will look crap in text browsers and screenreaders.  And the transitional stuff still doesn't answer the other question.

:rolleyes: I can make pages look great on text readers using deprecated text. Besides, with 4.0 deprecation at least the pages *can* be seen on some Netscape and Mac browsers. Unlike your fetish for XHTML which leads viewers to exit such pages in frustration...

Quote: I wasn't talking about compatibility within the site, with format. Get a fucking clue.
Speak english.

Sorry, I speak American. But hey, they're are advantages. We don't call our food "bangers and mash". :)

Quote: If you're suggesting that CSS1 looks and functions the same on Netscape 4, IE 5, IE 6 and Netscape 6.01 along with Mozilla or Mosaic or any of the hundrends of other browser/versions out there, then you've been smoking crack my friend.
I didn't say anything of the sort.

Good, then XHTML/CSS1/4.01 isn't  a solution...yet.

Quote: Moreso, I challenge you to create a page that works *perfectly* the same(*looks* the *same* on all browsers, using your preciously broken-for-now CSS1).
The aim is not to make pages that look the same.  The aim is to make pages that degrade gracefully and are widely accessible.

Wrong. When you sell something, consistency is key. If your page doesn't function properly because the CSS has caused the text to swell, breaking table brackets and making navigation impossible, you've lost customers.

Quote: While I'm aware that W3C is trying to push their XHTML in DOM,
That makes no sense.

www.w3c.org/DOM/

The object model used for scripting is tied also to its representation as XHTML/HTML. DHTML, if you will.  

Quote: I don't think actual application between various platforms/versions is at a reasonable place yet.
It certainly is.  Browsers with reasonable support exist on all platforms.  If people don't want to use them, that's their problem.

I think our definition of reasonable is variant because for me, reasonable is *all* inclusive, not just those on platforms that I prefer.

Quote: A great example was Sony's web site, which was using CSS1/XHTML and Javascript and which was *broken* until *yours truly* emailed their webmaster and told them that it doesn't work properly on a Mac IE 5 browser.
And...?

Just listing a true story(he never emailed me a "thank you" btw) that shows that you're previous take on "degrading well" doesn't mean squat because it ain't true. I also emailed the web team on KFC. Never heard from them either but they fixed their site too.

Quote: That's not what I'm talking about at all. And plain old HTML did that already.
Please show me the cascade rules for plain old HTML.  Please tell me how, using plain old HTML, I'm meant to denote that the headers of a table are meant to be read each time a row is read.

That's not what I said. But thank you for putting words in my mouth. I said text could be manipulated using old plain, deprecated HTML. And as for your question, perhaps rephrasing it could let me get you an answer, since table headers display just fine on HTML, the last time I checked.

Quote: The main advantages I see in XHTML and CSS1 is *not* the above but, instead, the ability to apply an ASP-like include-paradigm in controlling the page, allowing for more speed and greater amounts of detail functionality. You can have multiple CSS1 definitions on a seperate page that can be changed and *bam!*: instant modifcation on 4500 pages. More than that, XHTML has been pushed by W3C as a "silver bullet" of  portables-compliant code for the future.
That is certainly an advantage -- a big one -- but it is not the only one.

"the *main* advantages I see with XHTML..."

Quote: So a person can resize or recolor code with CSS1. Big fucking deal. They can do that with HTML too. What I find truly funny is that most people use CSS1 to *stop* customization of a page, not to help it along.  You know, like yours...or Risos...  
The primary reason sites do this is because Netscape 4.x can and does crash (amongst other things) when used with percentage sizes in CSS.  Just another reason to not support it.

In any case, my site is perfectly customizable.

Uh, no it's not. In fact, we can go back to the post on CSS and we can gloss over me asking you how you locked your font size on PC. Customizable? No.

Is your site ineffective? No. And your chick galleries are fly but what I AM saying is that you're talking about customization and you can't customize your site.

Quote: You're not a web dev. That explains a lot.
I do some web development.  But the days of "Best viewed in any browser" are behind us.  Today, our policy is "best viewed in a browser that attempts to conform to open standards".

No, today's policy is "best viewed to EVERYONE".

Quote: No they aren't. No it isn't.
Please show me how to write a page that:
makes extensive use of presentational elements

Define "Presentational elements"...

renders acceptably well in Netscape 4 (without stupidities like requiring a completely different version of the site)
renders acceptably well in text-only browsers
works well with screen readers

Can be done with plain HTML. Name me a screen reader you have.

Quote: Gee, I did. Go to http://www.w3.org/DOM/
And what did you find?

Yup, you've guessed it -- the DOM doesn't affect how ECMAScripts execute.

DOM in BROWSERS is interpreted differently which affects how ECMAScripts execute.
That's btw, what is on the W3C site if you want to look at it again.

Quote: This is how they phrase it:
The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.
Note how the DOM isn't specific to HTML -- unlike DHTML -- and isn't specific to ECMAScript/JavaScript/JScript -- unlike DHTML.  The DOM doesn't have any control over the execution of scripts, or the presentation of the elements within it, or anything like that.  DHTML does.

Quote: "Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated.
Notice here how the DOM is independent of the language, is independent of the style sheet language, and is independent of HTML.

Independent is something I never contested. Affected by and subject to does not mitigate its independence. It's indicating how DHTML is operated. Gee, that takes scripts into account. That means that ECMAScripts *will* be subject to DOM-browsers and since it's not consistent within browsers yet, ECMAScripts(despite the fact that they aren't related to DOM directly) will be affected.

Notice also how much DHTML doesn't use the DOM (anything that uses document.layers or document.all, for instance, is not using the DOM).  The DOM is not "basically the execution of DHTML".

You give me two examples of proprietary Netscape DOM as evidence? What?

JavaScript does not depend on the DOM.  It predates it (maybe 1.4 post-dates it, but the language had the bulk of its functionality before anyone had even thought about the DOM).
JScript does not depend on the DOM.  Most versions predate it, and its spec doesn't mention it or require it.
ECMAScript does not depend on the DOM.  It predates it, and its spec neither mentions nor requires it.

A browser using DOM inconsistently when compared to another browser *will* affect scripting between Javascript and Jscript. Which came first doesn't matter as long as the technology has been begun to be incorporated into N6x and IE6+. Your entire argument is that ECMAScript "predates DOM" and therefore DOM won't have any effect on them as an object model, despite the fact that browsers are adopting it disparately which we both have admitted and despite the fact that DOM deals with the execution of scripting, ECMA or otherwise.

The DOM does not depend on JavaScript.  It explicitly states that it's language neutral.
The DOM does not depend on JScript.  It explicitly states that it's language neutral.
The DOM does not depend on ECMAScript.  It explicitly states that it's language neutral.

I never said DOM depended on the script, I said the script depends on the DOM and repeating it three times with a slight alteration each time doesn't make your point any more effective. The salient point is that while DOM itself is neutral, it's interpretation by browsers and platforms that *aren't* will ultimately affect scripting on said platforms, just like HTML is != on various browsers, despite W3C pushing it's "compatibile and compliant standards".

Quote: If W3C wants a certain object model established and it alters the functionality between browsers(which you yourself admitted is probably likely), then it stands to reason that the usefulness/language itself are changed.
No, it doesn't "stand to reason".  If an object (i.e. the document object) external to the language changes, that doesn't change the language at all.  The two things are quite distinct.  Objects that a language may use are not the language itself.

And if you remove all objects how good is the language?

Quote: I never said ECMAscript was dependent on DOM. Please quote me on that.
You said that the languages "support" the DOM.  They do not.  The languages do not mention the DOM at all.

"The DOM defines the way in which HTML document objects are exposed to your script.  "

That's directly from Javascript 1.5 on netscape's developer page:

http://developer.netscape.com/docs/manuals/js/core/jsguide15/intro.html

M.

Sun Mar 31 21:31:07 2002

You're wrong. How the script relates to the browser is not all or nothing. As a developer, you should know that.

:rolleyes: I can make pages look great on text readers using deprecated text.

Besides, with 4.0 deprecation at least the pages *can* be seen on some Netscape and Mac browsers. Unlike your fetish for XHTML which leads viewers to exit such pages in frustration...

Good, then XHTML/CSS1/4.01 isn't  a solution...yet.

Wrong.

www.w3c.org/DOM/
The object model used for scripting is tied also to its representation as XHTML/HTML. DHTML, if you will.  

The scripting object model has *NOTHING* to do with the DOM.  NOTHING.  This is why you can use JScript/JavaScript in situations that are NOT INSIDE WEB PAGES.  The languages stand alone without the DOM.

Furthermore, the DOM applies to more than just HTML/XHTML.  You can generate an XML -- but not XHTML or HTML -- page using the DOM.

I think our definition of reasonable is variant because for me, reasonable is *all* inclusive, not just those on platforms that I prefer.

Just listing a true story(he never emailed me a "thank you" btw) that shows that you're previous take on "degrading well" doesn't mean squat because it ain't true. I also emailed the web team on KFC. Never heard from them either but they fixed their site too.

That's not what I said. But thank you for putting words in my mouth. I said text could be manipulated using old plain, deprecated HTML.

And as for your question, perhaps rephrasing it could let me get you an answer, since table headers display just fine on HTML, the last time I checked.

Uh, no it's not. In fact, we can go back to the post on CSS and we can gloss over me asking you how you locked your font size on PC. Customizable? No.

Is your site ineffective? No. And your chick galleries are fly but what I AM saying is that you're talking about customization and you can't customize your site.

HOWEVER, it also relies on people writing the page in a particular way.  It relies on people using the header tags to denote levels in a document's hierarchy, for instance. If they use them just to impose certain styling elements -- or alternatively, if they use just font tags (or even CSS classes) to make their headings bigger -- then I can't override them in any meaningful way.  This overridability is incredibly powerful, but it is useless if people don't use HTML for structure properly.

No, today's policy is "best viewed to EVERYONE".

Define "Presentational elements"...

Can be done with plain HTML. Name me a screen reader you have.

There are many screen readers (try google; I don't know any Mac products).  What's perhaps just as useful is things like this:
http://www.temple.edu/inst_disabilities/piat/wave/
Which tell you the order in which a page gets read, as well as highlighting many other issues.
http://www.delorie.com/web/purify.html is also good, mostly as a fake limited-capabilities browser, as well as DoctorHTML as a way of listing unsupported tags and such (though unfortunately it doesn't have IE 6 or XHTML support) http://www.doctor-html.com/RxHTML/cgi-bin/single.cgi .

And, of course, there's Bobby.  http://www.cast.org/bobby/

DOM in BROWSERS is interpreted differently which affects how ECMAScripts execute.
That's btw, what is on the W3C site if you want to look at it again.

Independent is something I never contested. Affected by and subject to does not mitigate its independence.

If, for instance, I have a JScript like this:
WScript.Echo("Hello World!");
I'm not affected *at all* by the fact that WSH doesn't provide DOM bindings.  The DOM bindings have no impact on the language itself.

It's indicating how DHTML is operated.

Gee, that takes scripts into account. That means that ECMAScripts *will* be subject to DOM-browsers

and since it's not consistent within browsers yet, ECMAScripts(despite the fact that they aren't related to DOM directly) will be affected.

You give me two examples of proprietary Netscape DOM as evidence? What?

A browser using DOM inconsistently

when compared to another browser *will* affect scripting between Javascript and Jscript.

Which came first doesn't matter as long as the technology has been begun to be incorporated into N6x and IE6+. Your entire argument is that ECMAScript "predates DOM" and therefore DOM won't have any effect on them as an object model,

despite the fact that browsers are adopting it disparately which we both have admitted and despite the fact that DOM deals with the execution of scripting, ECMA or otherwise.

I never said DOM depended on the script, I said the script depends on the DOM and repeating it three times with a slight alteration each time doesn't make your point any more effective. The salient point is that while DOM itself is neutral, it's interpretation by browsers and platforms that *aren't* will ultimately affect scripting on said platforms, just like HTML is != on various browsers, despite W3C pushing it's "compatibile and compliant standards".

And if you remove all objects how good is the language?

"The DOM defines the way in which HTML document objects are exposed to your script.  "
That's directly from Javascript 1.5 on netscape's developer page:

Sun Mar 31 23:01:51 2002

So a person can resize or recolor code with CSS1. Big fucking deal. They can do that with HTML too. What I find truly funny is that most people use CSS1 to *stop* customization of a page, not to help it along.  You know, like yours...or Risos...  

:rolleyes:

Sorry for making my page appear as I want.

Sun Mar 31 23:27:55 2002

Quote: You're wrong. How the script relates to the browser is not all or nothing. As a developer, you should know that.
I don't know about you, but when I wrote a program or a script, I expect it to do only one thing.  If its behaviour varied amongst different browsers, it would not be doing what I wanted it to do.  Hence, it would not be working.

Semantics. So now you're saying it *is* possible for code operations to deviate depending on the set of circumstances/browsers/platform...

Quote:  I can make pages look great on text readers using deprecated text.
No you can't.

Yes, I can.

Quote: Besides, with 4.0 deprecation at least the pages *can* be seen on some Netscape and Mac browsers. Unlike your fetish for XHTML which leads viewers to exit such pages in frustration...
Because I don't care about Netscape 4.x users.  There is no excuse for using Netscape 4.x.  There are better browsers out there -- use them.

You're DEFinitely not a web dev. It's not in your pompous, ego to decide what browser a customer can/can't use. Moreso, there are still a helluva a lot more people that use Netscape browsers than those that use all text browsers. So, once again, just say no.

Quote: Good, then XHTML/CSS1/4.01 isn't  a solution...yet.
Yes, it is.

NO, NO it isn't.

Quote: Wrong.
No, not wrong.  The only way to make the pages look *identical* is to just give users a black-and-white 1-bit screenshot (anything more than that introduces issues with people who can't display more than X colours).  You can aim to have pages that look very similar, certainly.  But you can't have pages that look identical.  That isn't HTML's purpose, that isn't CSS's purpose, and it is not within the scope of either language.

The pages might as well be identical. That isn't possible even reasonably with CSS1.

The scripting object model has *NOTHING* to do with the DOM.  NOTHING.  This is why you can use JScript/JavaScript in situations that are NOT INSIDE WEB PAGES.  The languages stand alone without the DOM.

DOM affects the language because it *is* an object model. The languages, like Javascript could use its or W3C's.

Quote: I think our definition of reasonable is variant because for me, reasonable is *all* inclusive, not just those on platforms that I prefer.
But by including Netscape 4.x you're necessarily excluding certain other platforms.

Bullshit. Give me an example of necessary code that would do this.

Quote: That's not what I said. But thank you for putting words in my mouth. I said text could be manipulated using old plain, deprecated HTML.
Yes, it can, but not in a manner that degrades gracefully.  And not with anything like the same control as CSS gives you.

Hate to burst your bubble but the new HStore site is plain deprecated HTML and it degrades all the way to Netscape 2.0. I tested it on that.

So, once again, you're wrong.

Quote: And as for your question, perhaps rephrasing it could let me get you an answer, since table headers display just fine on HTML, the last time I checked.
That isn't what I asked.  I asked how you tell a screen reader how to read them with plain HTML.

And again, I ask you...which reader?

Quote: Uh, no it's not. In fact, we can go back to the post on CSS and we can gloss over me asking you how you locked your font size on PC. Customizable? No.
Er, it isn't locked.  What the fuck are you talking about?

Please, don't make me go back and fucking dig for the last "conversation" we had about this, six months ago. When you told me that I should let the text be alterable, only for me to turn around and find out that Win IE browsers prevented the modification of your text size. It's on this board and I'm on 16 baud right now but I'll fucking do it, if I have to.

The only browsers it didn't work on, were the Mac IE(which is why I never stole...*cough* borrowed the code from your site...)

Quote: Is your site ineffective? No. And your chick galleries are fly but what I AM saying is that you're talking about customization and you can't customize your site.
YES.  You can.  You see this:

It lets me have extensive control over the page.

Peter. This is why your ego needs a "diet".

"See this?"

Answer:No

And that sums up our conversation really well. You confidently assert something technically, without realizing that your platform != everyones'.

HOWEVER, it also relies on people writing the page in a particular way.  It relies on people using the header tags to denote levels in a document's hierarchy, for instance. If they use them just to impose certain styling elements -- or alternatively, if they use just font tags (or even CSS classes) to make their headings bigger -- then I can't override them in any meaningful way.  This overridability is incredibly powerful, but it is useless if people don't use HTML for structure properly.

Are you telling me you can't code CSS1 or that you can't code HTML?

Quote: No, today's policy is "best viewed to EVERYONE".
Except it isn't.  By making your site viewable in Netscape 4.x, you're preventing it from degrading gracefully.

One more time, I'll say bullshit.

Quote: Can be done with plain HTML. Name me a screen reader you have.
No, it can't be.

:rolleyes: Oh, well now...since you said so...

You've sure convinced me!

And, of course, there's Bobby.  http://www.cast.org/bobby/

I'll take a look at it tomorrow at the Herald.

Quote: DOM in BROWSERS is interpreted differently which affects how ECMAScripts execute.
That's btw, what is on the W3C site if you want to look at it again.
The DOM doesn't just exist in browsers

Netscape doesn't agree. It says that 6.01 includes DOM. To my knowledge, 6.01 is out.

(and doesn't just refer to (X)HTML documents).  And both common ECMAScript implementations are available as standalone languages -- neither is tied to the browser.

Damnit. I never said the languages are proprietary but their execution on proprietary browsers makes them subject to such circumstances!

If, for instance, I have a JScript like this:
WScript.Echo("Hello World!";
I'm not affected *at all* by the fact that WSH doesn't provide DOM bindings.  The DOM bindings have no impact on the language itself.

Well now. Hello World. Wow. Well, something that complex would be bound to have problems on browsers right? :rolleyes:

NOT having DOM isn't the problem. Having DOM "implemented" differently on browsers *is* the problem.

Quote: It's indicating how DHTML is operated.
Except the DOM doesn't have to use HTML, or XHTML.  Dynamic or otherwise.

What are you referring to? XML? Are you fucking kidding me?

Quote: You give me two examples of proprietary Netscape DOM as evidence? What?
Only one of those was a feature of Netscape.  Neither of them are a feature of the DOM.  Both of them are a feature of DHTML.

Both were DOM-proprietary for Netscape. Netscape's DOM(W3C didn't invent the word DOM..you knew that right?). BTW, the very technology you listed as features of DHTML are not exactly a high list of priority for Netscape(probably because of W3C DOM) because their developer page has exed out those bits and the pages have been taken down for that tech:

[code]
Description: Explains how to enhance pages that use LAYER, document.layers[], and
document.all to also support...
Category: Computers > Programming > ... > Upgrading Nav4 and IE Content
sites.netscape.net/ekrockhome/standards.html - 2k - Cached - Similar pages [/code]

Quote: A browser using DOM inconsistently
Browsers don't "use" the DOM.  It's not a language or a piece of software, it's something that the browser *implements*.

Fuck. If this isn't the most brazen attempt at winning a debate semantically, then I'm a cactus.

Quote: Which came first doesn't matter as long as the technology has been begun to be incorporated into N6x and IE6+. Your entire argument is that ECMAScript "predates DOM" and therefore DOM won't have any effect on them as an object model,
Of course.  The language is not altered by the object models/APIs that have bindings for that language.

Quote: despite the fact that browsers are adopting it disparately which we both have admitted and despite the fact that DOM deals with the execution of scripting, ECMA or otherwise.
No, the DOM does not deal with that.  It ignores that.  It provides an object model.  No more, no less.  If and how scripts manipulate that object model is not something it cares about.

DOM provides neutrality but the interpretation on various browsers will not be. (how many times have I said this?)

Quote: I never said DOM depended on the script, I said the script depends on the DOM and repeating it three times with a slight alteration each time doesn't make your point any more effective. The salient point is that while DOM itself is neutral, it's interpretation by browsers and platforms that *aren't* will ultimately affect scripting on said platforms, just like HTML is != on various browsers, despite W3C pushing it's "compatibile and compliant standards".
The point is, that doesn't make the languages different.

It makes their execution different which alters their function.

Quote: "The DOM defines the way in which HTML document objects are exposed to your script.  "
That's directly from Javascript 1.5 on netscape's developer page:
It's wrong.  The DOM does not require JavaScript language bindings.  The DOM says nothing about whether bindings exist for a given language.  The DOM does define the form which those bindings might take, but that is not the same.

Yes Peter, the official Javascript dev page is wrong. Only you can be right.

I don't have anymore time for this. I'm not arguing semantics or nonsense anymore. Believe what you want. Respond what you want. I've got better things to do than try to prove to someone that certain development technologies work/don't work.

M.

Mon Apr 1 00:01:17 2002

Semantics.

Ask any programmers if they would regard "doing two different things when only one is desired" is the same as "working".

So now you're saying it *is* possible for code operations to deviate depending on the set of circumstances/browsers/platform...

You're DEFinitely not a web dev. It's not in your pompous, ego to decide what browser a customer can/can't use. Moreso, there are still a helluva a lot more people that use Netscape browsers than those that use all text browsers. So, once again, just say no.

The pages might as well be identical. That isn't possible even reasonably with CSS1.

DOM affects the language because it *is* an object model. The languages, like Javascript could use its or W3C's.

Bullshit. Give me an example of necessary code that would do this.

Hate to burst your bubble but the new HStore site is plain deprecated HTML and it degrades all the way to Netscape 2.0. I tested it on that.

So, once again, you're wrong.

And again, I ask you...which reader?

Please, don't make me go back and fucking dig for the last "conversation" we had about this, six months ago. When you told me that I should let the text be alterable, only for me to turn around and find out that Win IE browsers prevented the modification of your text size.

It's on this board and I'm on 16 baud right now but I'll fucking do it, if I have to.

Peter. This is why your ego needs a "diet".

"See this?"

Answer:No

And that sums up our conversation really well. You confidently assert something technically, without realizing that your platform != everyones'.

Are you telling me you can't code CSS1 or that you can't code HTML?

One more time, I'll say bullshit.

Netscape doesn't agree. It says that 6.01 includes DOM. To my knowledge, 6.01 is out.

I said that the DOM doesn't just exist in browsers.

For example.

We have Xerces, which provides DOM bindings for amongst other things, Java and COM.  http://xml.apache.org/index.html .  It manipulates XML documents using the DOM-mandated interface.

We have IBM's XML parser, which provides DOM bindings for Java.  http://www.alphaworks.ibm.com/tech/xml4j

We have MSXML, which provides DOM bindings for COM.
http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/766/msdncompositedoc.xml

And others.

So what on earth does your response mean?

Well now. Hello World. Wow. Well, something that complex would be bound to have problems on browsers right? :rolleyes:

NOT having DOM isn't the problem. Having DOM "implemented" differently on browsers *is* the problem.

What are you referring to? XML? Are you fucking kidding me?

Both were DOM-proprietary for Netscape.

Fuck. If this isn't the most brazen attempt at winning a debate semantically, then I'm a cactus.

DOM provides neutrality but the interpretation on various browsers will not be. (how many times have I said this?)

It makes their execution different which alters their function.

Yes Peter, the official Javascript dev page is wrong. Only you can be right.

I don't have anymore time for this. I'm not arguing semantics or nonsense anymore. Believe what you want. Respond what you want. I've got better things to do than try to prove to someone that certain development technologies work/don't work.