Slashdot Mirror
JavaScript: The Good Parts
Anita Kuno writes "JavaScript: The Good Parts is about the good parts of JavaScript and how to use them. This book takes a realistic look at the strengths and weaknesses of JavaScript and tells you how to use it to its best advantage. The code samples deal with the language and its merits — creating web pages is not discussed. How to understand the language, to execute the operations you want, is the focus of the book, not how to make rounded corners. The author, Douglas Crockford says, 'My microwave oven has tons of features, but the only ones I use are cook and the clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding and sticking with the good parts.'" Keep reading for the rest of Anita's review.
JavaScript: The Good Parts
author
Douglas Crockford
pages
153 pages includes the index
publisher
O'Reilly Media Inc.
rating
8
reviewer
Anita Kuno
ISBN
9780596517748
summary
The Good Parts of JavaScript.
Intended for those familiar with object-oriented programming, who understand inheritance, functions, variables, arrays, and enumeration, it identifies its audience as programmers new to JavaScript as well as those with some familiarity who wish to improve their interaction with the language. People who want to have a good relationship with JavaScript and those who wish to improve the relationship they have will find it most useful. There are lots of books and tutorials that deal with JavaScript but this approaches the language from the point of view of a survivalist.
I expect this little field guide to retain its usefulness for many years. As Brendan Eich, the creator of JavaScript, states on his blog, "What was needed was a convincing proof of concept, AKA a demo. That, I delivered, and in too-short order it was a fait accompli." JavaScript was a mock up that got a stamp of approval. His first draft became the language. I find that rather shocking. But Brendan alludes in his blog to the idea that there were many other considerations in play at the time, so the story-boarded code got the go-ahead. Crockford's book fills a niche for users explaining how to code with JavaScript and be a better programmer because of the experience.
Douglas Crockford writes in a relaxed, conversational style establishing a connection with the reader that continues through the book's contents (all 100 pages) and the five appendixes ( 50 pages total for the appendixes). I read the book in an evening-away-from-the-screen kind of mood and only followed one piece of code as outlined in the book. The book is approachable with a cursory acknowledgment of the code and it is also informative with a detailed examination of said code.
Special mention goes to Chapter 7: Regular Expressions. There are some topics which are so complex that other authors either skip over them, or use so much jargon as to render the effort useless. Douglas Crockford gives a guided tour of a regular expression designed to parse a url and it is intelligible and informative. He identifies the shortcut he uses in his regular expression code and acknowledges the risks he accepts by using it. I found his twelve and a half pages on regular expressions gave me a reasonable introduction to the subject.
He uses quotes from Shakespeare as an icebreaker for each chapter and appendix. The book contains code snippets and some recipes for adding your own functions and methods which Douglas feels should have been in the language and aren't. This I find to be a very interesting feature of the book. Like the staples for a good kitchen: ganache, bechamel, mirepoix; Crockford identifies the staples of a scripting language and gives the reader the recipes for the features that JavaScript doesn't have; .integer, .trim, and .curry (which allows the creation of a new function by combining a function and an argument).
One of the things that is missing from this book is the DOM (the Document Object Model). I couldn't be happier about that. Every other reference I have approached mashes JavaScript to the DOM so fast that as a newcomer to the language I thought that aspects of the DOM were properties of JavaScript. Douglas Crockford has an episode on Yahoo! Video talking about that very topic and it was a breath of fresh air for deciphering JavaScript. By the way, the amount of characters, in the above sentences about the DOM, is about the quantity of characters dedicated to the topic in JavaScript: The Good Parts. For me, this is a plus.
The author states that the necessary equipment for writing JavaScript programs is a browser and a text editor. Since both are readily available in a variety of flavors and styles, I am fairly confident that every programmer wanting to learn about the good parts of JavaScript can do so.
My previous attempts to learn JavaScript had not gone well and I didn't have an understanding about why the topic was proving so confusing for me. Knowing the history of the language and the environment at its birth, I now have a better appreciation for the abilities of this language as well as a higher level of acceptance for its quirks. I understand now why I should use "var" when assigning a variable, and also why it is a good idea to conclude the line containing "return" that is followed by a block, with the left curly brace that begins the block. I didn't have the patience to accept these idiosyncrasies before and now that I know the history of JavaScript, I can see why it is a good idea to use Crockford's suggestions as a consistent coding style.
Charles Jolley suggested that I read JavaScript: The Good Parts as a basis for learning JavaScript. His tag line was: "I read it in three hours." Now, that may be an inappropriate reason for reading a book, but after spending hours and hours with various media trying to understand JavaScript, three hours seemed like a reasonable investment of time. (It took me a little longer reading at home with the occasional interruption but I still did my first pass in an evening.) The author wrote the book as an enumerable (the recipient of an action one or more times) with each reading revealing layers of understanding.
In the appendixes, there is an appendix entitled "Awful Parts" and one entitled "Bad Parts". Global variables head the list in "Awful Parts". There are discussions throughout the book about why to avoid JavaScript's default to global variables and how to do this in your coding style. The explanation, of why global variables should be avoided in JavaScript, is detailed in the "Awful Parts" appendix. Also making an appearance in "Awful Parts": scope, semicolon insertion, and reserved words. The "Bad Parts" appendix includes: == (double equal sign) which can be evaluated unpredictably depending on the circumstances, "with" which can also have unpredictable results, and "eval" which passes a string to the JavaScript compiler and executes the result. "eval" slows the result when compilation isn't required and can also compromise the security of your application. But what about its use in JSON you ask? Crockford suggests using the JSON.parse method instead of "eval". The file which creates the JSON object with the parse method can be found here. If this is of interest to you, I suggest you check the link and access the book to hear it from Crockford directly.
I find Douglas Crockford's perspective on JavaScript in JavaScript: The Good Parts to be useful in my own relationship with JavaScript. His style is accessible and intelligent.
You can purchase JavaScript: The Good Parts from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I expect this little field guide to retain its usefulness for many years. As Brendan Eich, the creator of JavaScript, states on his blog, "What was needed was a convincing proof of concept, AKA a demo. That, I delivered, and in too-short order it was a fait accompli." JavaScript was a mock up that got a stamp of approval. His first draft became the language. I find that rather shocking. But Brendan alludes in his blog to the idea that there were many other considerations in play at the time, so the story-boarded code got the go-ahead. Crockford's book fills a niche for users explaining how to code with JavaScript and be a better programmer because of the experience.
Douglas Crockford writes in a relaxed, conversational style establishing a connection with the reader that continues through the book's contents (all 100 pages) and the five appendixes ( 50 pages total for the appendixes). I read the book in an evening-away-from-the-screen kind of mood and only followed one piece of code as outlined in the book. The book is approachable with a cursory acknowledgment of the code and it is also informative with a detailed examination of said code.
Special mention goes to Chapter 7: Regular Expressions. There are some topics which are so complex that other authors either skip over them, or use so much jargon as to render the effort useless. Douglas Crockford gives a guided tour of a regular expression designed to parse a url and it is intelligible and informative. He identifies the shortcut he uses in his regular expression code and acknowledges the risks he accepts by using it. I found his twelve and a half pages on regular expressions gave me a reasonable introduction to the subject.
He uses quotes from Shakespeare as an icebreaker for each chapter and appendix. The book contains code snippets and some recipes for adding your own functions and methods which Douglas feels should have been in the language and aren't. This I find to be a very interesting feature of the book. Like the staples for a good kitchen: ganache, bechamel, mirepoix; Crockford identifies the staples of a scripting language and gives the reader the recipes for the features that JavaScript doesn't have; .integer, .trim, and .curry (which allows the creation of a new function by combining a function and an argument).
One of the things that is missing from this book is the DOM (the Document Object Model). I couldn't be happier about that. Every other reference I have approached mashes JavaScript to the DOM so fast that as a newcomer to the language I thought that aspects of the DOM were properties of JavaScript. Douglas Crockford has an episode on Yahoo! Video talking about that very topic and it was a breath of fresh air for deciphering JavaScript. By the way, the amount of characters, in the above sentences about the DOM, is about the quantity of characters dedicated to the topic in JavaScript: The Good Parts. For me, this is a plus.
The author states that the necessary equipment for writing JavaScript programs is a browser and a text editor. Since both are readily available in a variety of flavors and styles, I am fairly confident that every programmer wanting to learn about the good parts of JavaScript can do so.
My previous attempts to learn JavaScript had not gone well and I didn't have an understanding about why the topic was proving so confusing for me. Knowing the history of the language and the environment at its birth, I now have a better appreciation for the abilities of this language as well as a higher level of acceptance for its quirks. I understand now why I should use "var" when assigning a variable, and also why it is a good idea to conclude the line containing "return" that is followed by a block, with the left curly brace that begins the block. I didn't have the patience to accept these idiosyncrasies before and now that I know the history of JavaScript, I can see why it is a good idea to use Crockford's suggestions as a consistent coding style.
Charles Jolley suggested that I read JavaScript: The Good Parts as a basis for learning JavaScript. His tag line was: "I read it in three hours." Now, that may be an inappropriate reason for reading a book, but after spending hours and hours with various media trying to understand JavaScript, three hours seemed like a reasonable investment of time. (It took me a little longer reading at home with the occasional interruption but I still did my first pass in an evening.) The author wrote the book as an enumerable (the recipient of an action one or more times) with each reading revealing layers of understanding.
In the appendixes, there is an appendix entitled "Awful Parts" and one entitled "Bad Parts". Global variables head the list in "Awful Parts". There are discussions throughout the book about why to avoid JavaScript's default to global variables and how to do this in your coding style. The explanation, of why global variables should be avoided in JavaScript, is detailed in the "Awful Parts" appendix. Also making an appearance in "Awful Parts": scope, semicolon insertion, and reserved words. The "Bad Parts" appendix includes: == (double equal sign) which can be evaluated unpredictably depending on the circumstances, "with" which can also have unpredictable results, and "eval" which passes a string to the JavaScript compiler and executes the result. "eval" slows the result when compilation isn't required and can also compromise the security of your application. But what about its use in JSON you ask? Crockford suggests using the JSON.parse method instead of "eval". The file which creates the JSON object with the parse method can be found here. If this is of interest to you, I suggest you check the link and access the book to hear it from Crockford directly.
I find Douglas Crockford's perspective on JavaScript in JavaScript: The Good Parts to be useful in my own relationship with JavaScript. His style is accessible and intelligent.
You can purchase JavaScript: The Good Parts from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
alert('no');
Perfect for a little light reading.
Javascript has its uses and works fine. Platforms have been the problem for me in the past. But with new libraries like jQuery, Javascript has become quite the tool.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
I tend to think of programming languages the same way I do hammers; they're tools to be used to accomplish a goal. That being said, I have to say I've always found Smalltalk to be a very cool language.
The world's burning. Moped Jesus spotted on I50. Details at 11.
The author states that the necessary equipment for writing JavaScript programs is a browser and a text editor.
You need waaay more thane ONE browser to write JavaScript. There are still so many cross-browser incompatibilities with javascript today you pretty much have to write one script for firefox and one for IE each time you code.
So... it's a blank note pad with a different cover?
is its neigbhorhood, where it is used. you spend 90% of your programming time dealing with the quirks between different browsers. ie isn't even the biggest offender, safari is
which is to say, there is nothing wrong with javascript. it a diamond trapped in a cage made out of shit
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
...of a t-shirt I saw once, it read "But what about all the good things Hitler did."
In all seriousness though with Prototype I don't find javascript browser inconsistencies nearly as problematic as css browser inconsistencies.
I love JavaScript :)
Am I a crazy mad man?
"Religion is the most malevolent of all mind viruses." - Arthur C. Clarke.
Since when is ANY programming language "cool"?
I myself don't find JavaScript cool, but I couldn't say the same about Prolog, Forth or LUA. On top of that, INTERCAL and LOLCODE also manage to be funny. ;-)
On a more serious note, if you can "feel" something as uncool, others can feel them as cool. Feeling nothing translates into perfect indifference. And since you posted a comment, your post itself is proof that inanimate tools do cause emotions and sentiments, your own words notwithstanding.
Conservatism: (n.) love of the existing evils. Liberalism: (n.) desire to substitute new evils for the existing ones.
And Lisp: Lisp is a hammer with all the power of a jackhammer and all the artistic merit of The Last Supper. :-)
maybe not cool in the sense of popularity by the people world as a whole... But by that sense, not much, if anything, is 'cool'. In the popularity sense, 'cool' tends to be geared towards a culture or grouping. Be it Americans, western culture, eastern culture, Russians, British, business executives, geeks... The slang word cool tends to be used in a rather flexible manner.
Also, it's a word rooted in OPPINION, which means SUBJECTIVE and not OBJECTIVE. That's probably related to the relative-to-grouping concept above, if you really want to ponder the semantics of it a bit more.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
[html]
[head]
[/head]
[body]
[script type="text/javascript"]
document.write("This message is written by JavaScript");
[/script]
Here?
[/body]
[/html]
--- What?
I must admit that JavaScript's method of scoping isn't the best (mostly because it has variables that can be reassigned, and scoping binds to the variables, not the values) but I can say that scoping is a time-saver if you do it right and (for example) have a bunch of anchors that all need slightly different arguments in their onclick event handlers.
I've more than once used something like:
It would be nice if it treated scope by binding values, not variables though... (If you tried doing the above by replacing onclickGenerator(i) with function() { doSomething(i); }, every element would end up calling doSomething(elements.length);, instead of doSomething(value_of_i_at_onclick_set_time);
And THIS is the symptom of an uber-asshole: he would rather spend his time blathering his pissy opinions
And your post was what... an example of a helpful opinion?
To see some incredible (IMO) JavaScript functionality, check out TiddlyWiki.
> JavaScript: The Good Parts
Shortest book ever?
I can tell from the title alone that this has got to be the shortest book ever written.
I Heart Sorting Networks
Crockford's website has a bunch of great articles about JavaScript. I've learned quite a bit from there.
http://www.crockford.com/javascript/
The creativity involved in making the link text in all of these trolls never fails to make me smile.
lithp ith for fagth.
Don't forget Python. The Python hammer functions differently based on the relationship of where your hand is currently on the handle to where it was previously. If you drop your hammer, you have to re-build your house from scratch.
Eggs
Milk
Bread
Cat Litter
Soda
i just wrote some script to handle anchor tag clicks globally. firefox, fine. opera, fine. ie, fine. safari: doesn't work in safari, because safari insists on doing the default action no matter what
http://codingforums.com/archive/index.php?t-30983.html
you can't cancel dom events in safari! fuck safari. so now i have to completely write off safari support, or completely alter my programming model because of its stupidity, and do some really guly hacks
or perhaps, no hacks possible!:
http://www.peterblum.com/SafariBugs/CancelKeyPress.html
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Or how about the C hammer? It's a rock.
Are you really required to support older versions of Safari? I only have 3.1.2 and that page that you linked to works as described - so it appears to have been fixed.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Javascript itself is a relative of scheme, which is a descendant of lisp.
It offers macros, closures and of course recursion.
The big difference is that javascript is not list based.
JavaScript: The Good Parts
Must be a quick read.
See my Home Theater
JQuery
Though they were the logical starting point, I am grateful to be mainly past my reliance on books. However, based on how good his videos (e.g. http://javascript.crockford.com/, http://yuiblog.com/blog/2007/01/24/video-crockford-tjpl/) are, I would consider checking this one out.
Bukowski said it. I believe it. That settles it.
I recommend buying the book. Closures are implemented with the expected scoping. They allow you do to things like this:
function createCounter()
{
var i = 0;
return {
incr: function() { ++i; },
decr: function() { --i; },
getValue: function() { return i; }
}
}
Aw crap, ninjas!
but safari still does default actions. you can't globally cancel a click, for example. i can't globally take over all anchor tag actions. safari will try to follow the href link still, no matter what you do in code. its really infuriating and im thinking of just dropping safari support
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
I'm a hobbyist and haven't programmed professionally in quite a while but if not Javascript, what (and I'm not using VBScript)? I'm not doing gigantic web sites, but little one off tools for my Shadowrun game. I'd like to have one page for inputting numbers, calculations, and the results are posted in the last field (like a total). Is there something I can use that's more appropriate?
[John]
Shit better not happen!
I've had the book for about a month now. I've read most of it, but I haven't finished it yet due to work and personal projects and tv and games... Anyway, I think it is really well written. Doug is definitely has a very intimate knowledge of the subject, but his writing comes across more like a guide than an expert. He takes an approach kind of like taking you on a tour of the language. It's a pretty short book, so in theory it should be a quick read. I'd suggest you pick it up if even for only understanding JavaScript better.
"And THIS is the symptom of an uber-asshole ... he would rather spend his time blathering his pissy opinions "
I hear you. But is this YOUR pissy opinion?
There you go.
Uncopyrightable: The longest word you can write without repeating a letter.
Honestly, I'm still not even sure where the goat is in that artwork...
If you would read the book you would find that your code contains a few definite "don't do that, that is bad practice" statements (at least according to Crockford).
If we take away the fact that there are several global variables created, the most problematic thing is that the code creates "elements.length" number of functions -> memory consuming, when it is easy to avoid.
There are several videos on YDN theatre which discuss many of the subjects the reviewer mentions (these screencasts came before the book). After I watched one I ended up watching just about all of them. See and listen to http://developer.yahoo.net/blogs/theater/archives/douglas_crockford/
and you will start to understanding javascript... not just write stuff what seems to work.
If you want to see if you write "good" javascript try "jslint" written by Crockford http://www.jslint.com/ But like the site says "WARNING: JSLint may hurt your feelings."
document.onclick=function(){
blah blah
}
then cancel event bubbling and default action, according to normal ie and firefox methods
the anchor tag is not modified in any way. the href goes nowhere
and i've tried to cancel the default action in safari in myriad ways, but it always tries to follow the bogus href ;-(
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Interestingly, jslint doesn't complain about the above code (if you assume that doSomething was already written and defined as a global function and that we're running in a browser such that document is already defined as a global variable.)
Yeah, building multiple functions is a bit wasteful. I suppose you could get by by attaching new properties to the elements and having the function attached to onclick reference the objects by using the event's target/srcElement property to get back to the custom variable.
That's one of the either really good or really bad things about JavaScript: there's a heck of a lot of vastly different things you can do to get the same effect.
do i give up all of my work and program from scratch according to a new approach? or do i just ignore safari?
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
I really like this book. The author does not treat you like an idiot or make 'oh so funny' jokes to make you feel comfortable with the text. The writing style is friendly and fluid, while the content is always to point. I wish more programming books were as dross-free as this one.
Many readers are likely to read through sections twice or a few times. Crockford warns, 'This book is small, but it is dense', and it is certainly is cramed with useful information. The author states no intention of writing a JavaScript reference but has certainly written a book that I will pick up frequently on JavaScript projects
I am surprised the reviewer didn't mention JSlint a free, online JavaScript 'verifier', written by the author, that can be used to 'debug' and write better code. It may even be worth a try before you buy the book.
> You don't need more than one browser to write a JavaScript program, you need more than one browser to develop a website.
Indeed. Well actually, you don't even need a browser to execute a JavaScript program.
About two years ago I stumbled across SEE, the Simple ECMAScript Engine. It is a standalone JavaScript interpreter. I find it excellent for teaching the fundamentals and flexibility of JavaScript in a non-Web context. No DOM references, no browser oddities, no picking through a JavaScript Error Console; just the student and the raw language.
http://www.adaptive-enterprises.com.au/~d/software/see/
BSD-licensed, of course. I have no affiliation with the project other than as a satisfied user.
Error: Implied global: doSomething 1, document 3
and
Global elements, i, onclickGenerator
1 onclickGenerator(i)
1 "return"()
Outer i
Global doSomething
Yeah, building multiple functions is a bit wasteful. I suppose you could get by by attaching new properties to the elements and having the function attached to onclick reference the objects by using the event's target/srcElement property to get back to the custom variable.
Well.. wastefull.. true, but for some apps it is detrimental (think ajax). Your example can perhaps be converted into something which avoids the need to pass "i" at all. Script libraries like YUI have code where you can control scoping when the handler executes. This may be overkill in this situation. So in this example perhaps setting an (html) id on the element and extracting it in the "doSomething" function would suffice, then you don't need the parameter at all.
/* lets say id is a1*/
function doSomething() {
var id = this.id
doSomethingElse(id);
}
then (something like)
for (var i = 0; i < elements.length; i++) {
elements[i].id = "a"+i;
elements[i].onclick = doSomething; }
But I really do recommend the screencasts, I thought I knew stuff about javascript, after having it explained (and verifed) in the screencats it is much easier to simply "use the good parts of javascript".
With the recent introduction of classical inheritance to JavaScript (which may or may not be a good thing, that's besides the point), is this book still current though?
"In our tactical decisions, we are operating contrary to our strategic interest."
Everybody talking about browsers, remember, Javascript is an interpreted language so the browser just acts as the interpreter. There is absolutely no requirement to use a browser to implement a javascript interpreter.
I wish more systems/languages used the 'image-based persistance' idea. And, its message passing is elegant simplicity--easy for humans to wrap their minds around.
dude, get with the now. goatse vids
"Javascript has become quite the tool." - by WED Fan (911325) on Friday July 25, @02:06PM (#24338577) Homepage
Yes, it has - However, quite often also (not just 'for the good') for the creation of malware laden websites, as well as adbanners that are bad (in combination w/ Iframes too).
Searching SECUNIA.COM for the past 3-5 yrs. worth of exploits almost nearly always has something to do with javascript, in the past few years worth of attacks, such as these:
----
Microsoft apologises for serving malware:
http://apcmag.com/microsoft_apologises_for_serving_malware.htm
----
(It even happens to "the best of them", including large corporate bodies, in them being 'suckered' by the people that put out malwares, by sneaking them into adbanners, as the example above notes)
AND, javascript's being exploited fro upcoming worse malware attacks, such as this:
----
Researcher to demonstrate attack code for Intel chips:
http://www.infoworld.com/article/08/07/14/Researcher_to_demonstrate_attack_code_for_Intel_chips_1.html
----
That last one? It's "pretty bad", imo @ least, maybe yours too, if you take a read of that last one.
I do NOT doubt it could happen, anymore than say, a malware being able to flash your vidcard OR motherboard's BIOS (because, if tools by say, ASUS &/or Gigabyte can do it, AND WHILE YOU ARE IN WINDOWS mind you (not bootup from a floppy) then it's possible these could too)
E.G.-> For example, if they ship a download via scripted attack that has say, a PnP driver + BIOS "img file" inside of it that the bogus javascript could SOMEHOW execute (or, a .exe they send - who knows? I don't make that kind of bogus ware, but the point is, the people misusing it are getting more & more "creative" about it, & their methods seem to be working).
----
Now, don't "get me wrong" here:
It's not that I "hate javascript" (well, I don't like working w/ it as opposed to other languages, let's put it that way), because it has its uses, but it gets abused a lot, in the way of being intended to harm others, is all.
Fact is - I have to use it myself on ASP.NET pages I create or created on the job, for instance, because sometimes, it makes easy going of it, or provides a way to do things I need done, faster (or, the only way I could SEE or KNOW how to do certain types of functionality, fast).
(Now - If the folks that create & extend javascripting engines can somehow do away with these misuses of javascript happening (how, I have NO idea, somekind of 'sandbox' such as 'fullblown java' has, good idea, maybe not perfect, but solid idea) that'd be GREAT... but I don't think that is as easily done, as it is said.
Mainly because it's like saying that for probably nearly ANY compiler out there for say, std. .exe files, first of all, probably an impossible undertaking (like a razor, compilers & code have 2 sides potentially).
Well - then, I wouldn't be "afraid of javascript", as an end-user online! Fact is, IF I knew it was safe (or, rather, safer than it is)?
I'd turn it on again in ALL of my webbrowser programs, & for every site online again (I cut the latter off, years back, once I saw it was being abused in bad adbanners mainly, like the first example above).
Yes, that is right, I am a bit afraid of it & tend to initially "cut it off" as to using it, wholesale @ first, in all of my webbrowsers, & ONLY turning it on for sites I absolutely cannot live without it on, & that's mostly banking &/or shopping style websites (& others that demand database or other files' access for instance, for ABSOLUTELY full & proper functionality (not just 'bells & whistles')).
Personal
i'll try that method
thanks for the tip
still a pain to change the whole programming model of how my page works just for safari
i'm current using document.onclick as a global handler
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it