«

Richard Cornford wrote:
> So it is usually an inability to pin-down the question that should be
> being asked that leads people to promote the notion of browser sniffing,
> regardless of the fact that it is known to be an impossible task to do
> accurately.
> Richard.

Well, your reply basically boils down to two major arguments. One is
that there's no need to sniff (and I accept that I didn't add any proof
that there is a reason). The other argument being that it's impossible
to sniff accurately.

Just because I didn't go into great detail about the problems, doesn't
mean they aren't real. I didn't want to write 250 lines that nobody
would read. I'll just say this. Try going to either the Firefox or
Safari Bugzilla DB's and check out the numerous problems that are
specific to a particular version of the browser, and/or a specific
version of a plugin. Whether you or I consider Flash to be something
that shouldn't be used, that doesn't mean it won't be. I don't get
involved in any of the site design decisions, but I have to live with
them. If I know that a specific version of a plugin will crash a
specific version of a browser if used in a certain way, then it would be
irresponsible to NOT sniff for those two conditions and take action to
avoid the logged browser crash.

Regarding the point that it's impossible to sniff accurately. Well
that's just not true. You can sniff very accurately for default
browsers, and the default user agent string is the vast majority. OK you
can make Netscape 8 pretend to be either IE or Firefox, you can make
Opera and Safari pretend to be just about anything. If those spoofed
user agent strings cause a mis-sniff, then it's their own fault. If you
dress up as a woman and do it very well, you shouldn't be surprised if
guys hit on you If I'm a user that's sufficiently advanced enough
to change my user agent string then I know what might happen. For all
those default browsers, not only is it possible, it's very easy.
Besides, it's also very easy to detect browsers that are spoofing. All
my sniffer code doesn't get fooled. Opera and Safari and NS8 are all
detected properly, regardless of what spoof mode they're in.

~dd

On Jul 20, 3:38 pm, Animesh K <animesh1...@gmail.com> wrote:
> Hello All:
>
> I came across this topic of UJS (unobtrusive Javascript) recently. I was
> wondering if this method is really worth it. Some people suggested using
> packages like prototype to use UJS. Other suggested code becomes
> lengthy. While others advocate its use saying it leads to a good
> separation of content.
>
> My questions:
>
> 1) Is UJS worth it, esp will it be more important in the near future?
> 2) How to begin learning about UJS. Are there any good tutorial like
> books to begin? I don't want some theoretical complete reference.

There is still a major problem with implementing UJS: the
window.onload problem. I investigated this in depth and wrote
something long about it too.

<URL: http://peter.michaux.ca/article/553>

Peter

d d wrote:
> Richard Cornford wrote:
>> So it is usually an inability to pin-down the question that
>> should be being asked that leads people to promote the notion
>> of browser sniffing, regardless of the fact that it is known
>> to be an impossible task to do accurately.
<snip>
> Well, your reply basically boils down to two major arguments.
> One is that there's no need to sniff (and I accept that I
> didn't add any proof that there is a reason). The other
> argument being that it's impossible to sniff accurately.

You weren't reading very accurately. I said that as it is impossible to
accurately determine the browser or its version and perceived need to do
so is an irrelevance.

> Just because I didn't go into great detail about the problems,
> doesn't mean they aren't real.

But it does man that you cannot be shown how you could avid your
perception of a need to browser sniff by learning how you might identify
the tests that will give you the answers you really need.

> I didn't want to write 250 lines that nobody would read.

250 lines of text would be pointless. 250 lines of code that
demonstrated your perception of a need would be something else. It might
make your point for you, or it might be the starting point of your
learning how the rest of us are happily getting by without browser
sniffing.

> I'll just say this. Try going to either the Firefox or Safari Bugzilla
> DB's and check out the numerous problems
> that are specific to a particular version of the browser,
> and/or a specific version of a plugin. Whether you or I
> consider Flash to be something that shouldn't be used, that
> doesn't mean it won't be. I don't get involved in any of the
> site design decisions, but I have to live with them. If I know
> that a specific version of a plugin will crash a specific
> version of a browser if used in a certain way, then it would be
> irresponsible to NOT sniff for those two conditions and take
> action to avoid the logged browser crash.

