Slashdot Mirror

The purpose of the article was improving performance and response times. This means trading in practices which one should be doing to optimize for what works best. While DOM manipulation may be the standards compliance way of going it is dramatically slower than innerHTML. It is only recently that Safari and Opera have been able to increase the speed of DOM manipulation, but sadly IE and Firefox (the two more used browsers) show better results for innerHTML. In my own testing Firefox 3 was closer to the Opera timing, only with the innerHTML and DOM method results reversed.

And future proofing isn't really an argument because the prevalence of innerHTML is so vast that dropping support for such a feature is equivalent to market share suicide. It would break so many sites that it would kill any base said browser had.

DOM manipulation is a useful tool, but one needs to know when to use it and when not to. I typically start with DOM manipulation when writing a JavaScript application using createElement for new nodes. If new nodes need to be created within a loop, I first create one node outside of the loop, and then clone a newer second node for each iteration (as mentioned in my first link). It is only after that that if performance is lacking AND I am lucky enough that I did not need to append any event handlers to said elements that I resort to innerHTML.

This explains the mess:
http://www.quirksmode.org/blog/archives/2005/09/xmlhttp_notes_r_1.html

What's even worse is that MS removed the * hack

As a standards web developer, one can only say that's a good thing. Since that time MS and some of the big name web standards developers have come out in having people use the IE Conditional comments to target specific CSS code to (any) IE. It allows you to keep your main CSS files IE hack 'clean'.

Cheers,
Fozzy

You are wrong.

http://quirksmode.org/bugreports/index.html reports 122 rendering bugs for IE5/IE6 and 88 for IE7.

Mozilla has 52 in comparison.

Even when you encounter a small bug (and I did discover some !), it's really unbearable, since the browser cannot be patched, and also you cannot report a bug to the IE team.

Finally IE7 supports transparent PNGs, but CSS support is still poor at best. Here's a table that lists support of various CSS styles on a per-browser basis. IE doesn't look good.

This is theoretically possible too, though there are problems with the spec (i.e. you access the given stylesheet rule by a numerical index) and (especially) the implementation (since it is apparently different for every browser in existence).

This is very possible. Has been for quite a while. http://www.quirksmode.org/dom/classchange.html

they've fixed also the bugs that made it possible to work around the bugs that they have NOT fixed yet! :-/

On the plus side, conditional comments help with that. They make it much easier to target a section of HTML or a stylesheet link to only IE6, or only IE7, or only IE up through 7, etc. And since they're intended functionality, not bugs, they're less likely to stop working in the future.

We then use a standards-compliant well-documented library, jQuery, to add an onclick-handler to the link.

Absolutely, this design style, called Unobtrusive JavaScript (for those reading and learning something new) seems to have become a recent push since the whole AJAX thing exploded. It's well covered by the gurus of the field Jeremy Keith (talks about it in his book Bulletproof AJAX) and Peter-Paul Koch (ppk) of QuicksMode. I've not read his book, "PPK on JavaScript" but if it's half has good as his website, it would be a standard buy for any web person.

Speaking of jQuery, Jeremy Keith also lists the following JavaScript Libraries/Frameworks/Toolkits...

• Prototype
• Scriptaculous
• Mochikit
• jQuery
• YUI (Yahoo! User Interface)

The only way someone would be screwed with this solution would be if [...] I am not aware of even a single example [of a browser that could screw this up]

Right, while not all objects/functions are supported cross-browser, they usually work the same when they are supported. There's only one real concern about the world of "AJAX" and "Web 2.0" that Jeremy Keith pointed out in Bulletproof AJAX: screen readers. Apparently Screen readers are far behind in detecting dynamically updated content via JavaScript. JavaScript "could" be turned on and the page properly updated but the Screen Reader won't understand this and this is a big problem for those sites concerned with accessibility. In short, those who require screen readers should turn off JavaScript and allow the site (if properly designed with unobtrusive JavaScript) fall back to the full page refresh updates. However, I don't know if there's a foolproof (or bulletproof) way of making sure screen readers turn off JavaScript and it could be bad to assume one would be turned off (if your sites traffic has high accessibility needs).

Cheers,
Fozzy

