Slashdot Mirror
Developing a Standards-Compliant Web App?
dogas queries: "I work for quite a large company that is creating quite a large web-based enterprise-level application. We've been in development for a long while, and currently our app is only native to IE 5.5. At this point it would take a *lot* of effort to bring our app up to to be Standards-compliant. Now management wants our app to be more flexible, such that if the customer wants to customize the look-and-feel, it won't be a major undertaking that will kill the structure. Naturally, we're switching to a CSS-based layout, ripping out the IE proprietary Javascript in favor of ECMAScript, and bringing the whole app to XHTML 1.0 Transitional compliance while we're at it. Since we started coding the front end at about the time of the browser wars, we didn't have the luxury of planning to use the W3 standards (especially since they were not complete, and browsers weren't honoring them anyways). I'm wondering what type of priority creating a standards-compliant web app is in other companies, and if that priority is being raised given the benefits of creating pages that separate structure from style from behavior."
Standards compliance is always a good thing. But dont for a moment think that it means crossbrowser/platform compatibility. Nothing beats actually testing your application on at least the most popular browsers on the most popular platforms. More often than not you will have to make comprimises in order to achieve compliance and compatibility at the same time.
Electronic Music Made Using Linux http://soundcloud.com/polyp
Separating content and presentation would be a good thing. But the currently supported web standards (HTML, XHTML, JavaScript, DOM, CSS) don't let you do it by themselves. To achieve that kind of separation, you need to use some kind of server-side technology and you need to generate preference-specific HTML anyway.
But even if you manage to do that, it's not clear that it's a good thing: regular folks don't feel all that comfortable authoring abstract markup. They want to write their web pages in something WYSIWYG and they will (trust me) manage to encode lots of assumptions about how the content is ultimately presented.
So, you have to pick some kind of middle ground: not too much user customization but some (maybe light/heavy). Not too much server side separation of content and presentation, but some. Not too much JavaScript and CSS, but a little may help you out quite a bit. Etc.
If this application is visible on a public website, making it standards-compliant is a major step towards making it accessible to the partially sighted, blind or motion-impaired. The company may also have staff that fall into this category. Making the site accessible in this way could even be a legal requirement (depending on your country) and it's just the right thing to do anyway.
What are you aiming for - compliance with the W3C specifications, or separation of content and presentation?
You can use all those nasty <font> elements and still adhere to the specifications. Use HTML 4.01 Transitional or XHTML 1.0 Transitional (following Appendix C).
The benefits of adherance to public standards means increased compatibility with present and future browsers, and reduced business risk.
Separation of content and presentation is slightly more risky, due to buggy browsers, particularly Internet Explorer. If you are going to do this, make sure you have somebody familiar with CSS first that knows the limitations of the various browsers.
You may want to do it in two stages - first separating out the minor styling, such as fonts and colours, and then getting rid of the table layouts when you've laid the groundwork.
Older browsers like Netscape 4.x will almost certainly cause you major problems. The normal technique these days is to hide stylesheets from them using their bugs against them. That way, they get the plain, unstyled HTML page (which should still be functional if you are doing things right).
Newer browsers have something called "doctype switching". Make sure you trigger standards-compliant mode so that they are at least trying to do the right thing.
Don't rush headlong into CSS if you've not spent much time with it before. There are plenty of things you can do to screw up a page (e.g. pt or px-sized fonts) that aren't immediately obvious to the newcomer.
Luckily, the things I'm working on are fairly new, so we'd need a pretty strong reason not to use the relevent specifications and separate content from presentation.
One of the major advantages of going "standard" is simply the correctness of the XHTML/HTML you'll send to the browser; no missing tags, no misordered, no proprietary tags will do 80% of the job. The W3 validator is your friend.
Most of the trouble with "IE-enhanced" pages is the interpretation of errors by parsers. If I write:
[p][strong]foo[em]bar[/strong]baz[br]
In what tags is the 'baz'? depends on who reads it, mmh?
Except for NN4, unrecognized CSS tags will just go unnoticed for lower-version browsers, so that if your structure is OK, it should be usable for most browsers.
You might want to test with Mac's browsers (IE5 at least) to make sure your ECMAscript works; some core methods are missing.
And, should you need an incentive to go table-less, there is a great presentation that summarizes the advantages.
The css Zen garden is a great example if you want to show colleagues why separating presentation from content is a neat idea.