So rather than narrowing down to the specifics of a particular case and
letting us test the proposition that your examples cannot be tested for
you are becoming even more vague and pointing at the entire bug
databases of two browsers.

Browsers have bugs. They always have and the always will. Yet the
Internet exists, mostly works, and people make a living writing code for
it that does not get involved with browser sniffing.

> Regarding the point that it's impossible to sniff accurately.
> Well that's just not true.

Your saying that something is not true does not make it so. There are
only two browser-sniffing techniques: UA string testing and object
inference. Both have flaws that render them incapable of accurately
discriminating web browsers and their versions.

> You can sniff very accurately for default browsers,

What is "the default browser"?

> and the default user agent string is the vast majority.

Is "the vast majority" of what?

> OK you can make Netscape 8 pretend to be either IE or
> Firefox, you can make Opera and Safari pretend to be
> just about anything.

You can make IE pretend to be just about anything as well, but the real
problems come with the many browsers that pretend to be one of the major
browsers (usually IE) by default.

> If those spoofed user agent strings cause a mis-sniff,

There you go. It is an unreliable technique, and nothing can be done to
stop that.

> then it's their own fault.

No it is not. The HTTP specification makes it very clear that the User
Agent (and so the browser's userAgent string) is not a source of
information; that is it essentially an arbitrary sequence of that
doesn't even have to be the same for any two consecutive requests.
Predicating a strategy on treating something that is not a source of
information as if it was a source of information is an obvious folly,
and if you do that the consequences are your fault. The User Agents are
conforming with the pertinent specification whatever they as their User
Agent headers.

> If you dress up as a woman and do it very well,
> you shouldn't be surprised if guys hit on you

You have not understood why it is normal for web browser's UA strings to
spoof other browser's UA strings.

> If I'm a user that's sufficiently advanced enough to change my user
> agent string then I know what might
> happen.

Don't blame the user for the consequences of your mistakes. Your
'sufficiently advanced user' is quite capable of understanding that the
line they must not cross is violating HTTP. If they do that they should
have every expectation of things not working properly, but if they don't
then it is some other fool's fault when things go wrong.

> For all those default browsers, not only is it possible,
> it's very easy.

All you re saying is that you can distinguish a default configuration of
one common browser from a default configuration of another common
browser. And you can do that, but as you cannot know that what appears
to be a default configuration of a common browser actually is a default
configuration of that browser the ability to distinguish between them is
not the ability to identify them. It is accurately identifying the
browser and/or its version that is impossible.

> Besides, it's also very easy to detect browsers that are
> spoofing.

Is it? how would you discriminate NetFront or IceBrowsr from IE?

> All my sniffer code doesn't get fooled.

I know where I would be placing my money.

> Opera and Safari and NS8 are all detected properly, regardless
> of what spoof mode they're in.

You are deluded.

Richard.

Richard Cornford wrote:
> You weren't reading very accurately. I said that as it is impossible to
> accurately determine the browser or its version and perceived need to do
> so is an irrelevance.
snip
> You are deluded.

OK, I give up.

At least I'm in good company though. I'm sure you'll agree that Google,
Yahoo, MSN and AOL are some of the largest tech companies in the world
and attract some of the finest developer minds to work for them. Are
they all deluded too? They're also foolishly sniffing for browsers via
the useragent, even though it's impossible to accurately determine the
browser, and it's pointless trying to do so.

Douglas Crockford, please explain why the YUI library is sniffing for
browsers. Richard says it can't be done, and doesn't need to be.

I believe you Richard, that the code you write can be done without
sniffing for browsers. I've written lots of things that didn't need it.
In my world though (and clearly in the world occupied by the code from
Google, Yahoo, MSN and AOL) there is a need for it, and it works on over
99.9% of browsers. It's a fact that's proven by the traffic logs from
web servers that 99.9% of visiting browsers are identified to be the
main browsers mentioned below. Of all the logs I've looked at, you don't
even see Opera or Safari in spoof mode get listed. People simply aren't
doing it.

btw, I never heard of NetFront or IceBrowser and unless they raise their
heads above the level of 0.1% browser market share, I doubt I'll
encounter them. If you use an obscure browser, or one with a spoofed
useragent, then what happens to you as you browse the web is your own
fault. Most web pages are written for the majority of browsers and
playing with bleeding edge tech, you can expect less than ideal results.
We're writing javascript that meets the vast majority, and I don't
mean an 80% majority, I mean > 99.9%.

What exactly is wrong with this pseudo code ?

if useragent has opera then browser is opera
else if useragent has safari then browser is safari
else if useragent has flock then browser is flock
else if useragent has firefox then browser is firefox
else if useragent has ie then browser is ie
else if useragent has netscape then browser is netscape
else if useragent has mozilla then browser is mozilla
else browser is unknown and gets a "classic" simple page

Sniffing for the two most popular spoofers gets them identified first,
thereby disregarding their spoofery. Searching for Flock (a variant of
Firefox) means it doesn't get seen as firefox. Searching for Firefox
before netscape means firefox doesn't get identified as netscape. Then
comes IE (which also catches netscape 8 in IE mode, but that's what we
want, because it is running an IE instance). Then comes netscape, so it
doesn't get identified as mozilla. Finally a mozilla check last (because
so many of the browsers above also have mozilla in their useragent).

