HTML Sucks for Rich Web Applications
This post started out as a reply to a work colleague’s article - Ben Teese’s CSS Layout Sucks for Panel-Based Web Apps- but it eventually expanded out into such a large little rant that I thought it would be better suited to my blog. So here it is.
Trying to Make CSS Suck Less
Ben, since I come from a web development background … I hear ya. At my last job, XHTML and CSS were our primary building blocks for web sites and applications. By the end of my time there, we got pretty good at building CSS layouts - but there was always some little exception, some little element that didn’t *quite* look right due to some weird CSS nuance. Worse, client change requests could often be downright painful for exactly the reasons you mention: recalculating measurements, layout “knowledge” scattered throughout the stylesheet(s), etc. Worse, trying to make it work in every version of Firefox, IE, Safari and Opera? No deal. Not without many, many painful hacks. Despite being a standard for *years*, most vendors’ implementations of CSS are half-assed at best and will remain so for the foreseeable future.
Regarding the DRY problems mentioned with CSS: a half-baked idea of mine was to use $TEMPLATE_LANGUAGE to generate CSS files as part of the build process to alleviate some of the pain. I never actually got around to this myself, but others seem to be scared of this approach. Why? If your template engine provides you with variables, conditionals, loops and a means for performing calculations in your CSS templates why aren’t you generating your CSS using Velocity, Erb or even PHP!?
HTML and Rich UI Don’t Mix
All gripes aside, when it comes to the web I remain a somewhat stalwart supporter of CSS and XHTML - if only because tables clutter up HTML like a dog. However, I do think that the HTML hemisphere of the web world is starved for choice: both tables and CSS suck in their own hairy little warty ways. Tables suck because they’re awful to maintain and effectively render screen-readers useless. CSS sucks because it’s error-prone and void of expressive syntax & semantics.
The web world should be paying a lot of attention to rich client solutions such as Flex and Silverlight. Flex would be my first choice for a client platform if I had to start building a web application tomorrow. In fact, I’d go so far as to argue that the decision between CSS/tables for web applications is moot - the real problem is the current trend of using HTML as a medium for rich web applications. GWT is a perfect example of the ridiculous lengths we’re going to in order to just make things work. It’s a godawful hack around a limited technology.
If your requirements permit it, don’t try to make your HTML jump through hoops - opt for Flex or Silverlight instead if you plan on having a truly interactive UI. If you’re stuck with HTML, inexpressive CSS stylesheets can be augmented with a template language to reduce the amount of knowledge being spread throughout your code.
Of course, when I make my browser window smaller, your text doesn’t flow.
Instead, the ends of the lines are cut off. This is a very common mistake that
newbies make. Please learn HTML and fix this.
Yeah, I’m really starting to wonder why so many of us gave up on rich client apps to begin with. The web automatically made linking easy of course, and gave us cross-platform for free, but rich client apps can do the same with Java and (to a lesser degree) mono on the front end, being driven by RESTful backends which would make them more “web-principled” than most web apps.
Hi Eddie - what browser are you using? It works fine for me in Firefox. Perhaps you’re referring to the preformatted text?
Anyway, I’m not looking for an argument: by all means, use HTML where it makes sense. If you disagree with what I have to say, feel free to continue hacking around HTML’s shortcomings despite better technologies being available for rich application UIs. I really don’t know why the HTML die-hards are so dogmatic about using HTML for *everything* on the web: the simple fact is it’s not always suited to certain types of application - even if that application happens to be delivered over HTTP.
On the topic of this site’s HTML, I couldn’t possibly take the credit for this wonderful design. It’s a Wordpress template called “Palaam” by Sadish Balasubramanian - a man with far more aesthetic sense than I could ever muster. I replaced the banner image with something a little less American, but other than that I’ve barely touched it.
Steve: that’s the beauty of some of the stuff that’s coming out of Adobe, Microsoft and Sun - the presentation tier is *designed* to be able to take advantage of modern, more complicated service tiers whether that be via XML-RPC, SOAP or REST. You’re largely forced to separate your presentation code from your business logic because the technology promotes such an architecture.
Hi Tom,
Would you mind pointing me to the $TEMPLATE_LANGUAGE you mentioned? I’m interested and google doesn’t want to tell me. She’s bitching something about me fondling other search engines….
Kind Regards,
Wim.
I too am waiting for the DHTML killer. I have been watching Silverlight with some interest. But while WCF is getting solid, WPF is soft and squishy. I am not sure what the solution is. I try and convince clients that Web Apps (which is what I do) that require the latest IE is to be expected.
I have avoided eCommerce which would necessitate cross browser functionality up to now but my current client’s CEO uses (gulp) Safari and seems to want him and the other two Safari users to be able to use his web app.
HTML was never meant to support the kind of tight, pixel perfect, requirements some clients want. With that said, it’s no excuse for an ugly UI.
Soooo……perhaps this is just co-miseration.
Oh yeah, and “Eddie Pasternak”, get a life. This is a blog fer cryinoutloud. Jeeeesh!
Hi Wim - the template language you will find most useful probably depends on the platform you develop for. I’d recommend taking a look at Apache Velocity (Java), Erb (Ruby) or even the command-line PHP interpreter. All of these can be used to generate CSS, although they’re more commonly used to generate HTML. Please be aware of the tradeoff of complexity for flexibility when using template languages to generate CSS.
Aaron: Exactly. HTML is being stretched and contorted in the absence of a similarly ubiquitous alternative suited to pixel perfection. Worse - developers, employers and end-users often pay the price for it.
All that said, I’m excited to see what happens in this space.