The main problem with IFrames is that they (depending on the browser version) can be cached in browser history, causing what looks (to the user) to be leakage.
For example, in post 8.0 Opera, IFrames (if they are all from the same URL) are not retained. Opera stays under 25 MB of memory. OTOH Firefox 1.1 grows quickly up to about 250+ MB and then grows more slowly.
I have tested some browser versions (which I will leave nameless - and no - not what you are thinking) that will continue to quickly grow memory forever (or at least to bigger than the 1 GB I had available).
One other issue with IFrames is that you will need at least one additional IFrame per concurrent pending request (each IFrame can only manage one pending request) Since some browser versions make it difficult to dynamically create invisible IFrames in the DOM (under certain conditions), you will need to precreate (meaning hardcode into your page) enough IFrames to handle your maximum expected number of pending requests.
On the up side, the IFrame implementation allows you to test the bulk of your DOM UI completely off your local filesystem (no HTTP server necessary). Just set up the "actions" as individual xml files selected by your UI elements, and when the response xml is loaded and read, just have it modify the action bindings of your control elements as necessary to get it to follow the application state.
This trick can also be used to prototype the UI (for demoing and mockups) before the application server is ready.
IFrames are also easier to debug than XMLHttpRequest if you leave the IFrame temporarily visible.
I would say that the deciding factors are the browser versions you intend to support, and the expected longevity (in terms of data exchanges with the server) of your application page, relative to the rate of (apparent) memory leakage for the supported browsers.
is that this is the sort of support experience I can expect when I buy one of their products.
So what, pray tell, does their marketing team think would induce me to buy Windoze Vista or to recommend it to anybody else, if this is the sort of support I am going to get for it?
----- "Yea, I know I was there when she landed..Wait, Father, she said something I didn't understand well I didn't understand any of it but what does 'Ecto gammet' mean?"
I'm a Rogers user and I already have issues with their recent blocking of the SMTP port (they did that without warning, or reducing the service fee also), and their TOS regarding putting up web or FTP servers.
I've only stayed with Rogers because they had a reasonably reliable newsfeed.
Most DSL vendors here are significantly cheaper, but they usually don't provide reliable usenet.
Now that I have to pay extra to get reliable usenet, regardless of choice,
I may as well switch to a DSL ISP, improve my connectivity, and pocket the difference.
Hmmm, methinks it would also be a good time to review the alternatives for TV...
Oh well. So much for monopoly cable. At least DSL has competition.
I find that light wood colors reduce my stress, and it is good to keep your field of vision as clear as possible. You want to reduce distractions and keep the mood light and serene.
I put in laminate wood flooring (easier to clean) with a light coloured massive L-shaped laminate desk with hutch, and real wooden horizontal blinds (all similarly light woods)
The desk lets me hide a couple of workstations in it (out of sight, out of mind - and less noise too) and lets me hold a massive glass monitor (FP1370) on the desk, with an alternate flat panel monitor on the library return. The Belkin KVM, powerbar and all wiring are all hidden underneath. The old soapbar style MS mouse (with gel pad and mouse bungee) tucks away with the keyboard under the desk on a sliding shelf/tray.
The Klipsch satellite speakers are hidden away in various spaces and an electric coffee warmer pad, a phone, a webcam and a microphone is on the desk.
The 4x6 whiteboard is on the back wall so I have to swivel my mesh backed ergonomic chair to see it. The floor is protected with a clear mat against the chair's plastic casters.
Visitors seat themselves in a drafting chair (the kibitzing seat) just high enough to have difficulty reaching for the keyboard or my mouse. After all, a computer is more personal than underwear (no touching allowed).
The source control repository, database, NAS (get a big ATA one), firewall/router, LAN switch and web servers are all hidden away downstairs in the basement at a secondary L-shaped desk. I normally leave tbe repository and database servers off, but I can remote boot and VNC into them as needed. Any other funky hardware, old software, or odd parts need to hide in the basement office/server room too.
For software, I use Subversion for a repository, ANT for build scripts (regardless of programming target), and CodeWright for an editor (no longer commercially available - get SlickEdit instead). If I have to use an IDE, I use Eclipse, but usually it is more trouble than its worth. Hopefully it will be good enough someday soon.
For hardware, see the ARS system guide. http://arstechnica.com/guides/buyer/system-guide-2 00508.ars/4 Get the God box for your primary workstation. The secondary workstation should have removable drives so you can boot multiple OSes (screw bootloaders) and swap drives around.
All workstations and servers should be dual CPU. Web servers should be as low power as possible. Repository and database servers should have RAID for their storage drives (back them up to the NAS) Database server should have SCSI drives and at least 2GB RAM. All other boxes are OK with ATA or SATA drives and at least 1GB RAM.
Make sure you have one of those DVD/CD multiformat burner thingies (to cut releases), and a jump drive (to carry demo/test software around)
If you are serious about software, you will also have plenty of books and quite a few binders. Either get a separate room for them (a study) or put bookcases in the basement, or both (I had to do both) Disk media need to be stored in binders, towers or whatever, but keep a ready rack in your primary office (it's part of my desk hutch)
C-beams are likely referring to Cerenkov (radiation) beams (radiation given by particles moving FTL for a given medium). Their observation (in vacuum) near the Tanhauser Gate would imply the presence of charged tachyon (faster than light) particles coming from the gate. Which makes sense because "gate" likely refers to the sci-fi concept of "jump gate" (a kind of access point for FTL travel - like the terminus a wormhole)
Back in the days of Blade Runner, there was still a little science left in the science fiction.
> How exactly do you detect if your user has javascript disabled without going client-side? Javascript is obviously a must for DHTML.
Well, yes. Currently you have to go client side if you want to tell if JavaScript is enabled. I didn't say otherwise. I was advancing the potential advantages of having an accurate user agent string. Perhaps some additional (like JavaScript enabling) info should be passed along to the server as well. After all, we already pass language and compression handling capabilities.
However, regardless of whether you test for Javascript client-side or some hypothetical server side mechanism, if JavaScript actually is disabled, then there is very little you can do to detect the version or capabilities of the browser unless you go by the user agent string.
And even if JavaScript is disabled, you still need this info to send out the correct CSS (unless you rely on CSS hacks). So user agent string is all you have to go by.
Amazingly enough, in certain cases, having incompatible CSS can actually affect whether the page loads or just hangs the browser.
In principle, CSS should ignore things it doesn't understand. In practice, some browsers don't handle things like that well (cough Firefox). Usually, the best you can hope for is that the CSS parser will skip over CSS attribute names it doesn't understand. But some parsers can get hung up on values they don't understand for attribute names they do understand. CSS is supposed to degrade gracefully (and most times it does) but as you push the envelope on newer (version specific) capabilities, you start to run into problems.
> I'm a huge proponent of (as others have since posted in replies to the GP) detecting if your browser has the feature you need on the client-side, and working from there.
I used to believe that too (and I tend to code that way by habit and necessity). I was a big believer in the original WASP http://www.webstandards.org/ I believed in the "level 5 browser" concept. And in the DOM "standard" concept (with suitable workarounds for IE of course)
However, at the time, the test was supposed to be
if(document.getElementById)
Unfortunately Opera didn't have createElement (because it had no reflow capability) but they got WASP rubber stamped anyways. So much for the concept of "level 5 browsers" supporting DOM.
When Netscape 6.0 came out (and the next few subsequent ones) The model was sufficiently hosed that elements could not be relied on to be adjacent to each other (some unwanted inter cell gaps were added). Version detection was the only possible answer and client side detection was the only reliable way, but detecting versions in this way assumes that there will always be a JavaScript feature you can test for on the same version of a bug that isn't discoverable by JavaScript. At the time of Netscape 6.0 finding JavaScript reachable differences between versions was a highly target-rich situation.
More recently, the Firefox DOM has stabilized, and going forward, you may not be able to rely on a convenient test.
Note: this is not to say that WASP failed to achieve its goals (although goals are easier to reach by lowering the bar just before attaining them). WASP did help a lot (even if they had minimal impact on MSIE)
With proper OO JS there is no need for code to be "sprinkled everywhere with little browser validation tests" - you only need make your test once, your objects handle it from ther on.
What I was referring to was the idea that you have to add "if(ie5)" or "if(event.preventDefault)" throughout cross-browser framework code. This is because the code can be entered by application developers at any point, so detection must be placed inside any exposed API that needs it (and ECMA 262.3 has no way to make things private). I presume, most of us who code cross-browser frameworks have gotten used to it, but it
Just because you don't think knowing the browser version is important doesn't mean that everyone thinks the way you do. Plenty of people care enough about it enough that there are plenty of client side version detectors out there http://www.mozilla.org/docs/web-developer/sniffer/ browser_type.html
Perhaps, before calling us all idiots, you may want to offer an alternate solution that works.
> test "does this feature I want to use work"
It would be nice if I could do this, but the unfortunate reality is that CSS does not work this way.
Unfortunately, CSS capabilities are not testable from script in any browser. You can only rely on the browser version to determine what is or is not available. Getting it wrong might result in a minor cosmetic problem or a browser crash, or maybe a hang. It is cleaner instead to base CSS on the browser version.
This is a problem, yes. And it was made worse by not being able to rely on the user agent string.
The CSS hack approach seriously lacks elegance. I believe that version detection is far more elegant by comparison (providing you get the detailed version info - IE needs to report the service pack level).
Unfortunately, since the cat is already out of the bag (all the existing opera browser instances), relying on the user agent string will never truly be an airtight solution.
Perhaps instead, it would be easier and better to restore elegance to CSS. We just need to convince all the browser manufacturers to make the browser version truly testable in the CSS @media descriptor. Or maybe propose an @version descriptor.
most standards compliant XHTML and CSS will work on all modern graphical browsers
Um, no. IE consistently fails to measure up on CSS, and even Opera and Firefox have their own little quirks (neither have passed the Acid2 test yet AFAIK).
However the issue is not about using "standards" compliant (x)HTML and CSS. This level of compliance produces a lowest common behavior type UI. Some of us need to get past that. Instead of compliance to the existing standards, the issue is about using the browser as an advanced application delivery platform via DHTML (meaning DOM and JavaScript).
This means you end up pushing past where the standards go. Standards begin to lose their relevance, and (unless you have the clout to sit on a standards committee) instead you begin to look for "equivalent" behaviours.
To choose these, you need to know what browser (and what version) you are running on. Alternatively, you can detect for the functionality you will explicitly need, but then your code is sprinkled everywhere with little browser validation tests. Sometimes this is acceptable, sometimes less so.
But worse than adapting to browser DOM behavior, trying to do adaptive CSS that can detect and react to each browser is full of special case hacks and is fraught with peril. It would be much better if the browser identified itself properly to the server, and the server could provide back a specifically tailored CSS file. Unfortunately, this never works on the first hit onto your server, unless you do a reload/redirect.
All of these workarounds lack the simple elegance that would result if the server could just rely on the user agent string.
If you do almost anything of significance with DHTML and event handling, you quickly run into major differences. Opera, due to its closer adherence to W3C standards, is much closer to mozilla/firefox than IE.
Because of Opera trying to force its way in to IE only sites, advanced DHTML authors have been forced to use client side browser detection for years now. Browser detection is crucial for advanced sites, and not being able to detect them on the server side is a needless burden. This _is_ Opera's fault. Server side browser detection has become essentially useless because of Opera.
Actually, I'm a bit appalled that the hit counting sites don't also do their detection exclusively on the client side to avoid this issue.
In any case, because the Opera market penetration number is a little vague (around 1~2% with some loss due to miscounting) They get the benefit of the vagueness, and generally I have advocated for supporting them and not NN4, even though NN4 probably has a higher market penetration (NN4 is harder to support than Opera).
As for Opera downloads, I have several. As a web developer, I have to test against Opera (and IE 5.x and 6.x) but, my primary browser is Firefox.
it's only a matter of time before they are rendered obsolete
Dude, they are obsolete now. The purpose of the record industry is to record music onto storable media, promote it on the radio and distribute it to customers. They no longer add any value in this process. Home studios can do pretty much what the big recording studios do, and the internet is simply a better distribution and publishing medium. In any case, the effect of the controlling hand of the recording industry over the last decade, has been to deter the emergence of creative new artists and to push established artists into creating formulaic mediocrity.
What is needed to get things moving along in the right direction is to separate the real music industry (you know, the artists) from the recording industry. We as consumers need to reward artists that don't go through the recording industry, and we need to persuade the rest that they are tied to a sinking rock. Go to concerts, buy music and products from artists on the right side of this and boycott the rest. Governments can only afford to prop up industries that are able to pay bribes (um, contributions).
Slashdot Mirror
The main problem with IFrames is that they (depending on the browser version) can be cached in browser history, causing what looks (to the user) to be leakage.
For example, in post 8.0 Opera, IFrames (if they are all from the same URL) are not retained. Opera stays under 25 MB of memory. OTOH Firefox 1.1 grows quickly up to about 250+ MB and then grows more slowly.
I have tested some browser versions (which I will leave nameless - and no - not what you are thinking) that will continue to quickly grow memory forever (or at least to bigger than the 1 GB I had available).
One other issue with IFrames is that you will need at least one additional IFrame per concurrent pending request (each IFrame can only manage one pending request)
Since some browser versions make it difficult to dynamically create invisible IFrames in the DOM (under certain conditions), you will need to precreate (meaning hardcode into your page) enough IFrames to handle your maximum expected number of pending requests.
On the up side, the IFrame implementation allows you to test the bulk of your DOM UI completely off your local filesystem (no HTTP server necessary). Just set up the "actions" as individual xml files selected by your UI elements, and when the response xml is loaded and read, just have it modify the action bindings of your control elements as necessary to get it to follow the application state.
This trick can also be used to prototype the UI (for demoing and mockups) before the application server is ready.
IFrames are also easier to debug than XMLHttpRequest if you leave the IFrame temporarily visible.
I would say that the deciding factors are the browser versions you intend to support, and the expected longevity (in terms of data exchanges with the server) of your application page, relative to the rate of (apparent) memory leakage for the supported browsers.
is that this is the sort of support experience I can expect when I buy one of their products.
So what, pray tell, does their marketing team think would induce me to buy Windoze Vista or to recommend it to anybody else, if this is the sort of support I am going to get for it?
-----
"Yea, I know I was there when she landed..Wait, Father, she said something I didn't understand well I didn't understand any of it but what does 'Ecto gammet' mean?"
I'm a Rogers user and I already have issues with their recent blocking of the SMTP port (they did that without warning, or reducing the service fee also), and their TOS regarding putting up web or FTP servers. I've only stayed with Rogers because they had a reasonably reliable newsfeed. Most DSL vendors here are significantly cheaper, but they usually don't provide reliable usenet. Now that I have to pay extra to get reliable usenet, regardless of choice, I may as well switch to a DSL ISP, improve my connectivity, and pocket the difference. Hmmm, methinks it would also be a good time to review the alternatives for TV ...
Oh well. So much for monopoly cable. At least DSL has competition.
When I first read the title, I thought it said: "Gates Donates $15M to Preserve Continuing History"
I find that light wood colors reduce my stress,
2 00508.ars/4
and it is good to keep your field of vision as clear as possible. You want to reduce distractions and keep the mood light and serene.
I put in laminate wood flooring (easier to clean) with a light coloured massive L-shaped laminate desk with hutch, and real wooden horizontal blinds (all similarly light woods)
The desk lets me hide a couple of workstations in it (out of sight, out of mind - and less noise too) and lets me hold a massive glass monitor (FP1370) on the desk, with an alternate flat panel monitor on the library return. The Belkin KVM, powerbar and all wiring are all hidden underneath.
The old soapbar style MS mouse (with gel pad and mouse bungee) tucks away with the keyboard under the desk on a sliding shelf/tray.
The Klipsch satellite speakers are hidden away in various spaces and an electric coffee warmer pad, a phone, a webcam and a microphone is on the desk.
The 4x6 whiteboard is on the back wall so I have to swivel my mesh backed ergonomic chair to see it. The floor is protected with a clear mat against the chair's plastic casters.
Visitors seat themselves in a drafting chair (the kibitzing seat) just high enough to have difficulty reaching for the keyboard or my mouse. After all, a computer is more personal than underwear (no touching allowed).
The source control repository, database, NAS (get a big ATA one), firewall/router, LAN switch and web servers are all hidden away downstairs in the basement at a secondary L-shaped desk. I normally leave tbe repository and database servers off, but I can remote boot and VNC into them as needed. Any other funky hardware, old software, or odd parts need to hide in the basement office/server room too.
For software, I use Subversion for a repository, ANT for build scripts (regardless of programming target), and CodeWright for an editor (no longer commercially available - get SlickEdit instead). If I have to use an IDE, I use Eclipse, but usually it is more trouble than its worth. Hopefully it will be good enough someday soon.
For hardware, see the ARS system guide.
http://arstechnica.com/guides/buyer/system-guide-
Get the God box for your primary workstation.
The secondary workstation should have removable drives so you can boot multiple OSes (screw bootloaders) and swap drives around.
All workstations and servers should be dual CPU.
Web servers should be as low power as possible.
Repository and database servers should have RAID for their storage drives (back them up to the NAS) Database server should have SCSI drives and at least 2GB RAM. All other boxes are OK with ATA or SATA drives and at least 1GB RAM.
Make sure you have one of those DVD/CD multiformat burner thingies (to cut releases), and a jump drive (to carry demo/test software around)
If you are serious about software, you will also have plenty of books and quite a few binders. Either get a separate room for them (a study) or put bookcases in the basement, or both (I had to do both) Disk media need to be stored in binders, towers or whatever, but keep a ready rack in your primary office (it's part of my desk hutch)
Actually the C-beams weren't improvised by Hauer, the C-beams survived being cut out in the improvisation by Hauer.
t xt
http://www.rutgerhauer.org/filmography/brdir.php
They were originally added to the 1981 version of the script by David Peoples
http://brmovie.com/Downloads/Docs/BR_Script_1981.
C-beams are likely referring to Cerenkov (radiation) beams (radiation given by particles moving FTL for a given medium). Their observation (in vacuum) near the Tanhauser Gate would imply the presence of charged tachyon (faster than light) particles coming from the gate. Which makes sense because "gate" likely refers to the sci-fi concept of "jump gate" (a kind of access point for FTL travel - like the terminus a wormhole)
Back in the days of Blade Runner, there was still a little science left in the science fiction.
> How exactly do you detect if your user has javascript disabled without going client-side? Javascript is obviously a must for DHTML.
Well, yes. Currently you have to go client side if you want to tell if JavaScript is enabled. I didn't say otherwise. I was advancing the potential advantages of having an accurate user agent string. Perhaps some additional (like JavaScript enabling) info should be passed along to the server as well. After all, we already pass language and compression handling capabilities.
However, regardless of whether you test for Javascript client-side or some hypothetical server side mechanism, if JavaScript actually is disabled, then there is very little you can do to detect the version or capabilities of the browser unless you go by the user agent string.
And even if JavaScript is disabled, you still need this info to send out the correct CSS (unless you rely on CSS hacks). So user agent string is all you have to go by.
Amazingly enough, in certain cases, having incompatible CSS can actually affect whether the page loads or just hangs the browser.
In principle, CSS should ignore things it doesn't understand. In practice, some browsers don't handle things like that well (cough Firefox). Usually, the best you can hope for is that the CSS parser will skip over CSS attribute names it doesn't understand. But some parsers can get hung up on values they don't understand for attribute names they do understand. CSS is supposed to degrade gracefully (and most times it does) but as you push the envelope on newer (version specific) capabilities, you start to run into problems.
> I'm a huge proponent of (as others have since posted in replies to the GP) detecting if your browser has the feature you need on the client-side, and working from there.
I used to believe that too (and I tend to code that way by habit and necessity).
I was a big believer in the original WASP http://www.webstandards.org/
I believed in the "level 5 browser" concept. And in the DOM "standard" concept (with suitable workarounds for IE of course)
However, at the time, the test was supposed to be
if(document.getElementById)
Unfortunately Opera didn't have createElement (because it had no reflow capability) but they got WASP rubber stamped anyways. So much for the concept of "level 5 browsers" supporting DOM.
When Netscape 6.0 came out (and the next few subsequent ones) The model was sufficiently hosed that elements could not be relied on to be adjacent to each other (some unwanted inter cell gaps were added). Version detection was the only possible answer and client side detection was the only reliable way, but detecting versions in this way assumes that there will always be a JavaScript feature you can test for on the same version of a bug that isn't discoverable by JavaScript. At the time of Netscape 6.0 finding JavaScript reachable differences between versions was a highly target-rich situation.
More recently, the Firefox DOM has stabilized, and going forward, you may not be able to rely on a convenient test.
Note: this is not to say that WASP failed to achieve its goals (although goals are easier to reach by lowering the bar just before attaining them). WASP did help a lot (even if they had minimal impact on MSIE)
With proper OO JS there is no need for code to be "sprinkled everywhere with little browser validation tests" - you only need make your test once, your objects handle it from ther on.
What I was referring to was the idea that you have to add "if(ie5)" or "if(event.preventDefault)" throughout cross-browser framework code. This is because the code can be entered by application developers at any point, so detection must be placed inside any exposed API that needs it (and ECMA 262.3 has no way to make things private). I presume, most of us who code cross-browser frameworks have gotten used to it, but it
> You can detect opera on the server just fine
r ids
h tml
e xtensions/nsextensions.htm
/ browser_type.html
Oh? Perhaps you can tell me what happens when you set an entry in ua.ini to 4 or 5?
http://www.scss.com.au/family/andrew/opera/browse
> And no, you don't need to test for browser or version ever, for any reason, period.
So I guess I shouldn't care that earlier versions of Opera don't support certain CSS parsing behavior
http://centricle.com/ref/css/filters/?whitebg
And I shouldn't care what improvements happen between versions of the same browser in case someone is using an older one
http://www.quirksmode.org/css/selector_attribute.
And I shouldn't care when Firefox implements CSS3 and eventually deprecates/drops the -moz equivalents like -moz-box-sizing
http://www.blooberry.com/indexdot/css/properties/
Just because you don't think knowing the browser version is important doesn't mean that everyone thinks the way you do. Plenty of people care enough about it enough that there are plenty of client side version detectors out there
http://www.mozilla.org/docs/web-developer/sniffer
Perhaps, before calling us all idiots, you may want to offer an alternate solution that works.
> test "does this feature I want to use work"
It would be nice if I could do this, but the unfortunate reality is that CSS does not work this way.
Unfortunately, CSS capabilities are not testable from script in any browser. You can only rely on the browser version to determine what is or is not available. Getting it wrong might result in a minor cosmetic problem or a browser crash, or maybe a hang. It is cleaner instead to base CSS on the browser version.
This is a problem, yes. And it was made worse by not being able to rely on the user agent string.
CSS hacks were the result. eg.
http://www.albin.net/CSS/OwenHack.html
But CSS hacks are an ugly workaround and don't solve all your problems.
http://digital-web.com/articles/keep_css_simple/
The CSS hack approach seriously lacks elegance.
I believe that version detection is far more elegant by comparison
(providing you get the detailed version info - IE needs to report the service pack level).
Unfortunately, since the cat is already out of the bag (all the existing opera browser instances), relying on the user agent string will never truly be an airtight solution.
Perhaps instead, it would be easier and better to restore elegance to CSS. We just need to convince all the browser manufacturers to make the browser version truly testable in the CSS @media descriptor. Or maybe propose an @version descriptor.
most standards compliant XHTML and CSS will work on all modern graphical browsers
Um, no. IE consistently fails to measure up on CSS, and even Opera and Firefox have their own little quirks (neither have passed the Acid2 test yet AFAIK).
However the issue is not about using "standards" compliant (x)HTML and CSS. This level of compliance produces a lowest common behavior type UI. Some of us need to get past that. Instead of compliance to the existing standards, the issue is about using the browser as an advanced application delivery platform via DHTML (meaning DOM and JavaScript).
This means you end up pushing past where the standards go. Standards begin to lose their relevance, and (unless you have the clout to sit on a standards committee) instead you begin to look for "equivalent" behaviours.
To choose these, you need to know what browser (and what version) you are running on. Alternatively, you can detect for the functionality you will explicitly need, but then your code is sprinkled everywhere with little browser validation tests. Sometimes this is acceptable, sometimes less so.
But worse than adapting to browser DOM behavior, trying to do adaptive CSS that can detect and react to each browser is full of special case hacks and is fraught with peril. It would be much better if the browser identified itself properly to the server, and the server could provide back a specifically tailored CSS file. Unfortunately, this never works on the first hit onto your server, unless you do a reload/redirect.
All of these workarounds lack the simple elegance that would result if the server could just rely on the user agent string.
Opera can render IE pages just fine
:-)
Oh no it can't.
If you do almost anything of significance with DHTML and event handling, you quickly run into major differences.
Opera, due to its closer adherence to W3C standards, is much closer to mozilla/firefox than IE.
Because of Opera trying to force its way in to IE only sites, advanced DHTML authors have been forced to use client side browser detection for years now. Browser detection is crucial for advanced sites, and not being able to detect them on the server side is a needless burden. This _is_ Opera's fault. Server side browser detection has become essentially useless because of Opera.
Actually, I'm a bit appalled that the hit counting sites don't also do their detection exclusively on the client side to avoid this issue.
In any case, because the Opera market penetration number is a little vague (around 1~2% with some loss due to miscounting) They get the benefit of the vagueness, and generally I have advocated for supporting them and not NN4, even though NN4 probably has a higher market penetration (NN4 is harder to support than Opera).
As for Opera downloads, I have several. As a web developer, I have to test against Opera (and IE 5.x and 6.x) but, my primary browser is Firefox.
So don't count my Opera downloads in the total
Dude, they are obsolete now. The purpose of the record industry is to record music onto storable media, promote it on the radio and distribute it to customers. They no longer add any value in this process. Home studios can do pretty much what the big recording studios do, and the internet is simply a better distribution and publishing medium. In any case, the effect of the controlling hand of the recording industry over the last decade, has been to deter the emergence of creative new artists and to push established artists into creating formulaic mediocrity.
What is needed to get things moving along in the right direction is to separate the real music industry (you know, the artists) from the recording industry. We as consumers need to reward artists that don't go through the recording industry, and we need to persuade the rest that they are tied to a sinking rock. Go to concerts, buy music and products from artists on the right side of this and boycott the rest. Governments can only afford to prop up industries that are able to pay bribes (um, contributions).
It's called disintermediation, dude.