PDA

View Full Version : Script tag not supported in current browsers



mabel_minn
08-09-2007, 01:38 PM
1) Script Title: Tabs Menu (mouseover)

2) Script URL (on DD): http://dynamicdrive.com/dynamicindex1/tabmouseover.htm

3) Describe problem:
This script uses <layer> and <ilayer>. From what I've been able to gather, these two tags are no longer supported by any current browsers. However, the script advertises that it works with "FF1+ IE5+ Opr7+". This seems misleading, at the least. If someone could shed some additional light on this, I would appreciate it! Thanks!

jscheuer1
08-09-2007, 03:01 PM
That tag was used to give backward compatibility to NN4 type browsers. It will not prevent the script from working in modern browsers.

mabel_minn
08-09-2007, 09:48 PM
Thanks for your input...that helps to explain things. Could I just take out the <layer> and <ilayer> statements? I've got the page coded both with a XHTML 1.0 Transitional and HTML 4.01 Transitional doctype. Should either of those work with this script? Thanks again for your help!

Twey
08-09-2007, 09:56 PM
Yes. You'd lose NN4 support, but hey, no-one cares about NN4 :p
I've got the page coded both with a XHTML 1.0 Transitional and HTML 4.01 Transitional doctype. Should either of those work with this script?It'll be valid HTML 4.01 Transitional if you remove the <layer> and <ilayer> and put the script in an external file. However, I strongly suggest you use HTML 4.01 Strict. There's really no reason to still be using either of the Transitional DOCTYPEs on the Web of today. XHTML should be avoided because IE doesn't support it yet.

jscheuer1
08-10-2007, 02:34 AM
Yes you can remove it, but there really is no need to unless you just can't sleep at night without passing the validator robot.

mabel_minn
08-10-2007, 03:40 AM
Not only was the validator failing, but the latest version of IE was giving me an error on the <layer> statements during runtime. I took them out and the error went away. Thank you both for your input. It really helped me out a great deal!

jscheuer1
08-10-2007, 04:04 AM
IE was giving me an error on the <layer> statements during runtime. I took them out and the error went away. Thank you both for your input. It really helped me out a great deal!

Mmm, not on the demo page though. I'm thinking that there must be something else going on with the page to do that. IE shouldn't even try to execute any layer statements unless you altered the script or have another that changes the meaning of some of the branching tests involved, something like that.

As Twey says though, it really isn't crucial to support NN4 any longer, except in special situations.

Oh, and you are welcome.

Twey
08-10-2007, 06:11 PM
It's browser detection, it's not hugely reliable.
Yes you can remove it, but there really is no need to unless you just can't sleep at night without passing the validator robot.Well I for one like to know that my code is actually HTML :)

jscheuer1
08-11-2007, 04:26 AM
Well I for one like to know that my code is actually HTML :)

I know that what I write is HTML, at least in some century. ;)

Anyways, we weren't discussing what you or I write, but what was written by someone else. No matter whatever else you may want to call it, it was HTML code at the time, and pretty darn serviceable HTML code at that, having stood the test of time so far.

I'm thinking that the error in IE reported by mabel_minn must have more behind it than has so far been let on.

Oh, and I agree, the browser detection of some of these older scripts is, at best, outmoded. But that has nothing to do with the HTML code. There is a thin line here with this script though, the 'detection' could be seen as feature branching and was quite good (whatever it is) for its day.

Twey
08-11-2007, 08:17 PM
No matter whatever else you may want to call it, it was HTML code at the time, and pretty darn serviceable HTML code at that, having stood the test of time so far.Agreed. A decade or so on, though, Web technologies have changed somewhat.
the 'detection' could be seen as feature branching and was quite good (whatever it is) for its day.Not really. You're right in saying that it was good compared to the majority of scripts in its day, but at the same time all the language features necessary for doing proper feature detection were there and could have been put to use. It's because of scripts like this one that DD has a bad reputation amongst experienced web developers.

jscheuer1
08-12-2007, 04:28 AM
Agreed. A decade or so on, though, Web technologies have changed somewhat.

I'm glad we are together on this one. Diverging from that point now - there was a time when there were no standards. In a sense, though there obviously are standards now, this is still true. The code that works is the code to use. This varies widely due to many circumstances. The standards approach is a good one, as is the quirks mode approach, and any variety of 'whatever you want to call them' approaches that make x-browser friendly code - if you know what you are doing. What (one thing that) the web needs is a way for the untrained to write good code. That's coming. The WYSIWYG's are improving, and are far better in many ways than a 1000 monkeys using a text editor. They are by no means ideal, yet.


Not really. You're right in saying that it was good compared to the majority of scripts in its day, but at the same time all the language features necessary for doing proper feature detection were there and could have been put to use. It's because of scripts like this one that DD has a bad reputation amongst experienced web developers.