I know you're going to say that using the useragent itself isn't a
reliable way of trying to determine the browser. All I can say (again)
is that it works for me (and Google, and Yahoo, and MSN and AOL)...

~dd

On Jul 23, 5:06 pm, d d <dd_no_s...@please.net> wrote:
> Richard Cornford wrote:
> > You weren't reading very accurately. I said that as it is impossible to
> > accurately determine the browser or its version and perceived need to do
> > so is an irrelevance.
> snip
> > You are deluded.
>
> OK, I give up.
>
> At least I'm in good company though. I'm sure you'll agree that Google,
> Yahoo, MSN and AOL are some of the largest tech companies in the world
> and attract some of the finest developer minds to work for them. Are
> they all deluded too?

Yes. eBay recently told me that I was using Safari 1.0 and to update
it to the latest version - I was actually using Safari 3.0. I let
them know and within a day or so they had it fixed, but I wonder how
many users saw that message and didn't know what to do about it? Or
blamed Safari? 3.0 had been out for about a month at least.


> They're also foolishly sniffing for browsers via
> the useragent, even though it's impossible to accurately determine the
> browser, and it's pointless trying to do so.

Yes, see above. I recently tried to use Google Groups with Safari
1.3, it fails in "tree view". Cleary either their sniffing fails to
identify it or they don't bother to respond if they do. Either way,
my opinion of Google developers is not very high in regard to code
quality as evidenced by their javascript skills.


[...]
> I believe you Richard, that the code you write can be done without
> sniffing for browsers. I've written lots of things that didn't need it.
> In my world though (and clearly in the world occupied by the code from
> Google, Yahoo, MSN and AOL) there is a need for it, and it works on over
> 99.9% of browsers. It's a fact that's proven by the traffic logs from
> web servers that 99.9% of visiting browsers are identified to be the
> main browsers mentioned below.

That is not proof. You will likely never know from such logs whether
they correctly identified the browser or not. All you can do is some
kind of test of UA string to feature set and see if matches what you
think it should. If it doesn't, does that mean the browser is
spoofing or you messed up the UA string/feature set match?


> Of all the logs I've looked at, you don't
> even see Opera or Safari in spoof mode get listed. People simply aren't
> doing it.
>
> btw, I never heard of NetFront or IceBrowser and unless they raise their
> heads above the level of 0.1% browser market share, I doubt I'll
> encounter them.

There are about to be billions of mobile devices running web
browsers. Of those that identify as a "major" browser, how many will
actually have all the features of their bigger cousin? What is the
leading mobile browser? How many need to be sniffed out to get 99.9%
of mobile users?

Enough for now, I don't want to sound like I'm getting on your case,
I'm just in a bit of a rush!

Cheers,


--
Rob

RobG wrote:
> Yes. eBay recently told me that I was using Safari 1.0 and to update
> it to the latest version - I was actually using Safari 3.0. I let
> them know and within a day or so they had it fixed, but I wonder how
> many users saw that message and didn't know what to do about it? Or
> blamed Safari? 3.0 had been out for about a month at least.