We then use a standards-compliant well-documented library, jQuery, to add an onclick-handler to the link.

Absolutely, this design style, called Unobtrusive JavaScript (for those reading and learning something new) seems to have become a recent push since the whole AJAX thing exploded. It's well covered by the gurus of the field Jeremy Keith (talks about it in his book Bulletproof AJAX) and Peter-Paul Koch (ppk) of QuicksMode. I've not read his book, "PPK on JavaScript" but if it's half has good as his website, it would be a standard buy for any web person.

Speaking of jQuery, Jeremy Keith also lists the following JavaScript Libraries/Frameworks/Toolkits...

• Prototype
• Scriptaculous
• Mochikit
• jQuery
• YUI (Yahoo! User Interface)

The only way someone would be screwed with this solution would be if [...] I am not aware of even a single example [of a browser that could screw this up]

Right, while not all objects/functions are supported cross-browser, they usually work the same when they are supported. There's only one real concern about the world of "AJAX" and "Web 2.0" that Jeremy Keith pointed out in Bulletproof AJAX: screen readers. Apparently Screen readers are far behind in detecting dynamically updated content via JavaScript. JavaScript "could" be turned on and the page properly updated but the Screen Reader won't understand this and this is a big problem for those sites concerned with accessibility. In short, those who require screen readers should turn off JavaScript and allow the site (if properly designed with unobtrusive JavaScript) fall back to the full page refresh updates. However, I don't know if there's a foolproof (or bulletproof) way of making sure screen readers turn off JavaScript and it could be bad to assume one would be turned off (if your sites traffic has high accessibility needs).

Cheers,
Fozzy

What we need is a http://www.quirksmode.org/ for SQL.

I mean c'mon it's not hard to write a brilliant page that works everywhere. Look at how Gmail works. IE, FF and Opera all render it correctly. Even Konqueror does a good job but its javascript implementation is a bit lax.

That must break poor PPK's heart.

I wouldn't go down the prototype/scriptaculous route. Those libraries are powerful, but so is jQuery, and it's much more lightweight and easier to learn. Fun, even.

If you want to understand unobtrusive javascripting (which is the only way to go really, unless you don't mind your site's content being invisible to search engines), PPK's book is the best I've seen.

I think that was the month they wrote the IEMac design docs, bringing about the destruction of the internet and the worm eating Apple from the inside out. At least until the contract expired and they went on Safari.

But seriously IEMac4 sucked.

But seriously IEMac5 was ahead of its time.

It's strange, Tantek and Jimmy are the only men at Microsoft besides Bill Gates that I'd like to shake hands with, then punch in the mouth. Thanks guys. ;-)

