Frequently Asked Questions

This page contains some answers to frequently asked questions. It mainly serves to keep the amount of reactions down, or to give me an excuse for trashing reactions of people who clearly haven't read this page.

Can I support this site?

Yes, you can, either by linking to it or by making a donation. See the Support page for more details.

Have you written a book?

No, though I'd love to.

When I got seriously interested in writing a book somewhere in 2001, the JavaScript book market was bloated with moderate to very bad books that mostly treated flashy DHTML interfaces and were riddled with browser detects and other bad code.

Reference type books restricted themselves to enumerating JavaScript's countless objects, methods and properties. These books are very useful, and generally better than the flashy books, but meanwhile we've got quite enough reference guides, too. Besides, I'm emphatically not interested in writing one.

The end of the market glut is not really in sight. I've corresponded with several publishing houses, but it always turned out that they want a JavaScript book that is exactly like all other JavaScript books. As soon as I mention my book would contain some theoretical chapters, communication generally breaks down.

I suppose all this makes sense from a commercial point of view, but I don't want a book that is exactly like all other books to have my name on its cover. I'm afraid we'll have to be patient while publishers catch up with the new way of writing JavaScript and books about JavaScript.

I don't mind waiting a little while. I'm still working on a JavaScript theory, and I like having some more time to think about fundamental questions. You can follow my current lines of thought by reading my slightly-less-than monthly Keep it Simple column on Digital Web Magazine.

Then which book should I buy?

The true book for every serious JavaScripter remains David Flanagan, “JavaScript, the Definitive Guide”, 4th edition, O’Reilly, 2001. I co–edited chapters 17-19 of this book.

Flanagan is theoretical, though, and it gives a complete overview of JavaScript, including many features you'll never need in a website. If you're looking for a beginner type book you might try Negrino & Smith, “JavaScript for the World Wide Web”, 5th edition, Peachpit Press, [2003?]. It contains some very useful examples and though it doesn’t treat advanced programming tricks, it will certainly help you get started.

lang="nl" Voor het Nederlandse taalgebied kan ik Peter Kassenaar, Basiscursus JavaScript 1.5, [5e editie?], Academic Service, 2003, aanbevelen. Een voorvader van dit boek leerde me in 1998 in twee dagen basis-JavaScript, en hoewel ik het ben ontgroeid, heeft het me toendertijd bijzonder geholpen.

Will you link to my page?

If you're thinking of showing me your research in the hope I'll link to you, I have to disappoint you.

There's nothing wrong with asking for attention. If you've done interesting research, you naturally want your peers to know about it. I feel exactly the same. When I publish a major new page I send out some strategic mails and hope people will link to me.

Your request isn't wrong, you just shouldn't send it to me.

I'm not interested in blog-style news item publishing, which, incidentally, is why I don't have a blog. I'm very bad at maintaining even a basic Interesting Sites page.

If you want to spread around any sort of news, sending it to me is a sure dead-end street. I just don't have the reporter instincts to keep up with a continuing stream of discoveries, discussions and opinions.

It's a kind of laziness. By ignoring your mail I leave it to others to assess your discoveries. I'll hear about it only when sufficient people start talking about your research. I use the web development community as a filter, so that I have to deal with less noise.

You'd do best to send your research to someone else.

Where is your XXX page/article?

If I published it on this site, or if it was in the old JavaScript Section or CSS2 Tests site, you can find it in my sitemap. I admit the sitemap is unwieldy, but I've tried to structure it as logically as possible.

If I published it on another site you can find it on my publications page. This page is far shorter than the sitemap, so start here if you're not sure whether the page you're looking for is on my site or not.

How does the XXX feature of your site work?

The Table of Contents and the navigation view/hide have an "Explanation" link, which links, surprise, to an explanation.

The breadcrumb script is not yet documented. See logo.js for the script itself; it's called by quirksmode.js, which I include in every content page.

My sitemap page doubles as navigation frame page. It is the same HTML, but I transform it rather heavily when it's loaded into the navigation frame. I haven't documented the effect yet, see navi.js for the code.

Which browsers do you test in?

