Does a Complex Web App Really Need Clean Markup?
07-05-2009 12:31 AM permalinkI found myself pondering this question today in a response to a status message
While I do really like the ExtJS APIs the generated markup makes me cry. A button should not be made of multiple 's. #fail
I had this same gripe a while back when I was hacking facebook with greasemonkey. I felt like facebook was flouting everything we've learned about web standards and structured content. Everything is a <div> wrapped in multiple other <div>'s. In fact, most of the content is generated with Javascript. With their last major redesign, Facebook eliminated many of the explicit page reloads. Now they literally pull in the entire page with ajax and regenerate the markup. And a couple of weeks after I finished my greasemonkey script, they changed the interface again and broke it!
But then I started really considering what apps like Facebook are trying to accomplish. They're task-oriented, not content oriented. Most of Facebook requires a user to be authenticated. fb is more concerned about people coming to the site, not robots. And even considering that, the public pages still manage to rank pretty high in Google. Search for marco rogers and you'll get my profile link as the first result. Even though the page is pretty much entirely generated with javascript. Today's web apps put the application first and the web second. Many of them are basically meant to be portable desktop apps. When was the last time you cared how the visual elements in MS Outlook were put together?
Unless I miss my guess, the markup spit out by fb is probably tied pretty closely with some proprietary content framework they're using to generate the pages. And generating semantic markup with javascript is no mean feat. If you can get away with every element being a <div> or <span>, you're almost certainly doing yourself a favor.
That's how I read the promise of Ext JS.
Ext JS is a cross-browser JavaScript library for building rich internet applications.
Ext JS is offering to do you that favor. You can build those complex applications with an interface that will be consistent in functionality as well as look and feel. As long as you're not worried about search findability. And if you're building a web application, you should really ask yourself that question sooner rather than later.
8 Responses to this Article
leave a comment
Facebook also tends to suck for screen readers
True, and that's not really acceptable. But the question about accessibility in modern web apps should be answered separately I think.
It matters how the elements are put together because it matters for accessibility. Semantics and accessibility go hand in hand, and are very much a part of this question.
Sacrificing something like that because you are too lazy or inexperienced a programmer to create a helper method that can easily create semantic elements instead of nested DIV after nested DIV is just lame and born of a fundamental lack of understanding of how plain 'ol hand written markup should be written.
@S.G. Chipman - I tend to agree with you in that semantics and accessibility go together. But, they don't always have to. You could do something like: http://www.w3.org/TR/wai-aria-practices/ and not have semantic markup but have it be accessible.
That said, you can overwrite the generated html with ExtJS too by using XTemplates.
@S.G. Chipman I knew I'd get ripped a new one for this. It's difficult to present a case that seems to advocate dismissing accessibility. But that's not where I was going with this at all. I think making a complex web app really usable for disabled users is a hard topic in itself. It won't be solved simply by outputting semantic markup, although that is a step in the right direction. And with that being the case, maybe it doesn't make sense to make that part of your primary development effort. Maybe it makes sense to have a separate engine that delivers specialized content for accessibility tools. Similar to delivering mobile-specific content.
You know way more about accessible web apps than I do, so I would welcome your input if you think that's a ridiculous idea. I'm just not sure that requiring all generated markup to be semantic out of the gate is the only solution.
@Nick - sort of. For example, screen readers have the ability to scan a document for headings and lists and the like and allow the user to skip directly to that content. You can direct it to read all of the headings to you and then drop right down into the content that interests you, rather than the ponderous task of waiting for the screen reader to get to what you want on its own.
ARIA exists to lend semantics and accessibility to objects in a document that would otherwise have none via the role attribute. I'd say its best to use them both.
@Marco - I am a big fan of the concept of "One Web"; I don't agree with serving specialized content to any device if it can be at all avoided. Accessible, semantic markup isn't just good for people that use screen readers, its good for everyone.
Back to your original point - other than being tied to a framework that outputs garbage markup, why exactly would someone shun markup the way it should be written for divitis? What are the benefits in your mind, specifically in regard to your statement that getting away with DIVs and SPANs is doing oneself a favor? How so?
@steve - "why exactly would someone shun markup the way it should be written for divitis?" My comment on doing yourself a favor was specifically referring to generating markup with javascript. It's not being "written" it's being generated. ExtJS, Facebook and many other client-heavy apps do this a lot and unless you do a lot of planning or write a lot of helper code, it's not easy to make everything nicely semantic. There are js templating solutions, but all of the ones I've tried probably wouldn't meet the performance requirements of an app like fb.
As for the idea of "One Web", I haven't really bought into that. Mobile Safari on the iPhone is pretty nice at rendering full traditional web pages. But it's always a lot nicer when I get an iPhone friendly version that is tailored towards the limitations of the device I'm using. For instance, hiding images and irrelevant side content and simplifying any task workflow (Try ordering a pizza from papajohns.com. They're iPhone version is awesome!) I guess the question I'm asking is what is the downside of taking this route for accessibility as well?
We've been breaking the web for decades, that's old news. Ext-JS is one of the latest attempts to make the web platform feel more like the desktop application experience. Browsers just quite frankly aren't designed for this, but I hope that will change in time.
That said, I think the biggest concern is the carbon-footprint that Ext-JS is responsible for. With all those HTML elements and Javascript-driven UI, machines probably consume tons more electricity than an equivalent desktop application would. It's time someone worked on a web-protocol specifically designed for interactive web applications. Enough is enough.
Add Your Comment