Well, ebay has let the side down there. I'm not surprised though. If you
look at the useragent for Safari 1.3 it identifies itself with a real
number like Safari/312.6 (that's what my 1.3 shows). Whereas my 3.0
shows itself as Safari/522.11.3. I bet ebay's parsing read that as 11.3.

> Yes, see above. I recently tried to use Google Groups with Safari
> 1.3, it fails in "tree view". Cleary either their sniffing fails to
> identify it or they don't bother to respond if they do. Either way,
> my opinion of Google developers is not very high in regard to code
> quality as evidenced by their javascript skills.

Yeah I really regretted adding Google to my list of high profile sites
that sniff. They suck big time. I can't view their google groups without
getting numerous errors if I go there with IE. They really need a course
on defensive programming.

> Enough for now, I don't want to sound like I'm getting on your case,
> I'm just in a bit of a rush!

I hope I haven't given the impression that my code is littered with
browser logic like if(IE)attachEvent(bla);else addEventListener(bla); I
use feature detection in all places possible. I also avoid eval as much
as possible. However, when I do know of cases where taking a particular
feature path must be avoided for a specific browser (despite the fact
that it will pass a feature test), then I'll use my useragent-sniffed
booleans to let me avoid that.

~dd

David Mark wrote:
> On Jul 20, 10:28 pm, Animesh K <animesh1...@gmail.com> wrote:
>> David Mark wrote:
>>> On Jul 20, 6:38 pm, Animesh K <animesh1...@gmail.com> wrote:
<snip>
>
> Yes, but sending the same script with every page is a waste of
> bandwidth.
>

Agreed.

>
> You can certainly create a spreadsheet without client side scripting.
> Same for a photo-sharing application. And the point is that many AJAX
> sites display script-only interfaces even with scripting disabled (eg
> arrows for dropdown menus that never appear.) That's just stupid.
>

That's an interesting thought. So how about showing "all the script
related buttons" with document.onload handler? Will document write be a
better option? Or will it be better to use "display: none" attributes?


>
> Prototype users will suggest you use Prototype for everything. They
> are married to it, so it is in their interest to keep it in fashion.

I know and it sucks.

>
<snip>
>>
>>
>>
>>>> 2) How to begin learning about UJS. Are there any good tutorial like
>>>> books to begin? I don't want some theoretical complete reference.
>>> Google it.
>> Any book?
>
> Not that I know of.
>

I googled and came across one. But reviewers say that his codes don't
work properly.

http://onlinetools.org/articles/unobtrusivejavascript/

RobG wrote:
> David Mark wrote:
>> On Jul 20, 10:28 pm, Animesh K <animesh1...@gmail.com> wrote:
>>> David Mark wrote:
>>>> On Jul 20, 6:38 pm, Animesh K <animesh1...@gmail.com> wrote:
>>>>> Hello All:
>>>>> I came across this topic of UJS (unobtrusive Javascript) recently.
>>>>> I was
>
> I hate the term "UJS", it's a complete misnomer. What is really meant
> is using javascript to add handlers at the client which, as you said
> elsewhere, it is hardly any different to doing it at the server before
> sending it.
>

Can you explain the viewpoint more? The misnomer part.

>
<snip>
>>
>> Yes, but sending the same script with every page is a waste of
>> bandwidth.
>
> Not really. Client-applied handlers are often dependent on elements
> having specific IDs or classnames, adding a simple handler directly to
> the HTML can often be less code. The body of functions can usually be
> delivered in a single js file that is cached.
>
> Client-applied handlers are also often strictly tied to a certain
> document structure - it is very common to see functions that go up and
> down the DOM looking for a specific structure to do stuff. From that
> perspective, the idea of separating script from layout is completely
> contradicted.
>


And explain this above point more as well. I am a bit lost on the
"contradicted" part.

<snip>
>
> I love Flash - I use FlashBlock to get rid of all Flash content I
> wish I could just as effectively get rid of annoying scriptaculous effects.
>
>


Use Noscript or Adblock in firefox to filter certain scripts that you
don't like.

