I’ve written earlier about user helplessness regarding any javascript alert boxes which keep popping in one tab of the browser, thereby jeopardizing the whole browser window.
I just found by chance that Google Chrome indeed handles this elegantly: On the second popup for any page, it displays this neat checkbox right below the message:
This is something that Mozilla folks decided “could wait” for the past eight years?
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
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 