Slashdot Mirror

1. We don't need someone to discuss something we already know. Is anyone here under the impression that this needs to be studied for the first time in human history because Apple created a phone? c = 2 × d × tan( theta ÷ 2 )
2. Who cares if the iPhone 4 strictly meets the resolution of the human retina? Different people have different eyesight. Certainly the Guiness record holder for best eyesight would not agree, but most of us need glasses, so what difference does it make to Apple's target market? It's better, that's what matters. In a couple of years, if every device has > 300ppi because Apple did this, I will be very, very happy. (I'm into photography, I'd love to be able to show images on a device that give some notion of sharpness.)
3. Apple fumbled this marketing claim. They should have said, Hey all, it's better! By making a scientific claim, they invited people to challenge it. The conversation has become about whether they have met some arbitrary goal rather than: it's better. Whee.

However, I'm finding that fewer sites seem to require me to do this. Things are improving on the W.W.W. for browsers. (Not just Opera, but it's nice that it's included as well.)

This extends the overridden XMLHttpRequest with methods to invoke server scripts with generalized get and post methods and easy-to-use form-based get and post methods.

However some people prefer Opera because it's
1) more secure .... link 1 .... link 2 .... link 3 .... link 4 .... link 5 .... link 6, September 16th 2005
2) faster
3) Is actively worked on -from Mike Connor, an important Firefox developer
4) smaller (3.7mb vs 4.7mb)
5) less bloat/ram usage

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/browser ids

Who cares? Guess what happens when I go through a proxy that changes or removes my useragent string? That has nothing to do with the normal browser behaviour. If you select report as IE in opera, it still says opera in the string. By your same logic you can't detect opera client side either because I can alter my opera to be named whatever I feel like.

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

That's correct, you shouldn't care. CSS exists to alter the look of a site. Unsupported CSS is ignored. All you should do is make the site correctly, and don't abuse CSS to format things incorrectly (sticking text under images if I changed my font size). If I am using an outdated browser, things may not look right. Oh well, that's what I get for using an outdated browser. At least I can still access the information, regardless of wether or not it looks precisely the way it did on your machine.

And I shouldn't care what improvements happen between versions of the same browser in case someone is using an older one

No, you shouldn't. HTML and CSS are standards. Write to the standard, this is simple and easy. Do not compensate for broken browsers, you can never get every obscure bug in every obscure browser, and older browsers simply don't support much of any CSS at all. None of this matters as its purely presentation.

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

Its not about caring, its about being misguided. The web is full of sites that don't work because someone "cared" so much that they customized the site for the browsers they know of, and in doing so fucked over the people using browsers they don't know about. Code to standard, degrade gracefully, it really is that simple. This not only makes web design far easier and saves your hair, but it works better than your misguided method of breaking your site for browsers you don't know about, or that have been altered.

Perhaps, before calling us all idiots, you may want to offer an alternate solution that works.

I did, do your job correctly. Your job is creating markup to format information, and CSS to style it. If the styling is not supported, it does not matter, the formatting and information still works. The web is not print, you cannot and will not ever be able to ensure that your site looks the same for everyone, so quit trying. Just make it *accessable* to everyone, and let the people who use up to date browsers have nice styling, and the people who don't have less nice styling.

It would be nice if I could do this, but the unfortunate reality is that CSS does not work this way.

Ecmascript does, and its the only case where you need to care. If something isn't supported in CSS, it will be ignored, and doesn't matter at all. Unsupported ecmascript may pop up error notices on the browser if its not set to hide those errors.

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.

You will always get it wrong f

> You can detect opera on the server just fine

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/browser ids

> 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.h tml

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/e xtensions/nsextensions.htm

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.

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.

"Nevermind that you're apparently the kind of arrogant asshole who thinks he can determine someone's "true self" from a couple of lines of text"

"I don't know what you've "heard somewhere else", but I'm guessing it's coming from professional web developers like myself who have just about had it with trying to support Opera's broken Javascript/DOM implementation."

"There is no concerted effort to undermine Opera by sending it broken code -- why would there be, when you can break it simply by trying to execute simple scripts that run without a hiccup under everything from IE to Firefox to OmniWeb?"

"is there something about small, underdog platforms that ctually breeds paranoia and delusions of widespread malignant conspiracy amongst their partisans, or do they just somehow attract the mentally unstable?"

Note that the beta version of Opera (v8.0beta) is rumoured to support gmail. Since I don't support gmail, I can't prove it.

"I really feel they need to add a "compatibility" mode or something to make it work with broken sites"

The problem isn't that Opera can't handle badly coded sites. The biggest problem today is that sites block Opera on purpose or use browser detection to send it broken code. Try it yourself, by completely hiding that you are using Opera.

"my pleas to Opera developers have fallen on deaf ears"

...Opera support...

Note that Opera 7.6 (currently in beta/development) has enhanced Gmail support. I just saw there is actually an entire website devoted to Gmail on Opera.

"I had heard before that Opera had good standard Javascript, but MS had extended it for their own use."

"I have to wonder why all these sites crap on Opera but work with FF/Moz. Should they have the same issues as Opera with compatability?"

What I frequently see is that MSIE gest one page, Firefox gets another, and Opera a third, broken one. Even more common is probably scripts detecting Opera and sending it broken stuff, probably because they don't think Opera 7 can handle DOM. In these cases, simply preventing the page from detecting Opera will make it work, as if by magic.

On the other hand, Firefox has problems with lots of sites too, so it is definitely not exclusive to Opera.

"Now try to select the make of the car. Works in FF, doesn't work in Opera. Why?? I really doubt it is sending specific code to Opera at this point. It appears that again Opera just can't handle some JS or something. This happens too often. If FF can handle this why can't Opera?"

"Opera is best browser by far if you ignore the fact that it is the least compatible on the market."

Well, if you're open to a little third-party software, I've made some Proxomitron filters that let you use Gmail with Opera. See my page.

Of course, I wish Opera and Gmail worked straight out, but I'd say support for XMLHttpRequest (the major Gmail blocker) is coming...