Using "document.all" to infer if the user is using IE or a "standards compliant browser" (by which you mean Mozilla, specifically) is a horribly broken way of doing things.
Actually it's not that bad when used as intended. It's supposed to be used to interrogate the browser to find out what features it actually supports, and then send it down the path that uses those features.
In the big WWW, in practice, a few assumptions are made - it's not deemed worth while to query every possible features used and write a code path for all possible permeations, so authors have picked the big three, IE, NS4, and Moz (or two IE, NS4 if this is legacy 1999 code we're talking about).
Taking this a bit out of order now.
getElementById() code written for IE generally runs 95% perfectly on Mozilla, in my experience. document.all code would do the same, if given a chance.
The first part doesn't suprise me all that much to be honest. getElementById() was first supported in IE6, which made a reasonable effort at standards compliance. By using document.getElementById() the author is pretty much saying he/she gives a damn about standards compliance (and if they don't use document.all at all, that in your intraweb, IE4 and IE5 don't matter), so it's not all that surprising that Mozilla would eat that and not choke. It doesn't follow at all by extension that document.all support would enable Mozilla to support most of the legacy scripts out on the web.
My background is working with intranet and vertical market codemonkeys [...] Now, it sounds like you are coming from the HTML guy's perspective
You are correct, and herein lies why are views don't mesh that well.
In your small, controlled, intraweb I can quite believe that document.all support would be a magic bullit.
You bring up IE's bugs and malformed DOM and so on, but realistically it's a pretty rare problem
Tag soup and bugs-that-became-features on the WWW aren't a rare problem, dealing with it in a sane way is why it's so hard to write a web browser that people won't immediately label as crap. Dave Hyatt (Safari and Firefox dev) recently brought this up in a discussion about XML error handling. So in the wider world, you can't rely on the DOM tree to look the same in different web browsers, and this itself is going to cause significant scripting (and display) problems.
(NS4 doesn't have much in the way of a DOM anyway, hence why I think you can make a stronger claim that document.layers should be supported in order to help legacy scripts, but personally I'm glad neither document.all or document.layers is in there).
I guess I'm not in any position to say what would break if Mozilla supported document.all, but I can say that tons of stuff would start working.
And if you break much more than you fix, what then?
What I'm saying is I don't see how fixing 95% of 10% (Intraweb apps) of sites scripting problems with document.all support is going to help when it may well break 19% of the remaining 90% (nasty tag soup real WWW code) and fixing just 1%(, and at the same time anger developers who lent their support to Mozilla early on).
Somehow though, I don't suppose we'll ever come to an agreement on this subject other than to agree to disagree:)
Unlike sucky layers, the IE DOM was based on W3C not all document.all code would work on Mozilla, but probably 80-90% of would work unmodified.
I'd say your guesstimate of 80-90% is hopelessly optimistic in my experiance. Even if the only IE only method in a script is document.all you face a problem when traversing the DOM. Sucky HTML leads trident (the Win/IE engine) to create a malformed DOM (Google cache of Ian Hixons (Opera Developer) blog), which would mean traversing the DOM won't necessisarily land you in the same place in Mozilla and IE.
Those legacy scripts that document.all support is supposed to save are nearly all sat on legacy web pages with legacy sucky tag soup HTML.
Current IE developers use document.getElementById() and then don't bother testing in Mozilla/Opera/Safari/etc, so this problem is not unique to document.all.
Again, not in my experiance (if by IE developers you mean web developers). Most current scripts detect IE by the presence of document.all, and standards based browsers by the support of document.GetElementById but not document all. IE6 which is often capable of following the document.GetElementById path gets shot off down the old IE4 document.all route.
Supporting document.all would break the above method of detection, breaking the scripts of those nice enough to give a damn about the standards compliant route, and probably discourage them from using these standards in the future. Just at a time when Mozilla and other browsers seem to be getting some traction.
If however by "Current IE developers use document.getElementById()" you mean there really is a large body of people who are detecting IE6 by the presence of document.getElementById(), and using it in a way that can't work with Mozilla, could you point me towards a few examples in the wild.
With respect to legacy code bases, perhaps the most logical way to magically make 1999 era code work with Mozilla would not be to make Mozilla an IE emulator and support document.all (and all IE's other propriatory methods, documented, undocumented, bugs and all - which you've admitted yourself elsewhere in this story that not even IE does), but to support document.layers. They do at least have access to the actual code (horrible that it is) that did the work.
Especially as a lot of 1999 era code sniffs for the presence of 'Navigator' in the UA string, then, if present, shoves the UA down a path where often document.layers is used.
The irony is of course, that this would effectively revive Netscape4, something that I believe your username and sig suggests you really wouldn't like to happen.
As an aside, there's a Mozdev project that allows 1999 era document.layers code to run in Mozilla by emulating the document.layers interface. The developer simply needs to drop a link to the.js file in the head of the document IIRC. I'll not link to it to save Mozdev the slashdotting, but it's easy enough to find if you want it.
Well, for a start, a lot of scipts do a simple browser sniff to see if the UA supports document.all (IE), document.layers (Netscape4), or document.GetElementByID (i.e. standards compliant - Mozilla and Safari).
Basically, once you commit to supporting dcument.all you have to commit to supporting every other propriatory extention IE offers (yes, even the bugs in those extentions) to be sure peoples javascript still works. Even when they have provided a standards compliant way of doing things.
So document.all support doesn't really give you anything, you can support it, but the document.all path is bound to have other IE only methods in it. If you dont support those methods, the script won't work anyway. And there's a good chance that the standards compliant version that was available and Mozilla could have run won't be chosen as the script now thinks Mozilla is IE.
IIRC Konq does support document.all and document.GetElementByID IIRC. I also believe they have the exact problem outlined above.
(In practice, the standards compliant route seems to be chosen based on the UA supporting document.GetElementByID but not document.all, as IE6 supports both.)
I thought that too, then on Friday I got my first SMS spam, it looked a lot (but not quite) like this.
Basically, spam a bunch of people with the promise of a holiday if they ring a number (premium rate, but hope that the sucker doesn't notice). When they ring they are instantly stung for £12 (about $20).
Obviously you dont need too many suckers to recoup the cost of the initial SMS spam...:(
My own Abit KG7 (Introduced *before* the XP line) has worked with all the 133 FSB Athlons, although it needed a BIOS update initially to get the XPs going (and I don't count that as a hack, more a bug fix).
Additionally I had a 100MHz FSB Socket A Athlon going for a while, though since the motherboard was released after the introduction of those I wouldn't have expected problems anyway.
Your claim of no pin compatibility between the various CPUs is false, at least in my experience.
No, its been a part of Mozilla (the app suite) since 0.9.5 by default.
View>Show/Hide>Site Navigation bar.
I've since learnt the Opera version does a bit more than just look at link elements though. Apparently if it finds an anchor with the text "Next" it'll offer that link in the link toolbar. Kinda neat:)
the difference is that with windows, there's no alternative to windows update.
I don't -have- to use RH update -- i can use any number of repositories & apt-get, etc...
While it's from the same place (MS), here is your alternative to Windows Update. Works with web browsers other than IE too.
Have fun keeping track of what you have patched though:)
Re:Gotta love british humor
on
Spam, Milord
·
· Score: 4, Informative
Lady Saltoun of Abernethy: My Lords, do the Government have any plans to restrict unsolicited faxes? My fax paper is always being wasted by people who send me faxes I do not want.
I doubt she reads/. , but by calling 0845 070 0702 you can opt out from the fax direct marketing list. It nicely cut down the ammount of fax spam we had in work from around 15-20 pages to, well, 0.
7. It happened when I hit one of the keys in one of the screens and I saw a message that said something appear. I think it was that version with the 1 in the name. It might have been Mozilla or Opera, don't ask me.
Urrgh:(
Here is the entire content of an IM my aunt sent me tonight:
Steve need to talk to u please to find out what I have to click! I have sent emails to all your addys.......all returned.. You must have changed them,,, it wont take 2 mins ok Jan
1)Very descriptive. 2)I only have one email address, it's working just fine. Way to lay the blame on me. 3)Whatever it is shes talking about may well take only two minutes. I just know shes bound to have a huge list of "little" things waiting for me when I go to sort out whatever the original proplem is...
I'm just not convinced that it wouldn't instantly lead to a great big game of pass the buck - ultimately ending up at whoever wrote whatever snippit of code.
I'm not sure UCITA is the correct way to go about it, but I think we do need some way of assigning responsibility for software failures, and opening up authors and distributors of software for lawsuits when it does fail.
Slashdot Mirror
Actually it's not that bad when used as intended. It's supposed to be used to interrogate the browser to find out what features it actually supports, and then send it down the path that uses those features.
In the big WWW, in practice, a few assumptions are made - it's not deemed worth while to query every possible features used and write a code path for all possible permeations, so authors have picked the big three, IE, NS4, and Moz (or two IE, NS4 if this is legacy 1999 code we're talking about).
Taking this a bit out of order now.
The first part doesn't suprise me all that much to be honest. getElementById() was first supported in IE6, which made a reasonable effort at standards compliance. By using document.getElementById() the author is pretty much saying he/she gives a damn about standards compliance (and if they don't use document.all at all, that in your intraweb, IE4 and IE5 don't matter), so it's not all that surprising that Mozilla would eat that and not choke. It doesn't follow at all by extension that document.all support would enable Mozilla to support most of the legacy scripts out on the web.
You are correct, and herein lies why are views don't mesh that well.
In your small, controlled, intraweb I can quite believe that document.all support would be a magic bullit.
Tag soup and bugs-that-became-features on the WWW aren't a rare problem, dealing with it in a sane way is why it's so hard to write a web browser that people won't immediately label as crap. Dave Hyatt (Safari and Firefox dev) recently brought this up in a discussion about XML error handling. So in the wider world, you can't rely on the DOM tree to look the same in different web browsers, and this itself is going to cause significant scripting (and display) problems.
(NS4 doesn't have much in the way of a DOM anyway, hence why I think you can make a stronger claim that document.layers should be supported in order to help legacy scripts, but personally I'm glad neither document.all or document.layers is in there).
And if you break much more than you fix, what then?
What I'm saying is I don't see how fixing 95% of 10% (Intraweb apps) of sites scripting problems with document.all support is going to help when it may well break 19% of the remaining 90% (nasty tag soup real WWW code) and fixing just 1%(, and at the same time anger developers who lent their support to Mozilla early on).
Somehow though, I don't suppose we'll ever come to an agreement on this subject other than to agree to disagree
I'd say your guesstimate of 80-90% is hopelessly optimistic in my experiance. Even if the only IE only method in a script is document.all you face a problem when traversing the DOM. Sucky HTML leads trident (the Win/IE engine) to create a malformed DOM (Google cache of Ian Hixons (Opera Developer) blog), which would mean traversing the DOM won't necessisarily land you in the same place in Mozilla and IE.
Those legacy scripts that document.all support is supposed to save are nearly all sat on legacy web pages with legacy sucky tag soup HTML.
Again, not in my experiance (if by IE developers you mean web developers). Most current scripts detect IE by the presence of document.all, and standards based browsers by the support of document.GetElementById but not document all. IE6 which is often capable of following the document.GetElementById path gets shot off down the old IE4 document.all route.
Supporting document.all would break the above method of detection, breaking the scripts of those nice enough to give a damn about the standards compliant route, and probably discourage them from using these standards in the future. Just at a time when Mozilla and other browsers seem to be getting some traction.
If however by "Current IE developers use document.getElementById()" you mean there really is a large body of people who are detecting IE6 by the presence of document.getElementById(), and using it in a way that can't work with Mozilla, could you point me towards a few examples in the wild.
With respect to legacy code bases, perhaps the most logical way to magically make 1999 era code work with Mozilla would not be to make Mozilla an IE emulator and support document.all (and all IE's other propriatory methods, documented, undocumented, bugs and all - which you've admitted yourself elsewhere in this story that not even IE does), but to support document.layers. They do at least have access to the actual code (horrible that it is) that did the work.
.js file in the head of the document IIRC. I'll not link to it to save Mozdev the slashdotting, but it's easy enough to find if you want it.
Especially as a lot of 1999 era code sniffs for the presence of 'Navigator' in the UA string, then, if present, shoves the UA down a path where often document.layers is used.
The irony is of course, that this would effectively revive Netscape4, something that I believe your username and sig suggests you really wouldn't like to happen.
As an aside, there's a Mozdev project that allows 1999 era document.layers code to run in Mozilla by emulating the document.layers interface. The developer simply needs to drop a link to the
Well, for a start, a lot of scipts do a simple browser sniff to see if the UA supports document.all (IE), document.layers (Netscape4), or document.GetElementByID (i.e. standards compliant - Mozilla and Safari).
Basically, once you commit to supporting dcument.all you have to commit to supporting every other propriatory extention IE offers (yes, even the bugs in those extentions) to be sure peoples javascript still works. Even when they have provided a standards compliant way of doing things.
So document.all support doesn't really give you anything, you can support it, but the document.all path is bound to have other IE only methods in it. If you dont support those methods, the script won't work anyway. And there's a good chance that the standards compliant version that was available and Mozilla could have run won't be chosen as the script now thinks Mozilla is IE.
IIRC Konq does support document.all and document.GetElementByID IIRC. I also believe they have the exact problem outlined above.
(In practice, the standards compliant route seems to be chosen based on the UA supporting document.GetElementByID but not document.all, as IE6 supports both.)
And Mozilla users can get an excellent pie menu extention here .
:)
Browsing just doesnt feel right without it
Did you know that you can now use ActiveX objects in Netscape and Mozilla?
Well, on windows atleast. And it requires a bit of pref hacking to let other stuff run.
Try the books then.
Its the distance between the holes in the mask IIRC.
What actually got me is the suggestion that VCRs dont record TV programmes...
I thought that too, then on Friday I got my first SMS spam, it looked a lot (but not quite) like this.
Basically, spam a bunch of people with the promise of a holiday if they ring a number (premium rate, but hope that the sucker doesn't notice). When they ring they are instantly stung for £12 (about $20).
Obviously you dont need too many suckers to recoup the cost of the initial SMS spam...
Heh, must preview :-)
*shrug* Probably for the same reasons Epic has made Unreal 64 bit?
*shrug* Probably for the same reasons ?
Thats just wrong.
My own Abit KG7 (Introduced *before* the XP line) has worked with all the 133 FSB Athlons, although it needed a BIOS update initially to get the XPs going (and I don't count that as a hack, more a bug fix).
Additionally I had a 100MHz FSB Socket A Athlon going for a while, though since the motherboard was released after the introduction of those I wouldn't have expected problems anyway.
Your claim of no pin compatibility between the various CPUs is false, at least in my experience.
...Use the mouse?
When its made enough to offset all the POS movies that lose money?
No, its been a part of Mozilla (the app suite) since 0.9.5 by default.
:)
View>Show/Hide>Site Navigation bar.
I've since learnt the Opera version does a bit more than just look at link elements though. Apparently if it finds an anchor with the text "Next" it'll offer that link in the link toolbar. Kinda neat
Mozilla has had a link toolbar since 2001. And Firebird users can get one here.
While it's from the same place (MS), here is your alternative to Windows Update. Works with web browsers other than IE too.
Have fun keeping track of what you have patched though
I doubt she reads
(Number taken from here.)
I haven't seen to many people at any graphics design places let that stop them from buying Adobe's photoshop though...
Those people need CMYK seperations. PSP and The GIMP just don't cut it.
Urrgh
Here is the entire content of an IM my aunt sent me tonight:
1)Very descriptive.
2)I only have one email address, it's working just fine. Way to lay the blame on me.
3)Whatever it is shes talking about may well take only two minutes. I just know shes bound to have a huge list of "little" things waiting for me when I go to sort out whatever the original proplem is...
Gah
A quick google suggests that it's quite comparable to a 900MHz Celeron
I'm just not convinced that it wouldn't instantly lead to a great big game of pass the buck - ultimately ending up at whoever wrote whatever snippit of code.
:P
But I'm cynical like that.
The backend for SVG support has recnetly been rewritten to allow plugins for native rendering on different OS's.
:), and so can't be part of the official Mozilla builds as the code isnt tri-licenced under the GPL/LGPL/MPL
For instance, visitors to recent nightlies may notice two options for Win32:
mozilla-win32-svg-GDI-mathml.zip
Which uses a GDI plugin for rendering SVG on win32 and:
mozilla-win32-svg-libart-mathml.zip
Which uses libart
(BTW, both builds also include Calendar)
for miss quoting them.
At least thats the impression I'm given from browsing their blogs.