(Yes, you'd better believe I still have to test my designs with it...)

Make a javascript version and a non-js version, and if there's a browser not on the tested whilelist, go non-js.

In the particular case of JavaScript support, this is poor design. Identifying and testing in browsers is a slow, unreliable process, and needs constant maintenance as new browsers come out. It's been best practice for years to use feature/object detection.

"The restitution was probably the cost of patching the vulnerability."

The vulnerability was in Internet Explorer and Opera, not in myspace code. Browsers aren't supposed to execute javascript found in css statements.

http://www.quirksmode.org/css/javascript.html

FYI, it doesn't work in Opera/linux or Internet Explorer 6/linux. As for Windows, I wouldn't know ...

it has been updated to account for IE7's ideosyncracies, but does it also cover the other browsers well?

Good question, each browser has different levels of support. If you check out some browser usage you can see a decent estimate of what browsers are most used. Then you can check out browser CSS compatibility.

Besides IE6 (I'm not supporting IE5 Mac), I do not see issues across (modern or heavily used) browsers very often, unless I'm trying to do some sophisticated, multi-column, nested, floating DIV design. Also, in my experience, complicated float designs usually can be simplified with other means to avoid X-browser issues.

The biggest problem with CSS is that it also required good (X)HTML markup. Sometimes your CSS is sound, but the HTML code is not proper or designed by design instead of designed by content. A good book on working through this is Transcending CSS: The Fine Art of Web Design whose authors are also well known in the CSS/Website world and quote from Eric Meyer (the author of the book being reviewed on this page) as well as others.

I've been starting to learn that lots of my CSS frustrations of the past have mostly been part of my fault not thinking about CSS properly and trying to make easy things more complicated. Though, it can still be said, there's still lots of room for improvement, in both browsers and CSS specs.

Cheers,
Fozzy

Hey! What is wrong with you! I do not hate MS... well a bit but what they do good sometimes is good. And I am very neutral to software companies if they do their jobs well. About the IE issue I already commented that it doesn't still work for me... here is what I found on google: /a co-developer of mine has reported this to be an IE7 problem after searching that day sorry for not able to find what he did then/ http://www.quirksmode.org/bugreports/archives/expl orer_56_windows/index.html it says: When using input type=image as a submit button, only Firefox sends the name-value pair to the server. There's an unobtrusive JavaScript fix included, which makes Opera, Firefox and IE6 behave the same (not tested in other browsers).

Forgive me if you already know this, but I ran across this bit of info a few months back. You can put IE into "standards compliant" mode by using certain doctypes. For instance, this doctype will make IE use the W3C standard box model, where the "width" css property sets the width of the content area (excluding borders and padding):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transition al.dtd">

This makes writing a site that looks great in Firefox and IE a little easier. Not a whole lot, but a little :)

More info here: www.quirksmode.org/css/quirksmode.html

applying styles correctly in dynamic updates.

Uhhhh... "display: inline-block" is CSS (CSS 2, anyway)... See here.

• display: table
  
• :before and :after
  
• :active
  
• :focus (IE 5.2 for Mac actually still does a better job)
  
• outline (IE 5.2 for Mac has full support)
  
• Tables: border-spacing
  
• Tables: border-collapse
  
• Tables: caption-side
  
• Tables: empty-cells

• display: table
  
• :before and :after
  
• :active
  
• :focus (IE 5.2 for Mac actually still does a better job)
  
• outline (IE 5.2 for Mac has full support)
  
• Tables: border-spacing
  
• Tables: border-collapse
  
• Tables: caption-side
  
• Tables: empty-cells

Microsoft does not support an official way to run multiple versions of Internet Explorer on the same system. This is only really an issue for web developers who need to test their websites in older versions of IE. The closest they come to "blessing" any method (short of testing on different computers) is to recommend running each version of IE in a virtual machine.

Now they're restricting virtual machines, forcing people who want to use the recommended solution to get the more expensive version of the OS.

This won't have much immediate effect. For one thing, Vista will ship with the newest version of IE, so unless you're using Win2k as your host OS, your guest systems will be older versions of Windows without the restriction. For another, it's actually easier to use the unofficial solution to run alternate versions of IE (though it's got its own drawbacks).

Something to think about, though.

CSS is a great idea, but doing it in practice blows because the browsers vary so much in their implementation.

The most useful thing I have found to help is QuirksMode Browser Compatability Tests. I think this guy is insane to have spent so much time testing every single feature in (nearly) every browser, but it is very, very useful to see exactly which browsers support what.