In the five current browsers.

Why don't you test in browser XXX?

When I upgrade to a newer version of a browser, I have to update all compatibility tables on my site. This is a lot of work, and I'm not particularly eager to do it every single time a browser vendor happens to release a new version.

I upgrade browsers about twice a year, and I always make sure that I can test at least two new versions simultaneously (say, the new Mozilla and the new Opera).

Also, I currently have no Linux workstation so I don't treat Linux browsers at all. I'm eventually going to get around to arranging for a Linux box, but I'm not in a hurry.

In addition, the Mozilla family of browsers has become so extremely bloated that I cannot possibly test all scripts and CSS in all these browsers, even if I wanted to (which I don't). Therefore I test in only one single Mozilla version.

If you don't like that, set up your own site with detailed compatibility information about all Mozilla releases. I'll link to it.

I have information on a new browser version. Are you interested?

Depends. If you describe one particular behaviour in two or three lines, and if I only need to add a single line to one page, I usually publish it. If your report is too complicated, or if I'd have to do significant retests, I ignore it.

Do NOT send me long, detailed, and opinionated mails about recent browser versions that I haven't yet tested. You're just wasting your time.

Why didn't you answer my mail?

Please remember that I'm quite busy. Generally I go through all feedback about once or twice a week, so if you're unlucky you may have to wait a week before getting a reply.

Furthermore, some mails are not worth replying to. I generally trash 30% of the feedback mails unanswered. (It used to be 50%, but this FAQ is working).

There are several reasons for this:

  1. You didn't use my contact form.
    I filter mails sent through this form into a special mailbox, and once every while I go through all these mails. Conversely, mails sent directly to me may not get my attention since they're in the wrong mailbox.
  2. You sent me an attachment.
    All mails with attachments are automatically trashed. I don't want to receive them for any reason. If you want me to take a look at a page, send me a URL.
  3. You obviously don't know CSS and JavaScript.
    If you're not sufficiently aware of recent developments in client side programming, you're on your own. I can't spare the time to help you catch up.
  4. You're asking about other programming languagues
    If you ask me about, for instance, C#.NET or the Windows Registry, you're guaranteed to get no answer, since I know nothing about these subjects.
  5. Your mail is too long.
    Please be short and snappy. If I need more information I'll get in touch with you.
  6. Your mail is too vague.
    Please tell me exactly what you think or see, and exactly what you want me to do about it. A mail like "Browser XXX sometimes refuses to execute statement YYY!" is trashed immediately. Instead, tell me when it refuses to execute it, and send me a link to a test page.
  7. You didn't read the browser notes on this page.
  8. You didn't refer to a simple, clear test page.
    If you have discovered a CSS or JavaScript bug, please publish a page that contains the minimum code necessary for the bug, and a short description of the problem, your test case and possible solutions.
    If you want my help in implementing one of my scripts, please add some notes to the page the script is on, and place the script in inline tags, not in an include, so that I can see it by performing a simple View Source.
  9. The bug you describe is too obscure.
    There are about two dozen gazillion CSS bugs, and most of them only occur when you use three or four specific styles in a specific context. I'm not interested in such bugs, because they're too complicated to describe, and if I described one I'd have to describe all two dozen gazillion.
    Hint: If it takes more than 50 words to summarize the bug is too obscure.
  10. You asked a complicated CSS question, with lots of boxes and floats and margins and stuff.
    Ask CSS Discuss instead.
  11. You repeated the gist of one of my articles, and said that you agree.
    Although I'm glad you agree, I'm not sure what to do with these mails, since perfect agreement does not invite discussion.
  12. You asked: "Please test this-and-this for me".
    Test it yourself!
  13. You asked: "I've got this script and it doesn't work"
    Too bad. I don't fix other people's scripts.
  14. You want to berate me for not following this-or-that standard.
    I'm currently not interested in such discussions.

Even if you scrupulously adhere to all these guidelines, I may not answer. Usually that's because I'm too busy and your question is too complicated to answer in two minutes.

I'm very sorry, but the help I offer is free, which means that paid jobs come first.