Code Away

Beautiful post on removing CSS layout and going back to the good ol’ table tag. The comments are good as well, if you can locate them among the thousand-odd rants.

Actually the beauty of the post lies in the author not trying to be in preach-mode. It’s just a “screw it all I’m goin’ home” treatment handed out to display:block; float:left; layout, which has irked some gentlemen of the CSS church. For these kind-hearted people, the author takes some time out to coin a term CSS-Trolls. And could you believe it, the very same association of people replied on this post with complete disgust, on how terrible the advice is, and how the author ought to die of shame. Well, some comments were actually written by well-mannered folks, who put their point and signed off with a bow.

But let’s not talk on people. Let’s talk on the point in question. Tables or CSS?

Well it really doesn’t have to be an exclusive decision. CSS does provide a lot in terms of

• Flexibility in presentation
• Easy alterations in future
• Accessibility for visually impaired
• Pixel-level control of all objects

and other goodies. I’m a CSS fan ever since I built my first CSS-enabled website 3 years ago and realized how much I sucked in web design before.

Yet, CSS, with all its control on page components, remains a browser-based implementation. Wait, even tables are in the same league! Yes, but tables give you one assurance: If you want “Y” in the left cell and “Z” in the right, that’s how you are going to get it. No side effects with anything: pages resized, font sizes increased, browsers changed, you try it. It may look ugly, sucky design, but “Z” remains to the right of “Y”.

This one single feature of consistent placement gets screwed up when you try to use CSS. I sat with my friend once to get a layout with 3 columns, with a horizontal bar at the bottom of all three columns. Quite a number of times, the bar appeared on the right of the columns, sometimes behind the columns. It took us a good one hour to get things sorted out, after adding a multitude of attributes for the last column and for the horizontal bar. I can surmise that whatever attributes we used would produce at least some side effects in one of the browsers.

You can well say that I am not as good of a CSS coder as I think. Well, that’s the whole problem. The layout worked perfectly in one browser and it wouldn’t on others. Why does my knowledge on markup have to involve inconsistencies rendered by design specs of different browsers?

Lets take another example. A friend working in a UI framework team discussed an issue with me one day: The div appeared two pixels to the right of the desired location on FireFox, while it rendered at the perfect spot for IE. Now that’s an amazing problem, where the (heavy) component is derived from 5 other smaller units. Turned out to be a difference of rendering a border between FF and IE.

Coming out of bedtime stories, we have situations where “the boss wants the code complete by evening”. It is useless to sit and gaze at the beauty of CSS at times like these. Just get yourself some nice tables where necessary, use CSS where easy and roll it out, as many have preferred.

Yesterday I happened to read a good bit of discussion which happened way back in 2005 on behavior of Google’s Web Accelerator and the trauma caused to websites. Although coming a little late to the party (3 years later), my post on Best Practices for GET and POST HTTP commands does answer some big questions which kept occurring in the discussion.

At first, a little introduction to the havoc wreaked by WebAccelerator: It sits with your browser, and “clicks” links intelligently on the page you have visited. This ensures that your next click opens the new page instantly. However, “intelligent” behavior started to trouble web applications where links happened to update/delete records in Admin Consoles.

Although the bigger question raised was regarding privacy concerns (Google indexes pages prefetched by WebAccelerator, which includes pages unreachable by its crawlers), lets keep that out for a moment and revisit the issues faced by web developers. As Web Accelerator is no longer active, you may wonder why we need to recap history. The reason is, you never know what plugin the users of your app have installed on their browsers. Yesterday, it was Google. Tomorrow, it may be something smaller, having auto-installed with another package, and no one will have an idea that your pages are being prefetched.

As always, information websites with links sprinkled around do not need to bother about prefetch. Its the websites with user authentication required that mostly fell prey to this activity.

I’ve not tried GWA, and there are comments stating that GWA doesn’t do a lot of things which have been alleged. However, our work here is not to discuss merits of Web Accelerators and their conformance to standards. All we want to do is strengthen our own website. So lets take a look at some problems faced, and graceful solutions or workarounds opined.

1. “Logout” link prefetched once the user logged in: This threw the user out before he did any other activity. Quite irritating. The “Best Practices” supporters came out in strong defense of Google here. Why would developers keep Logout as a link (GET) and not a POST, they asked. Except that Logout is really an idempotent operation! A user can logout once or ten times, and it is always the same result, in almost all cases. Our little tweak to the Best Practices helps in deciding that POST is better for Logout.

A safer deal is to have form method as GET when the application state does not change at all

2. “Delete” links prefetched in Admin consoles: Well, this is pretty straightforward. You cannot have “Delete” as a GET operation. But here’s where we get out of utopia. In the real world, navigation and look and feel of the application is largely decided by the UI team, and the developer has little say in the matter. If the designers feel that links alongside 10 items feel “cool” and buttons don’t, well, you need to keep a link. The workaround here is to have a href = "#" and code a form submit on the onclick event of the link.

3. Links which involved heavy database operations: …and thus increased server load were prefetched. A way out here is to limit the number of “heavy” operations performed by a user per minute. This seems like a fair balance between a hack to redirect to 403 and a puritan approach of removing links altogether, making pages accessible only through Javascript or POST operations.

4. Links which retrieved data but also imposed exclusive locks on the data: The first user to come along could end up locking quite a bit of system data, thanks to prefetch operation. However, isn’t a lock on data change of application state? The change needn’t be in a database operation. Any change of state should require (scream) POST.

Well, that’s quite an interesting list of 4 points with repeated gyaan which has, no doubt, also been written  before by others. But, as long as reading this post helps at least one developer, I’m happy. Benefited developer, please post a comment so that I stay vindicated

While posting about usability of alert, I was chatting with a friend who saw it not just as a minor nuisance, but a greater threat. Since alerts interfere in user activity in other tabs, we have a basic case of client side DoS, he said.

After thinking about it, I’m inclined to agree.

Older browsers didn’t have this problem: they were not multi-tabbed. And window switching is certainly not disabled by any modal pop-ups.

Browsers evolved, tabs arrived. Today I have 15 tabs opened in my browser. And then say someone sends me a nicely obfuscated script which simplifies to this:

javascript:eval("for(i=0;i<554;i++) alert(123)");

Works nicely in FireFox. Stops me from accessing other tabs altogether till I succumb to the pressure 554 times (and I might not even know the actual figure if its jumbled code)

And lets not forget that this error can be caused without malicious intent. Say some webpage gives out two or three alert messages in a loop, and the loop counter goes haywire because of a corner case which wasn’t tested. It still is a block on all activity in the browser, whether the user likes it or not.

I’m not saying this is some awesome loophole in browser security. But it certainly is more than an irritant if I’ve paid by credit card in another tab, and the site is waiting for me to perform the next step.

The graceful solution for this is to have dialog boxes modal with respect to their own tab. This satisfies all legacy requirements of an alert as well. Currently, browsers have just provided a knife to play with.

Update: This problem has been reported in Mozilla as a bug, verified as a FireFox DoS as early as November 2000.

I think this is really a common problem for web-developers. I’ve fallen into this trap several times myself (accidentally created an infite loop around my debugging alert()). But instead of aborting all scripts, I’d like to have something similar to the “A script on this page is causing Mozilla to run slow” message with the option to abort the script.

Another user writes:

The page in the URL (don’t open it unless you know what you’re doing!) “locks” the user in an endless stream of JavaScript alerts. There is no way out; closing the popup just opens a new one; UI is unresponsive in *any* place except the popup; you can’t cancel the loading of the page (or do something like ESC to stop the script) since the UI is blocked by the popup. The perfect anti-Mozilla DoS.