"Secondly, I can't take your rant seriously. At all. " That's because you don't understand cross-site scripting vulnerabilities. At all. Even if you made a perfect browser without vulnerabilities that implemented JavaScript to the exact EcmaScript specifications, you would still be vulnerable because the XSS vulnerabilities exist in the web applications, not the browser. The design of JavaScript enables this, because the separation between code and data is flimsy (you can insert JavaScript almost everywhere in HTML, with "on ..." events -- you don't even need a script tag); you couldn't do it unintentionally with a web browser that only understood Java, and a Java web application. JavaScript makes it very easy, just like C makes it easy to mishandle pointers and fixed length buffers. If C gets criticized for that, it's fair to criticize JavaScript for making XSS vulnerabilities easy. Microsoft's version of JavaScript is worse due to the insecure functionality (see http://www.quirksmode.org/js/intro.html) added *by design*. People keep getting surprised by the nasty stuff that standards-conforming, but malicious JavaScript can do, from simple stuff like undying windows (JavaScript spawns a new window every time it detects the closing event) from taking over your desktop, including exploiting intranet applications (recent example: http://www.phoneboy.com/node/6 ; original article at http://www.spidynamics.com/spilabs/education/artic les/JS-portscan.html). It's not surprising to me -- hostile code is much more powerful than hostile data (see below).

You also don't understand how much more difficult it is to process hostile code than hostile data. You point out vulnerabilities in handling data as proof that there are other dangers. Given these, and how much more difficult it is to safely handle code than data, you should agree that it is reasonable to highly distrust a browser's handling of JavaScript.

The more ignorant people are, the quicker they are to mock people pointing out security issues.

Tidy, as others have already mentioned, will be your very best new friend.

Install the 'Web Developer' extension for Firefox, and use some of the HTML/CSS validators in the Tools submenu.

Get a good handle on regex searching & replacing (if you're doing this from Windows, I suggest Funduc's "Search & Replace").

If you're migrating your GIFs to PNG (which I would recommend), then you need to get yourself pngout, to compress them to their smallest possible size (Photoshop SUCKS at this).

And as someone else said, make an empty new standards compliant template, and get to cutting and pasting; it can be a *brutal* initial process, but you'll probably save yourself time in the long run, depending on how clean you want to eventually get the code. If you just want it to be standards compliant, then you can just do a clean up job. If you want to do it 'right,' you'll want to develop a new template and coding style to properly integrate the HTML and CSS. Things like not putting everything in a DIV (a sure sign you're a newbie to CSS), just to style something. Figure out why you should be using H1, H2 tags (& TBODY & TH tags if you're using tables for outer layout), etc, without having to use a lot of unnecessary DIVs all over the place. Inline styles = bad.

Figure out why XHTML may not be the best choice over HTML. Know which DTDs to specify. Know the difference in IE6 between standards mode and quirks mode, and which DTD to use to make IE6 behave. Know that IE7's quirks mode is supposedly identical to IE6's; you supposedly won't get the new 'more-standards compliancy' in IE7 without a DTD.

Oh yeah - the guy who posted about replacing spacer gifs with 'spacer DIVs'? Don't do that to yourself, okay? Yikes.

Learn about usability and readability. Learn about typography, and how light-on-black text should be sized differently from black-on-light. Thinking about grey text on black or grey text on white? Don't be stupid. Make the stuff readable! Learn that sans serif fonts are more easily read at screen density (opposite of print). Learn why Verdana is usually not your friend (go for Trebuchet MS or even Arial).

Oh, and learn to intent your freaking HTML!

Some nice resources:

Activating the Right Layout Mode Using the Doctype Declaration

Quirksmode - a GREAT resource. Awesome info here. Memorize it.

A lot of them have been destroyed.

For further information on CSS compatability, check out the IEBlog entry, "Details on our CSS changes for IE7", as well as the Quirksmode CSS browser compatability page.

Web developers can use conditional comments to target a specific version of IE, and here is an article that goes into the details of what hacks are "supported" by IE7.

Supporting IE7 will require some extra work by webdevs, but it's doable even if code already contains hacks for previous versions of IE.

Print version here.

Zero credibility points for trying to put markup in the <title> element and hiding the printable version behind a javascript:void(0) link.

If you want the technical stuff, skip about a third of the way down. The first third of the article just repeatedly tells you that Ajax is when the page doesn't "blink".

The code he supplies is crap. For instance:

<html> <head>

<title>HTMLfs</title>
</head>
<framese t rows="100%,*">
<frame name="visible_frame" src="visible.htm">
<frame name="hidden_frame" src="hidden.htm">
<noframes>Frames are required to use this Web site.</noframes>

Things wrong with even this tiny snippet of code:

• Invalid.
• Frames (at the very least, he should have used iframes).
• Cheesy "fuck off" error message instead of functional equivalent.

Skimming the rest of the article, I see the following mistakes:

• Using DOM methods without testing for their existence.
• Browser detection (which is stupid and wrong).
• Obtrusive JavaScript embedded in the page with old-fashioned HTML attributes.
• Non-degradable JavaScript form submission with <button> instead of <submit>.
• Confusion over what elements and tags are.
• Internet Explorer-only code without error checking or a fallback.

If this is a representative sample of the book it is excerpted from, steer well clear of it. The whole approach is poor.

The best way of producing compatible, accessible Ajax applications is to start with the bare HTML and make that work. Only then do you add the JavaScript, and you do it by enhancing the page, not replacing it. For instance, don't use <button onclick="...">, use a normal <input type="submit"> and hook into the form's submit event. That way:

• It works when JavaScript is unavailable.
• It works when there's a problem in your code.
• It works when you find you can't do something halfway through processing the event (e.g. you find that ActiveX is switched off in Internet Explorer, making XMLHttpRequest unavailable).

The problem with that is that Microsoft makes it difficult to install two different versions of IE on the same machine. It's possible, but not exactly easy.

Since I currently need to support IE 6, I haven't bothered trying IE 7. At some point I'm going to have to figure out how to run both IE 6 and IE 7 at the same time, but for now, I'm just not worrying about IE 7.

The other problem with IE 7 that I hope is fixed is that IE 7 Beta 2 broken HTML help. That forced me to uninstall it (on my home machine) since I happen to need to read the documentation for various apps that comes in an HTML help file.

Even if those percentages are correct - which I highly doubt - the percentage of the CSS standards followed doesn't give you the number of pages displayed correctly. For example, the rules that dictate text colour or position are going to be used more often than, say, inline images or selectors (which is why we get tests like Acid2 to test the rarely-implemented stuff).

Also I like to mention conditional CSS in IE, which is probably the only nonstandard feature in IE that's useful.

Seriously, A List Apart's Stylesheet Switcher uses onunload to set cookies, so you get the same stylesheet next time. It works in Microsoft Internet Explorer and Firefox, but Opera support is iffy.

Why? Because Opera doesn't fire the unonload event if the user clicks the back or forward buttons. I can see not firing when hitting forward... but when hitting back?

Actually, yes, you can run two versions on the same machine via several mechanisms. There's the unsupported hack method detailed here http://www.quirksmode.org/browsers/multipleie.html , and you can also download a free VM from VMWare or Microsoft and run a development version of your OS with the other version.

Update: I just checked quirksmode.org. Looks like all the major browsers support CSS tables now ... except for IE. *sigh*

There's no associated complexity with programming in JavaScript. There's lack of progress in the language (still no native support of ECMA4 in browser, shame that *Flash* comes with ECMA4 implementation in just two months, before browsers do).

I disagree.

Javascript is complex due to it's idiosynchroses due it's weird mix of functional LISP-like features and half-baked OO constructs (prototype) which means that (for instance) the "this" keyword has strange properties which, although well-documentated, make it hard to use the encapsulation features that do exist

As a result of this, Javascript-capable IDEs have poor code naviagtion and outlining - and the deguggers have similar problems making it complex to develop using to Javascript.

JS synthesis is a hack anyway. I've seen the code produced by such technologies, and it's crap. You trust your application's well being to the compiler authors with the hope they update it when it breaks in the latest and greatest browser out there.

Given the browser issues, I would think that a Javascript compiler is just the way to go. As soon as (say) IE 7 comes out and breaks all those hand-crafted scripts, you just recompile with the lastest version of (say) Google's GWT whcih will obviously be kept up to date with the latest browers

I'm a functional (Haskell, LISP) programmer as well as being well versed in OO (C++ & Java mainly) and I've just started my first AJAX project and I've hopped from IDE TO ide including plain vim, Eclipse with ADT & WDT, Mozilla with Venkman debugger and (gasp horror) Visual Studio 2005 and I still find it harder than anything else I've done in terms of code-navigation and debugging

"People who don't know what they are doing and complain about "em". This is you."

Then tell me what part of the following indicates that I don't know what I'm talking about:
- I have a div which is supposed to be a side bar on my site.
- The width attribute is set to 2cm. Note that according to http://www.quirksmode.org/, the width attribute defines the width of the inner part of a box, excluding padding borders. The padding is set to 1em. The div is floating to the right side.
- What I want is that the main content's maximum width is the width of the div (including the div's padding), minus another em so there's a little space between the side bar and the main content. So I wrap the beforementioned div into another div, which has a padding-left of 3em (to compensate for the inner div's left padding, right padding, and the extra spacing).
It should work. Works fine in Firefox. Passed the W3C validator. Broken in IE.

