Share your views on unobtrusive javascript
Animesh K
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.
Thank you,
Animesh
David Mark
> Hello All:
>
> I came across this topic of UJS (unobtrusive Javascript) recently. I was
> wondering if this method is really worth it.
It isn't a method. It is an umbrella term for various best
practices. Examples:
1. Keep JS out of HTML files to keep content and behavior seperate.
Script pasted into an HTML paged cannot be used with the next page you
write. Paste identical script into the next page and you create a
maintenance problem.
2. Never rely on client side scripting for anything. Write your pages
without JS first. Then use JS to enhance features when appropriate.
Most AJAX sites break this rule.
3. Don't write code forks for specific browsers. Use object and
feature detection instead of sniffing out specific browsers, versions,
etc. You would think this one goes without saying at this point in
time, but many sites break this rule.
> Some people suggested using
> packages like prototype to use UJS. Other suggested code becomes
Why would you need Prototype to follow these rules? At best it
abstracts the task of attaching listeners to elements (to avoid inline
event handlers), but at worst it abstracts browser sniffing. It is
also bloated with lots of AJAX code that most sites will never need.
> 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?
The methods described above have always been good ideas.
> 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.
Animesh K
> 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
>> wondering if this method is really worth it.
>
> It isn't a method. It is an umbrella term for various best
> practices. Examples:
>
> 1. Keep JS out of HTML files to keep content and behavior seperate.
> Script pasted into an HTML paged cannot be used with the next page you
> write. Paste identical script into the next page and you create a
> maintenance problem.
Thanks for the reply David. Actually if one is using a Php setup to
generate the files the JS within each PHP file can be edited by editing
just one file. Think something like blog. You can always republish the
blog with a new template.
It isn't really a maintenance problem in that setup. Though I agree with
you about the separation.
>
> 2. Never rely on client side scripting for anything. Write your pages
> without JS first. Then use JS to enhance features when appropriate.
> Most AJAX sites break this rule.
While some features can be enhancements, some AJAX based sites give
applications which cannot be done otherwise (or so I feel). For example,
spreadsheets, or Picasa Photo share. But I get the general picture and
it is an interesting way to think and implement a website.
>
> 3. Don't write code forks for specific browsers. Use object and
> feature detection instead of sniffing out specific browsers, versions,
> etc. You would think this one goes without saying at this point in
> time, but many sites break this rule.
>
This one I agree with.
>> Some people suggested using
>> packages like prototype to use UJS. Other suggested code becomes
>
> Why would you need Prototype to follow these rules? At best it
> abstracts the task of attaching listeners to elements (to avoid inline
> event handlers), but at worst it abstracts browser sniffing. It is
> also bloated with lots of AJAX code that most sites will never need.
I googled and found a blog where the guy was worried that UJS is
increasing the amount of code written. So he suggested the use of
Prototype. I personally don't like using Prototypes (they are overkill,
usually). It's like having a cannon to kill a rabbit.
>
>> 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?
>
> The methods described above have always been good ideas.
Point noted and agreed.
>
>> 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?
David Mark
> 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
> >> wondering if this method is really worth it.
>
> > It isn't a method. It is an umbrella term for various best
> > practices. Examples:
>
> > 1. Keep JS out of HTML files to keep content and behavior seperate.
> > Script pasted into an HTML paged cannot be used with the next page you
> > write. Paste identical script into the next page and you create a
> > maintenance problem.
>
> Thanks for the reply David. Actually if one is using a Php setup to
> generate the files the JS within each PHP file can be edited by editing
> just one file. Think something like blog. You can always republish the
> blog with a new template.
Yes, but sending the same script with every page is a waste of
bandwidth.
>
> It isn't really a maintenance problem in that setup. Though I agree with
> you about the separation.
>
>
>
> > 2. Never rely on client side scripting for anything. Write your pages
> > without JS first. Then use JS to enhance features when appropriate.
> > Most AJAX sites break this rule.
>
> While some features can be enhancements, some AJAX based sites give
> applications which cannot be done otherwise (or so I feel). For example,
> spreadsheets, or Picasa Photo share. But I get the general picture and
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.
> it is an interesting way to think and implement a website.
>
>
>
> > 3. Don't write code forks for specific browsers. Use object and
> > feature detection instead of sniffing out specific browsers, versions,
> > etc. You would think this one goes without saying at this point in
> > time, but many sites break this rule.
>
> This one I agree with.
>
> >> Some people suggested using
> >> packages like prototype to use UJS. Other suggested code becomes
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.
>
> > Why would you need Prototype to follow these rules? At best it
> > abstracts the task of attaching listeners to elements (to avoid inline
> > event handlers), but at worst it abstracts browser sniffing. It is
> > also bloated with lots of AJAX code that most sites will never need.
>
> I googled and found a blog where the guy was worried that UJS is
> increasing the amount of code written. So he suggested the use of
> Prototype. I personally don't like using Prototypes (they are overkill,
> usually). It's like having a cannon to kill a rabbit.
Prototype and other libs like it are massive overkill, especially when
you consider that most sites do not need AJAX at all. I don't think I
have ever seen Prototype without Scriptaculous (sp?) beside it and
that is something like 150K added and often for nothing more than a
few special effects. That's almost as stupid as using Flash.
>
>
>
> >> 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?
>
> > The methods described above have always been good ideas.
>
> Point noted and agreed.
>
>
>
> >> 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.
d d
> 3. Don't write code forks for specific browsers. Use object and
> feature detection instead of sniffing out specific browsers, versions,
> etc. You would think this one goes without saying at this point in
> time, but many sites break this rule.
I think this one falls into the same camp as the "eval is evil" mantra.
It's just not true that you don't ever need to fork for browsers, just
like using eval isn't always evil (sometimes it is necessary).
The same goes for browser forking. I could list probably a dozen cases
where browser forking is absolutely necessary (and I'm sure you'll ask
me to ;-). Here are a few cases that I've had to fork for:
1. When trying to inject code from an iframe into a parent page, Safari
can sometimes result in that code being inaccessible unless you write
the code to the script element using s.innerHTML. This is a known
workaround and can't be sniffed for in any way other than by browser.
2. Although Safari 1.3 supports the preventDefault and stopPropagation
methods of an event (i.e. it has them and you can call them), they don't
do anything. It's as if they're still stub functions that were never
implemented.
3. EOLAS patent dispute issue. If you're writing an object/embed tag for
Flash into the page on IE6 or IE7, you need to write it from an external
javascript file. OK, you might say, simply do that for all browsers and
those that don't need it won't complain. Yes that's true, but if you
have to wait for the page to be complete before you can add a new JS
file to the DOM, then that's slowing down browsers that don't need
slowing down.
4. Firefox 2.0.0.2 had issues that would make it crash the browser when
using Flash objects. They had to work quickly to release 2.0.0.3 to fix
this.
5. Various other issues with media players and browser combinations.
6. Various issues with Flash external interface not creating the objects
properly which they use to script into Flash, on IE only. If anyone is
considering using external interface instead of getURL or FSCommand,
google the hell out of it first and see if the problems are acceptable.
7. Various browser versions don't properly support transparent Flash.
8. Mac IE has all kinds of issues, too numerous to mention.
9. Various plugins won't work on Opera when it's spoofing itself as
other browsers.
10. Firefox 1.0.x has all kinds of issues and is best avoided (default
to a "classic" version of a page).
I could go on, really I have more, but as you can see, there are many
many reasons why browser sniffing can become essential. I didn't even go
into the different CSS support problems, and several of those points
above are 'various issues' that I haven't even listed out in full.
As I said at the start, the issue is similar to the eval is evil
situation. It's wrong to use eval when not needed, and it's wrong to
sniff for the browser when it's not needed. Simply checking for the
existence of properties (e.g. offsetWidth, clientY) or of certain
methods (getElementById, addEventListener) is often all that's needed,
but in a lot of cases it isn't.
~dd
RobG
> 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.
>>>> wondering if this method is really worth it.
>>> It isn't a method. It is an umbrella term for various best
>>> practices. Examples:
>>> 1. Keep JS out of HTML files to keep content and behavior seperate.
>>> Script pasted into an HTML paged cannot be used with the next page you
>>> write. Paste identical script into the next page and you create a
>>> maintenance problem.
>> Thanks for the reply David. Actually if one is using a Php setup to
>> generate the files the JS within each PHP file can be edited by editing
>> just one file. Think something like blog. You can always republish the
>> blog with a new template.
>
> 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.
[...]
>>> 2. Never rely on client side scripting for anything. Write your pages
>>> without JS first. Then use JS to enhance features when appropriate.
>>> Most AJAX sites break this rule.
>> While some features can be enhancements, some AJAX based sites give
>> applications which cannot be done otherwise (or so I feel). For example,
>> spreadsheets, or Picasa Photo share. But I get the general picture and
>
> You can certainly create a spreadsheet without client side scripting.
I think the point is that it is very hard to make a usable corporate
intranet application without serious scripting. A big issue is that
many intranet developers are Windows developers who think in terms of
Windows applications and write really appalling browser applications.
[...]
>>>> Some people suggested using
>>>> packages like prototype to use UJS. Other suggested code becomes
>
> 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 agree with that. They think that since you've downloaded it once and
it's cached, what's the issue? But many sites use it for very trivial
functions that could have been written in a few lines, yet visitors are
forced to suck down maybe 300kB of libraries to do it.
>>> Why would you need Prototype to follow these rules? At best it
>>> abstracts the task of attaching listeners to elements (to avoid inline
>>> event handlers), but at worst it abstracts browser sniffing. It is
>>> also bloated with lots of AJAX code that most sites will never need.
>> I googled and found a blog where the guy was worried that UJS is
>> increasing the amount of code written. So he suggested the use of
>> Prototype. I personally don't like using Prototypes (they are overkill,
>> usually). It's like having a cannon to kill a rabbit.
>
> Prototype and other libs like it are massive overkill, especially when
> you consider that most sites do not need AJAX at all. I don't think I
> have ever seen Prototype without Scriptaculous (sp?) beside it and
> that is something like 150K added and often for nothing more than a
> few special effects. That's almost as stupid as using Flash.
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.
--
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
David Mark
> David Mark wrote:
> > 3. Don't write code forks for specific browsers. Use object and
> > feature detection instead of sniffing out specific browsers, versions,
> > etc. You would think this one goes without saying at this point in
> > time, but many sites break this rule.
>
> I think this one falls into the same camp as the "eval is evil" mantra.
> It's just not true that you don't ever need to fork for browsers, just
> like using eval isn't always evil (sometimes it is necessary).
>
> The same goes for browser forking. I could list probably a dozen cases
> where browser forking is absolutely necessary (and I'm sure you'll ask
> me to ;-). Here are a few cases that I've had to fork for:
>
> 1. When trying to inject code from an iframe into a parent page, Safari
> can sometimes result in that code being inaccessible unless you write
> the code to the script element using s.innerHTML. This is a known
> workaround and can't be sniffed for in any way other than by browser.
My solution to that would be to not use an iframe.
>
> 2. Although Safari 1.3 supports the preventDefault and stopPropagation
> methods of an event (i.e. it has them and you can call them), they don't
> do anything. It's as if they're still stub functions that were never
> implemented.
Then that version is broken beyond belief and I wouldn't worry about
supporting it at this time. As for preventDefault, what happens if
you return false from the event handler?
>
> 3. EOLAS patent dispute issue. If you're writing an object/embed tag for
> Flash into the page on IE6 or IE7, you need to write it from an external
> javascript file. OK, you might say, simply do that for all browsers and
> those that don't need it won't complain. Yes that's true, but
Yes. For an interactive Flash movie that is true.
if you
> have to wait for the page to be complete before you can add a new JS
> file to the DOM, then that's slowing down browsers that don't need
> slowing down.
You only have to do that when serving XHTML, with HTML you would just
document.write the object tag(s) from an external file. I wouldn't
insert a JS into the DOM, I would insert the object tag(s) when the
DOM is ready. And if Windows IE is all that you are worried about,
use IE conditional comments.
>
> 4. Firefox 2.0.0.2 had issues that would make it crash the browser when
> using Flash objects. They had to work quickly to release 2.0.0.3 to fix
> this.
Flash just isn't worth supporting for this and many other reasons.
>
> 5. Various other issues with media players and browser combinations.
Like what?
>
> 6. Various issues with Flash external interface not creating the objects
> properly which they use to script into Flash, on IE only. If anyone is
> considering using external interface instead of getURL or FSCommand,
> google the hell out of it first and see if the problems are acceptable.
I say don't use Flash at all, but if you must and it must communicate
with your JS, don't use external interface. But if it is an IE-only
problem (the memory leak issue?) that you refer to, IE conditional
comments are the way around it.
>
> 7. Various browser versions don't properly support transparent Flash.
A pattern is emerging here. Don't use transparent Flash.
>
> 8. Mac IE has all kinds of issues, too numerous to mention.
That browser is dead and buried. Anybody still using it will have
problems with virtually every site on the Internet.
>
> 9. Various plugins won't work on Opera when it's spoofing itself as
> other browsers.
Then those plugins are defective. Don't use them.
>
> 10. Firefox 1.0.x has all kinds of issues and is best avoided (default
> to a "classic" version of a page).
Presumably Firefox users are sophisticated enough to upgrade. How old
is that version?
>
> I could go on, really I have more, but as you can see, there are many
> many reasons why browser sniffing can become essential. I didn't even go
> into the different CSS support problems, and several of those points
> above are 'various issues' that I haven't even listed out in full.
>
You don't want to get into CSS hacks either. Those are as bad as
browser sniffing and guaranteed to sacrifice forward compatibility for
backward.
> As I said at the start, the issue is similar to the eval is evil
> situation. It's wrong to use eval when not needed, and it's wrong to
> sniff for the browser when it's not needed. Simply checking for the
> existence of properties (e.g. offsetWidth, clientY) or of certain
> methods (getElementById, addEventListener) is often all that's needed,
> but in a lot of cases it isn't.
>
In short I say:
1. Don't use Flash.
2. Set reasonable limits on what outdated browsers are to be
supported. For instance, is anybody still supporting Netscape 4.7?
3. Validate everything and test thoroughly on as many devices and
browsers as possible.
After that, let the chips fall where they may.
David Mark
[snip]
>
> Not really. Client-applied handlers are often dependent on elements
> having specific IDs or classnames, adding a simple handler
Of course.
directly to
> the HTML can often be less code. The body of functions can
That depends on how many elements are in the structure and how many
pages share the same structure.
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.
It would have to be a pretty poorly conceived script to rely on the
layout to work. I can't think of such an example.
>
> [...]
>
> >>> 2. Never rely on client side scripting for anything. Write your pages
> >>> without JS first. Then use JS to enhance features when appropriate.
> >>> Most AJAX sites break this rule.
> >> While some features can be enhancements, some AJAX based sites give
> >> applications which cannot be done otherwise (or so I feel). For example,
> >> spreadsheets, or Picasa Photo share. But I get the general picture and
>
> > You can certainly create a spreadsheet without client side scripting.
>
> I think the point is that it is very hard to make a usable corporate
> intranet application without serious scripting. A big issue is
Depends on what it has to do.
that
> many intranet developers are Windows developers who think in terms of
> Windows applications and write really appalling browser applications.
I agree that most Intranet (and Internet) developers are incompetent.
Windows developers are notoriously bad as well. Most don't think at
all (they just copy and paste sample code.)
>
> [...]
>
> >>>> Some people suggested using
> >>>> packages like prototype to use UJS. Other suggested code becomes
>
> > 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 agree with that. They think that since you've downloaded it once and
> it's cached, what's the issue? But many sites use it for very trivial
> functions that could have been written in a few lines, yet visitors are
> forced to suck down maybe 300kB of libraries to do it.
Right. And then there are those misleading charts that show the
wonders of http compression. As if that had anything to do with the
issue!
>
> >>> Why would you need Prototype to follow these rules? At best it
> >>> abstracts the task of attaching listeners to elements (to avoid inline
> >>> event handlers), but at worst it abstracts browser sniffing. It is
> >>> also bloated with lots of AJAX code that most sites will never need.
> >> I googled and found a blog where the guy was worried that UJS is
> >> increasing the amount of code written. So he suggested the use of
> >> Prototype. I personally don't like using Prototypes (they are overkill,
> >> usually). It's like having a cannon to kill a rabbit.
>
> > Prototype and other libs like it are massive overkill, especially when
> > you consider that most sites do not need AJAX at all. I don't think I
> > have ever seen Prototype without Scriptaculous (sp?) beside it and
> > that is something like 150K added and often for nothing more than a
> > few special effects. That's almost as stupid as using Flash.
>
> 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.
>
You can! Disable JavaScript.
Richard Cornford
> I came across this topic of UJS (unobtrusive Javascript) recently.
> I was wondering if this method is really worth it.
Design decisions should not start with imposing arbitrary restrictions
on the outcome. You have something to achieve and you have a context in
which to achieve it. It is ludicrous to pre-suppose that any single
approach will always be the best approach to achieve anything and
everything in all contexts. Promises of universal panaceas should be
regarded with extreme suspicion.
> Some people suggested using packages like prototype to use UJS.
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not the
best source of advice on designing systems that use javascript.
> Other suggested code becomes lengthy.
Doesn't Prototype.js avoid becoming lengthy by starting off lengthy?
With the bonus of it's being inefficient itself and encouraging
(sometimes forcing) people to write very inefficient code in order to
use it.
> While others advocate its use saying it leads to a good separation of
> content.
Separating presentation, content and mechanism(s), in the perception of
a project as seen by its developers/maintainers, is an extremely
valuable/rewarding characteristic of well designed system architecture.
"Unobtrusive Javascript" does not inherently provide this in the areas
of an architecture where it has an influence, could not contribute to
proper separation outside the areas of its influence (on the server),
and is a very long way from being the only possible means of achieving
that separation. Just putting the javascript into an external file, of
itself, is only separation in the most superficial sense. And the
browser's view of separation is an irrelevance compared to the
developer/maintainer's perception of it.
> My questions:
>
> 1) Is UJS worth it,
It is worth it if in the context of the whatever it is that is to be
achieved the (any) tangible benefits it brings exceed any negative
impact it may have. It is a design decision, and so tied to the specific
context.
> esp will it be more important in the near future?
There is nothing new here except a label. That label has been attached
to things that have been possible virtually since the dawn of browser
scripting, and have been in common use over that time.
> 2) How to begin learning about UJS.
Learn to design/write cross-browser (as opposed to multi-browser)
scripts and when you have don that you will know everything you need to
know both the implement "unobtrusive scripting" and decided where its
use is appropriate.
> Are there any good tutorial like books to begin?
There are no good javascript books. David Flanagan's "JavaScript: The
Definitive Guide" (ISBN:0-596-10199-6) is the least bad javascript book
(by a very wide margin), but you won't find the techniques for
"unobtrusive javascript" grouped under that label in it.
(Incidentally, one of the tell-tale characteristics of a very bad
javascript book is that the publishes make a sample chapter available
that has no technical content. Something like and introduction to
javascript, or its history. That makes it difficult to state how bad any
particular book is without getting hold of a copy (which is probably
what the publishers want). While if a technical chapter is available
someone who knows what they are doing can look at it and say, for
example (and based upon a particular book I have in mind, no names but
it has "Advanced" in the title) "60% of the factual statements made are
false, the code is inept and promotes approaches that are hard to
maintain, and the design advice varies from the poor to the
catastrophic: it is average for a javascript book".)
> I don't want some theoretical complete reference.
Probably we all started off learning javascript from books. As you learn
more, and try more, one of the things you learn is how bad those books
were. At this point nobody is going to start looking at tutorial books
that attempt to round up the techniques we have been using for years,
without being paid to do so. And that is assuming such books exist.
That leaves you with a problem; the people reading such books are doing
so precisely because they don't know enough to judge them in the wider
context, and the people who could make the judgment are not motivated to
even look at those books.
Richard.
Richard Cornford
> David Mark wrote:
>> 3. Don't write code forks for specific browsers. Use
>> object and feature detection instead of sniffing out
>> specific browsers, versions, etc. You would think this
>> one goes without saying at this point in time, but many
>> sites break this rule.
>
> I think this one falls into the same camp as the "eval is evil"
> mantra.
The people chanting the '"evel is evil" mantra' are always in a position
to point to (hundreds of) thousands of examples where someone seeing
that - eval - exists have then gone on to employ it in a way that is
stupid, pointless, futile or dangerous, and then some of them trying to
defend their use of - eval - in a way that demonstrates that they really
had no idea what they were doing. The idea is that "eval is evil"
because it lets people carry on writing obscure, hard to maintain, and
sometimes absolutely silly code when they could be learning to write
javascript well.
It is an extreme position, and probably more extreme than it needs to
be, but it has also reaped rewards for the world of browser scripting.
Go back 5 years and look at answers posted on comp.lang.javascript and
you will see a constant procession of inexperienced javascript authors
trying to 'help' by posting code littered with unnecessary uses of -
eval -. So many that at the time I thought we could have a competition
for the month's "most futile use of the - eval - function" and have at
least half a dozen good nominations each month.
(A "futile" use of - eval - would be something like:-
var y = eval("document.getElementById('xxx')");
- or (worse):-
var y = eval(document.getElementById('xxx'));
- the second being the winner of "most futile" because whenever its
argument is not a string the - eval - function just returns its
argument, so in that case no code is even evaluated)
That situation has changed and currently you hardly see anyone proposing
anything nearly so stupid. Could it be that 5 years of people taking a
slightly extreme position towards - eval - might have improved the
standard of javascript knowledge and authoring globally?
> It's just not true that you don't ever need to fork
> for browsers,
You have not understood the position. Whether you ever need to fork code
for a particular browser or not is irrelevant. The simple truth is that
there is no technique arable that can accurately identify a browser or
its version. That is just impossible, and your perception of a need to
do so will not make it possible.
The reason for proposing that people not attempt browser sniffing as a
criteria for branching code is that it is an obvious mistake to
predicate a script design upon an ability to do something that is know
to be impossible to achieve. The best that can come out of that are
unreliable scripts that just about function with a tiny handful of known
browsers in their default configurations, and just fall apart when
exposed to anything else (where "anything else" often includes the next
release of one of the "known browsers" (so unreliable code with ongoing
maintenance costs)).
> just like using eval isn't always evil (sometimes it is
> necessary).
The use of the -eval - function is never necessary, it is just that its
use is sometimes expedient (the effort needed to avoid its use in some
circumstances are disproportional (particularly if they involve
implementing the rest of javascript in javascript so you can turn a code
string into something that can be executed)).
> The same goes for browser forking.
But if browser sniffing cannot identify browsers and their versions
accurately seeing a need to do so speaks of a design fault.
> I could list probably a dozen cases where browser forking is
> absolutely necessary (and I'm sure you'll ask me to ;-). Here are a
> few cases that I've had to fork for:
>
> 1. When trying to inject code
Define "inject code".
> from an iframe into a parent page, Safari can sometimes
Ah, and there is the word "sometimes". Being relentlessly mechanically
logical it is not in the nature of computers to "sometimes" do one thing
and then "sometimes" do something else. Given the same state and the
same input computers always produce the same output, they have no
choice. What "sometimes" means is that you have not analysed the
situation to the point of pinning down the cause and effect relationship
that is pertinent to your situation. And without knowledge of that cause
and effect relationship how do you expect to be take seriously when you
assert that it cannot be tested for, or that the need to test for it
cannot be avoided entirely.
> result in that code
Which code? The code that does the injecting?
> being inaccessible
Where is it inaccessible from?
> unless you write the code to the script element using s.innerHTML.
> This is a known workaround and can't be sniffed for in any way
> other than by browser.
Haven't you just outlined the feature test that could be done here? You
try to "insert" the code and then you try to access it, and if you
cannot access it you are in a situation where the inserted code is
inaccessible and can try something else. Though once you have pinned
down the real cause and effect relationship a better test probably could
be devised.
> 2. Although Safari 1.3 supports the preventDefault and
> stopPropagation methods of an event (i.e. it has them and
> you can call them), they don't do anything. It's as if
> they're still stub functions that were never implemented.
And yet a considerable volume of event driven javascript works
absolutely fine on Safari (including old versions). Could it be that you
have elected to do something that is brining you up against this issue
that you could just stop doing?
> 3. EOLAS patent dispute issue. If you're writing an object/embed
> tag for Flash into the page on IE6 or IE7, you need to write it
> from an external javascript file. OK, you might say, simply do
> that for all browsers and those that don't need it won't complain.
And strangely that is what most have elected to do.
> Yes that's true, but if you have to wait for the page to be
> complete before you can add a new JS file to the DOM,
Why add a new script element to the DOM? All you have to do is put a
SCRIPT element at the point where you want the OBJECT element, that
imports a script file that - document.write -s your OBJECT/EMBED mark-up
straight into the context where it is wanted.
> then that's slowing down browsers that don't need slowing down.
If you insist on needlessly jumping through hoops to achieve something
then that will slow things down.
> 4. Firefox 2.0.0.2 had issues that would make it crash the
> browser when using Flash objects. They had to work quickly
> to release 2.0.0.3 to fix this.
Doesn't Firefox automatically check for updates by default?
> 5. Various other issues with media players and browser
> combinations.
The question is not whether issues exist but whether they are issues
that cannot be directly tested for. To mark that determination it is
necessary to be specific about what the issues are and how you go about
provoking them.
> 6. Various issues with Flash external interface not creating the
> objects properly which they use to script into Flash,
<snip>
Are you really asserting that the consequences of "not creating the
objects properly" cannot be feature tested?
Still, the general advice concerning Flash is that if you want to use
Flash at all you should do everything (the whole site) in, and inside,
the Flash, or not use Flash at all.
> 7. Various browser versions don't properly support transparent Flash.
So what?
> 8. Mac IE has all kinds of issues, too numerous to mention.
The question is not whether issues exist but whether they are issues
that cannot be directly tested for. To mark that determination it is
necessary to be specific about what the issues are and how you go about
provoking them.
> 9. Various plugins won't work on Opera when it's spoofing
> itself as other browsers.
You realise that that means that the authors of those plugins have
foolishly followed the browser sniffing line and ended up writing
something unreliable that falls over at its first exposure to anything
outside of its authors limited experience. That hardly represents a
good contribution to an argument in favour of branching javascript based
upon browser sniffing.
> 10. Firefox 1.0.x has all kinds of issues and is best
> avoided (default to a "classic" version of a page).
The question is not whether issues exist but whether they are issues
that cannot be directly tested for. To mark that determination it is
necessary to be specific about what the issues are and how you go about
provoking them.
> I could go on,
Maybe, but you will not get anywhere useful posting vague allegations
without the specifics or the test cases. Experience says that 90% of the
things that people assert require browser sniffing are actually amenable
to feature testing once they have been precisely pinned down, and the
rest can be designed out of the system.
> really I have more, but as you can see, there are many many reasons
> why browser sniffing can become essential.
And, even if true, that would not change the fact that browser sniffing
is not capable of accurately identifying browsers or their versions.
<snip>
> As I said at the start, the issue is similar to the eval is
> evil situation. It's wrong to use eval when not needed, and
> it's wrong to sniff for the browser when it's not needed. Simply
> checking for the existence of properties (e.g. offsetWidth, clientY)
> or of certain methods (getElementById, addEventListener) is often
> all that's needed, but in a lot of cases it isn't.
You have not demonstrated a single case where browser sniffing is
necessary. Vague descriptions are not a demonstration of the
impossibility of feature testing. And even if you had you cannot get
round the fact that you cannot accurately identify browsers or their
versions with browser sniffing. And identifying a need to do the
impossible still would not render it possible.
With browser sniffing you can ask the question but the answer given by
code is not necessarily the correct answer (and there are no technical
grounds for expecting it to be the correct answer).
With properly designed feature detecting code you always get the correct
answer to the questions you ask, but you have to absolutely pin down the
question you should be asking or the correct answer to the question
asked may not suite the decision made with it.
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.
d d
> 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
Peter Michaux
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
Richard Cornford
> 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.
> 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.
d d
> 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.
> 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
RobG
> 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
d d
> 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
Randy Webb
<snip>
> 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)...
Half of Google's site errors on me.
MSN I don't use but if the quality of scripting is the same as MSDN then
it isn't much of a quality to compare against.
AOL won't allow me to use the website (even though I am an AOL customer)
because they can't tell that I am using IE so they tell me my browser
can't handle the page and that I should upgrade it.
Yahoo I don't use so I can't comment on it. The only thing it has going
for it - to me - is Douglas and that is only because I have been reading
his posts for years.
Not much of a level of proficiency to be striving for if your goals are
set at the level of Google, MSN and AOL.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Animesh K
> 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:
>
> 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.
Animesh K
> 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.
David Mark
"Animesh K" <anime...@gmail.com> wrote in message
news:f85s7a$16d4$1...@agate.berkeley.edu...
> 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
Either document.write for HTML or append them to the DOM for XHTML. For the
latter, you don't necessarily need to wait for the onload event, but that is
the simplest way to do it.
> better option? Or will it be better to use "display: none" attributes?
Not for elements generated by script. They would still display when style
sheets are disabled.
>
>
>>
>> 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.
It certainly does. Its users point out how compact their scripts are when
using Prototype or similar libs, without mentioning (or perhaps realizing)
that library itself is something like 70K.
>
>>
> <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/
There is no way I would pay for a book on JavaScript. Despite the fact that
the Web is full of misinformation, at least it is free and you can try the
next search result as soon as you realize you are reading nonsense.
As for that link, I looked at the page and find it troubling that the
navigation "menu" (actually a select element) vanishes when scripting is
disabled. So much for accessibility. It is explained on the page that the
select is populated from link elements (all five of them), which slightly
benefits the author, but severely hinders users. Based on that example, the
reviewers are probably right.
RobG
> 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.
Animesh K
<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
Richard Cornford
> 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.
You are not alone, certainly. Whether the quality of your company is
good or otherwise is another matter.
> I'm sure you'll agree that Google,
Google? You mean that gang of inept, halfwit jellies that are
responsible for turning google groups from a reliable and fast,
searchable archive into a flaky, error-spitting, slow, inconvenient and
troublesome epitome of scripting bad-practice and questionable design?
The people who cannot even count the number of posts someone has made to
a group and come up the same total twice in succession, and produce
totals that differ by more than +/-50%? (If they cannot program counting
on computers what could they ever be expected to get right?)
> Yahoo,
I have not had much to do with Yahoo, but when, in relation to a
question asked on this group, I looked at their YUI code the very first
function I looked at had a gapping hole in its logic. That is not even
the more questionable (and style influenced) areas of host object model
interaction, but the actual logic of the code.
> MSN
Microsoft employs web developers who write IE only code and still come
up with stuff that errors-out (the infamous "parentElement.prentElement
is null or not an object error" that graces nearly every visit to MSDN,
for example), even when using IE in its default configuration. That is,
people who aspire to no more than the easiest browser-scripting task
(scripting the default configuration of a single browser) and still
cannot get it right.
> and AOL
I have zero experience of AOL.
> are some of the largest tech companies in the world
Yes they are.
> and attract some of the finest developer minds to work
> for them.
Do they? On what basis do you make that assertion? And even if they do,
do they then employ those individuals to design/write the code that
makes up their public faces?
> Are they all deluded too?
Take Google, and GMail this time. When GMail was created Opera browser
did not support XML HTTP requests, and GMail used browser sniffing to
tell Opera users that they should find another browser. Opera reacted to
the resulting complaints of their customers by implementing XML HTTP
requests that were (at minimum) compatible with GMail. But it took
someone at Google to go into their code an update the browser sniffing
before Opera could be used with GMail.
Doing that cost Google money. Maybe not much money (particularly as they
don't seem to do much QA testing on their products) but it was more than
no money at all. While the feature detecting approach to XML HTTP
requests (of which plenty of examples considerably pre-date GMail) would
have just worked when presented with a more capable version of Opera.
The people who designed/wrote the original browser sniffing thought they
were doing the right thing, and the people who employed them to do it
thought they were employing the right people to do it. But a bad,
formally baseless, predictably unreliable and technically superseded
design decision had the usual consequences of needlessly costing money
to correct, and then more money to correct the correction when Safari,
Konqueror, IceBrowser, etc, also introduced support for XML HTTP
requests. There is delusion somewhere in an organisation that allows
this to happen, and then allows it to happen again and again.
> 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.
And they are (literally) paying for that mistake.
> Douglas Crockford, please explain
In my experience of working in IT I have never worked for an
organisation that did not include confidentiality clauses in its
employment contracts. Usually along the lines of: 'you will say nothing
specifies about what you do here now and for at least 5 years after you
leave our employment'. Now that might be a peculiarly British thing, or
it may relate to the types of industries I have worked in (financial
services being particularly keen on confidentiality), but I don't think
so.
Asking Douglas what he does at Yahoo is probably utterly pointless as he
is likely obliged not to answer.
> why the YUI library is sniffing for browsers.
They do it because they don't have the skills/experience not to do it,
and because of that they have taken the attitude that they only support
a small set of 'acceptable' browsers/browser configurations.
There is a misconception about the YUI libraries, that they are some
sort of contribution to the public good. They are not; they are the
tools that Yahoo needs to do the job it perceives it needs to do. They
are publicly available and usable as an exercise in cheep but extensive
QA testing. It is a very clever move, but not altruistic in any way.
> Richard says it can't be done, and doesn't need to be.
I said the results of browser sniffing could not accurately identify web
browser or their versions. That is just the logic of the situation; you
cannot distinguish between the character sequence "I am web browser x"
and the character sequence "I am web browser x" by looking at the
characters and their sequence. And there is no requirement that the
character sequence that you are looking at be anything in particular or
even consistent over time. The logic of the situation is undeniable, and
all the 'justifications' that remain for doing it anyway are just a
smokescreen, where the smoke gets in the eyes of the people trying to
make the justification more than those they are trying to justify it to.
> 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.
And if you try you will find you could write considerably more.
> 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,
Of what relevance is a perceived need when the thing that is needed is
impossible?
> and it works on over 99.9% of browsers.
No it doesn't. It is technically baseless and logically faulty in all
browsers, it is just that the actual instances of observed consequences
of those facts is sufficiently low that they are disregarded by many (or
unknown to many).
> 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.
How does a 'traffic log' identify a web browser? Doesn't it use the User
Agent header? Isn't the User Agent header an arbitrary sequence of
characters that are not specified as having any meaning at all (or even
required to be consistent over time)? Isn't the ability to identify a
web browser from its User Agent header precisely the thing that is the
logical impossibility?
Yes the logs may well identify 99.9% of web browsers as being members of
a limited set of well-known and common web browsers, but if the
'identification' cannot accurately discriminate between web browser
because the techniques they use are formally baseless and logically
flawed then what precisely gets "proven" by them.
> 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.
How could you tell? There is an Epimenidies paradox-like situation here;
if someone is attempting to tell you a convincing lie, and you are
convinced, does the lie then become the truth?
> btw, I never heard of NetFront or IceBrowser
No, you spend you time looking at 'traffic logs', where they are listed
as IE 5, 6 or 7 (depending on the version).
> and unless they raise their heads above the
> level of 0.1% browser market share,
You have no evidence that they are not above 0.1% of the browser market.
Your 'traffic logs', because they will list them as IE versions, can
only suggest to you that their market shares do not exceed whatever
figure you have for IE (assuming the logs in question are representative
of market share, which is very improbable).
But on the subject of small market shares, weren't you whining about a
minor (and rapidly updated) version of Firefox that would crash under
some circumstances, and wanting to take action because of it? Is its
share of the market really greater than your 0.1% apparent cut-off?
> I doubt I'll encounter them.
I doubt you would recognise doing so when you do. Both browsers are in
the embedded browser market and feature built into mobile phones,
currently a growth area in web browsing.
> 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.
That's right blame the users, when they are doing nothing wrong (HTTP
1,1 allows them to send any User agent Header they like, and not even
send the same one with each request, so whatever they send it _cannot_
be wrong).
There is nothing the commissioner of a new web site wants to here more
than your justification for eliminating (an unknowable proportion of)
their potential customers at the design stage of a project and in a way
that has no relationship to the business they are in. Especially when it
boils down to "it is the user's fault if you cannot take their money off
them".
> Most web pages are written for the majority of
> browsers and playing with bleeding edge tech,
Bullshit. Most web pages are, and probably will be for a considerable
time to come, ordinary HTML. There are already billions of them.
> you can expect less than ideal results.
I expect that people who don't think about what they are doing,
understand the technologies, or care to do the job well, will act to
turn potentially reliable web projects into flaky half-efforts that do
(probably unrecognised) harm to the business and reputations of the
people who commission then.
> We're writing javascript that meets the vast majority,
> and I don't mean an 80% majority, I mean > 99.9%.
You have already made it clear that you do not understand the factors
that are undermining any clams of yours to be supporting a 'majority' of
any size.
> 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
The fault with that pseudo code is that the userAgen string is a
reflection of the HTTP User Agent header and the HTTP User Agent header
is specified as being no more any arbitrary sequence of characters and
is not even required to be consistent over time. That is, the code is
predicated upon the premise that the User Agent header is a source of
information, when by specification it is no such thing.
You have also demonstrated the precise reason that we are in a situation
where the HTTP User Agent header cannot be specified as being a source
of information (which clearly was the original, and now long abandoned,
purpose of that header). You are attempting to funnel all of the (many)
browsers that you have never heard of into your '"classic" simple page'.
Now the authors of brand new web browser 'Y' have spend two years
implementing a scriptable dynamic web browser that fully supports
ECMAScript, the W3C DOM(s) (HTML and XHTML), CSS, AJAX and stuffed in a
load of IE compatibility, and now you want to give it a "classic" web
page because you don't recognise its name. And so you make the product
of all their hard work look like 1995's Netscape.
Their solution; they don't tell you its name, they tell you it is IE, or
Mozilla, or Opera, or Safari, or whichever common browser best parallels
the capabilities of the browser they have written.
Of course you are none the wiser because you are looking at 'traffic
logs' and seeing only whichever convincing lie they have chosen to tell
you.
> Sniffing for the two most popular spoofers
What criteria can determine the "most popular spoofers"? Might there not
be at least one more popular spoofer that is spoofing so well that you
have not been able to distinguish it form whatever it is spoofing?
> gets them identified first, thereby disregarding their spoofery.
> Searching for Flock (a variant of Firefox) means it doesn't get seen
> as firefox.
If it is a variant of Firefox why not treated it as Firefox? What about
all those over (20-odd) Mozilla/Gecko variants?
> 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).
And also catches the vast majority of all of those little embedded
browsers that you are blind to.
> Then comes netscape, so it doesn't get identified as mozilla.
And there go another crowd of embedded browsers.
> Finally a mozilla check last (because so many of the browsers above
> also have mozilla
> in their useragent).
Do you understand why they all have 'mozilla' in their User Agent
headers? The irony of this whole thing is that it was Microsoft that
introduced spoofing, and did so in order that foolish browser detection
would not result in its new IE browsers getting the "classic" pages back
in the days when Netscape was the big player. And then it was because
browser spoofing was already endemic that in 1998 it was impossible for
the HTTP 1.1 specification to require anything specific of the contents
of the User Agent header.
> I know you're going to say that using the useragent
> itself isn't a reliable way of trying to determine
> the browser.
If I did I would only be repeating a fact that is clear from the HTTP
1.1 specification and evident in the real world.
> All I can say (again) is that it works for me (and Google,
> and Yahoo, and MSN and AOL)...
And all I can say again is that it doesn't work for you, or Google, or
Yahoo or MSN or AOL. It does not work for anyone, as it is logically
impossible to use an arbitrary sequence of characters do discriminate
between sources of arbitrary sequences of characters. You cannot
accurately identify a web browser from its User Agent header, logically,
there is no formal basis for ever trying, some are known to use User
Agent headers that are (deliberately) indistinguishable from others, and
almost all User Agent headers are user configurable anyway.
Richard.
Peter Michaux
wrote:
> > Yahoo,
>
> I have not had much to do with Yahoo, but when, in relation to a
> question asked on this group, I looked at their YUI code the very first
> function I looked at had a gapping hole in its logic. That is not even
> the more questionable (and style influenced) areas of host object model
> interaction, but the actual logic of the code.
What particular code in YUI was that? What was the problem?
Thanks,
Peter
Randy Webb
> d d wrote:
<snip>
>> and AOL
>
> I have zero experience of AOL.
AOL uses an embedded IE. About 2 weeks ago the AOL Software told me that
I needed to upgrade my browser as it was incompatible with the AOL
Website. The "browser" I was using was AOL's software itself. I think
you can figure out what that says about the "quality" of AOL, it's
software, and it's ability to identify a browser.
Thomas 'PointedEars' Lahn
> On Jul 21, 1:32 am, d d <dd_no_s...@please.net> wrote:
>> 8. Mac IE has all kinds of issues, too numerous to mention.
>
> That browser is dead and buried. Anybody still using it will have
> problems with virtually every site on the Internet.
That is the official statement I believed too before, but I wouldn't be
so sure about that now. Last time I checked, IE 5 on Mac topped even IE
6 on Windows when it came to standards conforming rendering -- the
layout engine is another one (Tasman, not Trident).
Recently, our company has been "asked" to provide a tableless Plone site
(formatted with CSS) with Mac IE 5 compatibility because some of the
customer's VIPs still use it. It was an about 5-hour-PITA to
restructure the templates (IE 5 Mac does not support @media rules that
Plone uses by default for its stylesheets) but now it looks good and --
more important -- it is still accessible.
Regards,
PointedEars
David Mark
wrote:
> David Mark wrote:
> > On Jul 21, 1:32 am, d d <dd_no_s...@please.net> wrote:
> >> 8. Mac IE has all kinds of issues, too numerous to mention.
>
> > That browser is dead and buried. Anybody still using it will have
> > problems with virtually every site on the Internet.
>
> That is the official statement I believed too before, but I wouldn't be
> so sure about that now. Last time I checked, IE 5 on Mac topped even IE
> 6 on Windows when it came to standards conforming rendering -- the
IE6 has lots of silly rendering problems, as does IE5 for the Mac.
There are lots of published hacks to get around the Mac version's
problems, but none are a good idea, especially since it doesn't do
conditional comments.
> layout engine is another one (Tasman, not Trident).
>
> Recently, our company has been "asked" to provide a tableless Plone site
> (formatted with CSS) with Mac IE 5 compatibility because some of the
> customer's VIPs still use it. It was an
They must be out of their minds.
about 5-hour-PITA to
> restructure the templates (IE 5 Mac does not support @media rules that
> Plone uses by default for its stylesheets) but now it looks good and --
> more important -- it is still accessible.
Certainly you can create styles without hacks that work flawlessly for
IE5 Mac, just as you can for NS4, but it usually isn't worth the
effort. There are a lot of DOM scripting issues with it as well. I
used to test all the way back to IE4 on the Mac, but lately have
decided to forget about both of them. From my experience, I know that
simpler pages will work fine, but complicated applications will have
issues. I do try to avoid things that I know will cause breakdowns.