Animesh K wrote:
> RobG wrote:
>> David Mark wrote:
>>> On Jul 20, 10:28 pm, Animesh K <animesh1...@gmail.com> wrote:
>>>> David Mark wrote:
>>>>> On Jul 20, 6:38 pm, Animesh K <animesh1...@gmail.com> wrote:
>>>>>> Hello All:
>>>>>> I came across this topic of UJS (unobtrusive Javascript) recently.
>>>>>> I was
>>
>> I hate the term "UJS", it's a complete misnomer. What is really meant
>> is using javascript to add handlers at the client which, as you said
>> elsewhere, it is hardly any different to doing it at the server before
>> sending it.
>>
>
> Can you explain the viewpoint more? The misnomer part.

Properly applied handlers only add a function call to the value of an
attribute in the HTML. So-called unobtrusive scripts usually rely on
elements having an ID or class attribute that otherwise would not have
been needed, so one bit of markup is replaced by another.


>>
> <snip>
>>>
>>> Yes, but sending the same script with every page is a waste of
>>> bandwidth.
>>
>> Not really. Client-applied handlers are often dependent on elements
>> having specific IDs or classnames, adding a simple handler directly to
>> the HTML can often be less code. The body of functions can usually be
>> delivered in a single js file that is cached.
>>
>> Client-applied handlers are also often strictly tied to a certain
>> document structure - it is very common to see functions that go up and
>> down the DOM looking for a specific structure to do stuff. From that
>> perspective, the idea of separating script from layout is completely
>> contradicted.
>>
>
>
> And explain this above point more as well. I am a bit lost on the
> "contradicted" part.

The contradiction comes when a handler is dependent on the document
structure. You often see scripts that apply effects (e.g. hiding,
showing, sliding up or down) that go looking for the first div parent or
first ul parent or such. In those cases, you must ensure that the
handler is on the right element and within the right structure,
otherwise it all falls apart.

Add to that the requirement that to identify the right element to start
the up/down/next search also requires an appropriate ID or class on that
element and you've got to ask yourself: why not just apply the handler
directly?

I'm not criticising the technique as such, only the claim that applying
handlers dynamically at the client rather than inline on the server
abstracts markup from code. Separate physically, yes. Abstract, no -
the handlers still need to end up on the right elements.


> <snip>
>>
>> I love Flash - I use FlashBlock to get rid of all Flash content I
>> wish I could just as effectively get rid of annoying scriptaculous
>> effects.
>>
>>
>
>
> Use Noscript or Adblock in firefox to filter certain scripts that you
> don't like.

I already use Adblock, but you can't block scripts willy-nilly - much
better to turn off script support completely.


--
Rob
"We shall not cease from exploration, and the end of all our
exploring will be to arrive where we started and know the
place for the first time." -- T. S. Eliot

RobG wrote:
<snip>
>>>
>>
>> Can you explain the viewpoint more? The misnomer part.
>
> Properly applied handlers only add a function call to the value of an
> attribute in the HTML. So-called unobtrusive scripts usually rely on
> elements having an ID or class attribute that otherwise would not have
> been needed, so one bit of markup is replaced by another.
>

That's a very good point. Thank you.

>
>>>
<snip>
>
> The contradiction comes when a handler is dependent on the document
> structure. You often see scripts that apply effects (e.g. hiding,
> showing, sliding up or down) that go looking for the first div parent or
> first ul parent or such. In those cases, you must ensure that the
> handler is on the right element and within the right structure,
> otherwise it all falls apart.
>
> Add to that the requirement that to identify the right element to start
> the up/down/next search also requires an appropriate ID or class on that
> element and you've got to ask yourself: why not just apply the handler
> directly?
>

Ditto, nice point here too.

> I'm not criticising the technique as such, only the claim that applying
> handlers dynamically at the client rather than inline on the server
> abstracts markup from code. Separate physically, yes. Abstract, no -
> the handlers still need to end up on the right elements.
>

Agreed.

>
> I already use Adblock, but you can't block scripts willy-nilly - much
> better to turn off script support completely.
>
>


I meant adblock for flash and noscript for javascript. There are
websites where JS is handy.

Best,
A