A truly experienced developer would take into account the age of the scripts, and what is more, the vision and creativity involved in their making and their being brought together in such a free and highly organized site. Without really knowing, I would venture to say that there are few if any sites comparable to DD that have such diversity of freely available, accessible to the novice scripts, constantly being upgraded and added to. If there are any, I doubt that they are any more perfect from a coding standpoint. Add to that the traffic at DD (read 'the actual utility it affords the web community'), and you have something really valuable.

To those that feel smug in pointing out such lapses in the DD library I would say, "Join the community and add your knowledge in the pursuit of making these scripts even better".

I know you are on board with this, but what you might not understand, or perhaps you do - changes of that sort won't happen overnight. Without those who are knowledgeable and dedicated though, they never will.

Twey
08-12-2007, 06:25 AM
there was a time when there were no standards.Ah, now here's a tricky question. The specifications for HTML were open and available to all, certainly. I'd say that's as good as a standard.
The code that works is the code to use.Obviously -- code that doesn't work is of no use to anybody. However, "code" is a very general term and doesn't have a fixed definition. If we are writing HTML, we need to follow the standards, be they formal (which is always preferable, since we're guaranteed that they've been thought through and aren't going to change spontaneously in the future) or de-facto.
The standards approach is a good one, as is the quirks mode approach, and any variety of 'whatever you want to call them' approaches that make x-browser friendly code - if you know what you are doing.There is no truly cross-browser code without standards. Certainly, if one has huge amounts of time and experience, as well as an eidetic memory, and knows the quirks of every browser in existence one can incorporate different code to cater to each and every one of them. This will work fine, until a new browser comes out with different quirks. Standards of one kind or another are the only guarantee that future browsers will be able to make the slightest sense of our code.
What (one thing that) the web needs is a way for the untrained to write good code.I don't see why it should require such training. The concepts are perfectly simple to grasp.
That's coming.Highly debatable.
The WYSIWYG's are improving, and are far better in many ways than a 1000 monkeys using a text editor. They are by no means ideal, yet.And never will be. A machine has no sense of semantics, and thus is entirely unsuitable to write code in a semantic markup language such as HTML.
A truly experienced developer would take into account the age of the scripts, and what is more, the vision and creativity involved in their making and their being brought together in such a free and highly organized site.You inadvertantly argue against yourself by making it sound as though these scripts are fit only as museum pieces -- a sentiment with which I wholly agree, in some cases. It's true that the scripts are old, but even where age could be considered cause for poor quality (which is, in quite a lot of cases [for example, browser vs. feature detection] not a fair excuse), they should be retired until a new version can be written to avoid luring the novice into using them, unaware of the danger.
Without really knowing, I would venture to say that there are few if any sites comparable to DD that have such diversity of freely available, accessible to the novice scripts, constantly being upgraded and added to.If only they were constantly being upgraded. Those of us in this forum chip away at them, but the archives are vast, and some scripts really need to be retired completely. You're right, of course, in saying that most others are no better. DD only draws fire because it's one of the largest.
Add to that the traffic at DD (read 'the actual utility it affords the web community'), and you have something really valuable.Also debatable. This depends on how you look at it. For a novice web developer looking to add a flashy script to his/her site, something that can be copied and pasted from DD is ideal. However, if we look a little further down the chain to users, now or in later times, who can no longer access the novice web developer's site because the content is bound up in a poorly-designed script that the user is incapable of running for whatever reason, both the user and the web designer lose out. I think it's all too easy to forget that content is the core of the Web, and that while flashy designs and scripts can add a lot to that, when they're of a design such that they start obstructing access to the content, it would have been better off to not use them at all.

The fact that a large portion of DD's user base is made up of such novice designers is an argument for, not against, good code. KISS is one thing, but the novice web designer will not understand that the script will degrade their content without sufficient fallback, and will not provide for that eventuality.

jscheuer1
08-12-2007, 04:00 PM
I hope the original question in this thread was already answered, I think that it was.

Anyways Twey, you really sliced and diced my comments. You did forget at least one thing though. There is no truly cross browser code with standards either. The code that works across browsers without kludges, hacks, and/or supported workaround methods is pretty basic and a version of it can be executed in either standards or quirks mode, as I said, "If you know what you are doing". There is no guarantee of backward or forward compatibility using either method. The theory is that standards will continue to be supported, but the actual practice is more likely, only for a greater period of time, perhaps than quirks mode code.

Another thing I would take issue with is the awe which you seem stand in as regards the knowledge required to code well in quirks mode. I would actually put it about on a par with that required to write to standards. In fact, one method would be to code to standards avoiding any methods known not to work in quirks, remove your DOCTYPE and fix any minor problems that might pop up.

Twey
08-12-2007, 06:38 PM
The theory is that standards will continue to be supported, but the actual practice is more likely, only for a greater period of time, perhaps than quirks mode code.A theory is at least something to go on.
Another thing I would take issue with is the awe which you seem stand in as regards the knowledge required to code well in quirks mode. I would actually put it about on a par with that required to write to standards. In fact, one method would be to code to standards avoiding any methods known not to work in quirks, remove your DOCTYPE and fix any minor problems that might pop up.In every browser that exists or will exist, since their quirks modes are all different? Also, what do you do when they have two conflicting bugs such that to solve one causes the other? This is why we see such hideous code as:
if(is_ie)
document.write("IE specific code");
else if(is_nn4)
document.write("Netscape code");... and the authors invariably fail to take into account all browsers and thus break their scripts in many that would work just fine using simple, standardised code.

jscheuer1
08-13-2007, 03:15 PM
There is also the theory of quirks mode code writing which is well documented at quirksmode.org. So, we have theories in both directions. The fact that there is good documentation available puts the lie to your claim that one must know the quirk of every browser. In other words, there are, just as with standards code writing, a set of good practices. Whithout same in standards code writing, one must know every occasionally changing rule. Either method is daunting (to say the least) if the prospective practitioner believes that they must know everything about it before getting started.

Your example of poor javascript code branching is just that. The use of standards vs. quirks mode has nothing to do with whether or not one avoids such poor branching practices. However, your example doesn't even necessarily show poor branching. If the criteria established for the tested variables are object tests and the code which follows each branch is based on those objects and is written to them, rather than to some arbitrary idea of what a given browser supports, the code will be very highly servicable. However, it would be best if the object variables used for such branching had more appropriate names. Even if with that (as with all variables of that nature), they would best be created and used in the most limited scope applicable, something that isn't indicated one way or the other in your example.

Twey
08-13-2007, 07:52 PM
The fact that there is good documentation available puts the lie to your claim that one must know the quirk of every browser.How? What do you think that documentation is attempting to document? And I guarantee you that there's at least one browser, current or future, that it doesn't cover, and at least one browser bug that it doesn't mention.
Whithout same in standards code writing, one must know every occasionally changing rule.The rules don't change occasionally. The last major DTD release was a decade ago. They haven't changed since then. Once the next standard is released, HTML4 and XHTML1 will continue to be supported well into the next decade.
Your example of poor javascript code branching is just that. The use of standards vs. quirks mode has nothing to do with whether or not one avoids such poor branching practices.No -- in standards mode code for all decently-compliant browsers is the same, and code branching generally isn't necessary at all (for HTML, that is; Javascript branching can be done via feature detection, although even that would be unnecessary if browsers had better standards support).
However, your example doesn't even necessarily show poor branching. If the criteria established for the tested variables are object tests and the code which follows each branch is based on those objects and is written to them, rather than to some arbitrary idea of what a given browser supports, the code will be very highly servicable. However, it would be best if the object variables used for such branching had more appropriate names. Even if with that (as with all variables of that nature), they would best be created and used in the most limited scope applicable, something that isn't indicated one way or the other in your example.I specifically used the example of using document.write() to write some HTML. Code branching is indeed necessary in some cases in JS, but in standards-compliant code between reasonably standards-compliant browsers it is never necessary for writing HTML as it can be in quirks mode.

jscheuer1
08-14-2007, 02:37 AM
You make it sound like writing to standards overcomes all differences in browser implementations, this simply isn't true.

I think we are talking at cross purposes with script branching question and are essentially in agreement about what constitutes good vs. poor branching technique. I also think that you over state the importance of document.write in your example, as, even in poor branching technique, the only difference in document.write statements that I see much of for various browsers is NN4 layer syntax vs. all others that support either document.all and/or document.getElementById. In other words, there really isn't that much if any of it unless NN4 is being supported. Standards won't change that.

Twey
08-14-2007, 02:57 AM
You make it sound like writing to standards overcomes all differences in browser implementations, this simply isn't true.It certainly isn't -- at least not yet. However, those differences that do exist are primarily in CSS and and scripting implementations; I was using HTML as an example of standards mostly done right, and what could happen to CSS and JS in the future as well if we write standards-compliant code now. The original question in this thread is a good example of what code was like before standards existed. The thought of having to write different HTML for different browsers today (other, perhaps, than having to include different scripts or stylesheets) is one that doesn't often cross our minds. There are things that certain browsers (mostly IE) don't support, of course, but they tend to be "eye-candy" elements like <canvas> that aren't really necessary in a web page. XHTML is an exception, but we can make allowances for that by not using it, since (for now) embedding works just as well as mixed namespaces for most purposes.
I think we are talking at cross purposes with script branching question and are essentially in agreement about what constitutes good vs. poor branching technique. I also think that you over state the importance of document.write in your example, as, even in poor branching technique, the only difference in document.write statements that I see much of for various browsers is NN4 layer syntax vs. all others that support either document.all and/or document.getElementById.I think you're misunderstanding me. That is exactly the sort of thing that is avoided by browser and page developers both following standards.

The big difference is really where trust lies. If you write to standards, and somebody comes out with a new browser that doesn't display your page properly, it's their fault and you're perfectly within your rights to file a bug report and ask them to fix their browser so it works with your page. If you make up a markup language (which is essentially what you're doing if you don't follow any of the existing standards), you can't expect anything to support it. Some might, but that's coincidental; if they stop supporting it you can hardly complain.