What part of that indicates that I don't know what I'm doing? Do you even know what 'em' is? It sounds like you are the one who doesn't know what you're talking about. In fact, you sound exactly like those Microsoft zealots who are constantly trolling users of alternative browsers.

http://www.quirksmode.org/
Reproduce it yourself. Especially the broken alpha channel support and the broken 'em' unit support in IE are annoying.

You can't be serious. http://www.quirksmode.org/about/makingof.html#bugr idden

You already can run stand-alone versions of IE. Evolt has a good repository for this, and the very excellent QuirksMode has a great guide to implementing it (basically, you just create a seperate directory for each IE manually, such as C:\Program Files\Internet Explorer 5.5\, and install to there).

If Quirksmode weren't pretty, no one would read it.

People should read quirksmode.

So it should be pretty.

Q.E.D.

Please don't promote that awful tutorial. It makes two classic newbie mistakes: javascript: hrefs and browser detection. These are stupid and wrong. Yes, I know Rasmus is a hot shot PHP developer, but his Javascript sucks.

You mean did I read this
http://www.quirksmode.org/dom/innerhtml.html

Well, sure I could do it the slower way with lot more code, but then again, I wouldn't feel good about myself then :)

Goold luck creating large amount of dynamic html without it.

When a browser/OS combination determines how something renders, like an input type="file" element. Want to stylize it? The page at http://www.quirksmode.org/dom/inputfile.html provides some guidance, but holy crap, what a friggin pita!

[this I know, spending a few hours trying to maybe write my own version with no better luck]

...have put off working with JavaScript because of the standards issues, then this book is our notification that those days are behind us.

Sorry, but I have to disagree with you immensly on this point.

There were, and still are, drastic differences between browsers in terms of JavaScript and even DOM. A cursory glance at http://www.quirksmode.org/ shows what I'm talking about.

Standardizing javascript now, or in the future, has no bearing on supporting the past and present. Unless you can afford to not support browsers... IE doesn't fully support setAttribute() yet (id, class, for, onClick, etc.). Firefox doesn't support innerText, outerHTML, nor outerText. IE doesn't support cssRules but does rules while Firefox is the exact opposite (opera does neither).

JavaScript has a long ways to go and no book is going to erase these vast differences no matter how well written it is.

It seems the only way we'll get out of the javascript mess is by everyone supporting everything or an entire new language is created with a strict API defined. Then again, HTML & CSS are still up in the air so standards aren't the whole solution.

Mostly bugs in alignment of elements it seems. The site I'm working on now is having a lot of issues with it and I've had similar issues on other sites I've done.

Have you looked around here and here to find out whether the issues you're seeing have explanations or workarounds?

I see innerHTML as lazy, it only takes a few moments to create a proper node set. String manipulation is so 1990.

Unless you care about performance on the client, which depends entirely on the app you are building. Yes using the DOM is cleaner, but apparently innerHTML is faster to write and to execute. That said, I generally use the DOM.

I don't bother with hacks anymore. Conditional comments are much easier. Now the only thing I have to hack for is differences between Firefox and Opera, which I don't run into very much.

A few months ago, the IE team asked web developers to switch from using CSS hacks (which depend on additional bugs which may not get fixed at the same time as the ones you're working around) to using Conditional Comments, which let you target specific versions of IE using intended functionality rather than bug side effects.

This still requires effort on the part of web developers, but they at least tried to get the ball rolling back in October.

It can also be mitigated by checking for capabilities rather than browsers. For example, look for a DOM function, and if you don't find it, look for the IE function, instead of the other way around. It's the way they recommended handling AJAX when they announced the native (i.e. non-ActiveX) implementation of XMLHTTPRequest.

if (has standard function) {
do standards-based stuff for Firefox, Opera, Safari, IE7, etc.
}
else if (has IE function) {
do IE-specific stuff
}
else {
do fallback stuff for primitive browsers
}

From looking at my own sites, half the bugs have been the result of CSS hacks I'd forgotten about, and the other half have been attributed to a particular bug in the new beta/preview/whatever: Horizontal padding is applied incorrectly on absolutely positioned elements, causing the text to overflow the right edge of the box. I put together a testcase and reproted it on the IE blog, where I found that at least 2 other people had reported the same bug.