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.
Standards compliant pages? Why don't you just ask CmdrTaco et al?
:-)
*cough*HTML 3.2*cough*
The revolution will not be televised. It won't be on a friggin blog either
Aiming for standards compliance is always a good thing, IMHO. However, you will find that you will have to make compromises along the way given that not all browsers comply with the standards to the same degree.
:-)
About 2 years ago I was involved in redeveloping our proprietary Web app to comply more with standards. It was a huge uphill battle to try and convince management that this was what they wanted. Complying to standards meant we had to drop or significantly change features of the app to ensure that it would work cross-browser and remain accessible.
My main advice is that whenever you ahve to make compromises on functionality and compliance, try and veer to the side of compliance. Your customers will (hopefully) thank you for it in the long run. Especially, if like me, they don't use IE or Netscape
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.
As much as I understand the underpinnings of that statement, You cant go around making comments like that. Only coding for mozilla /netscape is just as lazy and ignorant as the idiots that only code for IE. The trick is to build for compliance, have a nice clean design and test cross platform and cross browser as much as possible. Iron out the bugs and make comprimises (usually graphic design) where there are style problems you cant fix.(Degrade gracefully)
I will say though its about time people gave up on NS4.7 it is the browser from hell!
Electronic Music Made Using Linux http://soundcloud.com/polyp
I'd say opera is pretty crossplatform, too. Not as free as mozilla/netscape, but it's beginning to emerge as the true and only choice for smartphones and communicators/PDAs.
So I guess it's only a matter of time before IE-junkies realizes that it might be smart to check out their shit in browsers that doesn't make up their own standard as they go along
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.
In what tags is the 'baz'?
You mean "elements", not "tags".
unrecognized CSS tags will just go unnoticed
There's no such thing as a "tag" in CSS. Are you talking about rulesets?
The Zen Garden is an exercise in graphic design, and a rebuttal to the myth that standards-based code is ugly. Most of the entries are highly fragile, not very usable or accessible, and are NOT suitable to use as examples for production websites.
(emphasis mine - see bottom)
I defintiely agree with the parent here. Try to make sure it's viewable on as many browser/platform combinations as possible. Yes, maybe the newer ones will still look prettier, but as long as older browsers at least display the basics.
Testing under IE, NS/Moz (multiple platforms), Opera (if possible, and even Lynx means you can see which ones display it as you want, which fail but still display the text, and which bomb out totally (see bottom).
If using CSS, testing how it looks when you eliminate the stylesheet is always a good idea. In fact, designing the layout before even adding the Styles means you know that it's at least legible in "plain" format (the "KISS"/"Get it Right in Black & White" methods)
Oh and personal peeve. Never hardcode your font-sizes and the absolute width of your pages. There's nothing worse than a page which takes up about half of your 1280x1024 screen and displays in a tiny little 10pt font.
Yes some browsers cab nabdate a minumum font-size, but too many sites also implicitly state sizes of tables and positionsing - and therefore readable font0sizes start to ovelap badly.
Oh yes. I gave up on Netcape 4.x on my site a couple years ago. Not only did it not display my styles properly, but it couldn't even fail cleanly.
TiggsEven Lynx would show a style-free version of my pages, whereas NS4.x actually lost half the text.
Tiggs
"120 chars should be enough for everyone..."
Web standards are important from just an interoperability standpoint.
When you're sure that everyone uses the same browser, it means you can use a 'standard' that works for you. But enterprises are increasingly called to support a wider range of hardware and software.
Using data standards is a key component to interoperability. The more universal the standard, the more likely the systems will interoperate. That applies to any enterprise and any system, from CD recording format, to Unicode, the NATO Phonetic Alphabet, to Webstandards, to the Incident Command System.
Heck, Law School's main purpose (besides removing your soul) is to teach you the standards and processes of working the legal system. For the most part, the Law is the system that ensures the interoperability of property (heh).
You can certainly roll your own standard, or stick to an old one, but you run the risk of not being interoperable. In a world of increasing interdependence, you will probably want to implement your own solution, but ensure that the "public" parts are interoperable.
My father is a blogger.
Regarding web applications: I believe it's always good to support multiple browsers - even if you don't need to because you write applications for a closed user groups, that uses only a known browser.
As soon as you start to automatically test your web applications with scripts (e.g. HttpUnit) there is suddenly another browser: The test script. The more browsers you support from the beginning, the higher the chance that you can easily automate tests for your application.
Your mileage may vary with read-only sites, but others have already elaborated about this.
Only latin is a true cross-cultural language. Latin texts have been written since the time of the Roman Empire.
Don't let the passing fad of the "English" language make a choice for you. Target the american market with latin pages!
Conformity is the jailer of freedom and enemy of growth. -JFK
Do yourself a favour and go for the Strict versions of the (X)HTML markups directly. Don't waste time with Transitional markup, because you'll be creating the same old tag soup that all the browsers (old and new) will happily eat in quirks mode. When the day comes (after your transition?) and you finally set that DTD to Strict, all your pages will be blown to bollocks because the browsers will now render them in strict standards compliance mode.
Why bother? You can't really benefit from Style Sheets in quirks mode anyway? Remember, the rendering is completely different between quirks and strict standards compliance mode, and with good reason! The browser developers finally had a chance to do it right with strict standards compliance mode rendering because their implementations are made from scratch from the same thorough W3C spec. With quirks mode they just use their old layout engines from back during the browser wars.
You'll benefit greatly from the Strict versions of the (X)HTML markup. While taking full advantage of Style Sheets and ridding your old (X)HTML sources of the deprecated presentational tags, you'll end up with more easily maintainable (X)HTML sources. Think about it, most of your pages might already consist of 80% tags related to presentation. When you have removed these from one page and put the presentational information in an external style sheet, it won't be that much of an effort to apply these resulting style sheet rules to the rest of your pages. Why? Because most of the time you'll just be removing deprecated tags. Sure, there's still a bit of structure to deal with, but it's a worthwile task.
I've written "(X)HTML" in this comment a couple of times now. As I see it, the Transitional/Strict issue is infinately more important than the HTML/XHTML issue. When you have Strict HTML markup it's really a no-brainer to convert it to XHTML, because it's pretty much about syntax, well formedness. Try taking a look at W3C's HTML compatibility guidelines for XML. If you do yourself a favor and explicitly use closing tags, etc. you can convert your HTML to XHTML with a couple of regular expression substituions. That's pretty much it. Bottom line: the main difference between the Strict versions og HTML and XHTML is largely syntax. (There are some elements of your DOM that require special attention with respects to applying CSS, but this statement is essentially true.)
If you care about having the same result shown accross browsers (especially IE), then watch out for XHTML.
(Borrowing a bit from a previous comment I made here on /.) IE can be a stick in the wheel, because it
ignores the XML declaration in XHTML documents beginning like this:
<?xml version='1.0' encoding='iso-8859-1'?>
IE expects to encounter the DOCTYPE first, which doesn't make sense - and would be non-valid XHTML markup. When IE encounters the above declaration it throws itself into quirks mode, unconditionally!
Sure, the XML declaration is not strictly required, however if you read the W3C XHTML spec it says:
An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.
Another point. XHTML pages should really only be created for the purpose of being served - by your web server - as application/xhtml+xml. See W3C's document on XHTML Media Types. IE doesn't support the application/xhtml+xml media type, and this together with the above mentioned deficiency makes for quite a showstopper with respects to the adoption of XHTML - it's sad, really.
Mozilla and Opera will handle XHTML documents served as application/xhtml+xm
What would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
I'm the lead developer of a commercial web-based document management system. It has a huge PHP and javascript codebase and runs well on any modern browser (IE 5.5 and up, Mozilla 1.0 and up, Konqueror, Safari, etc). Here is the most valueable piece of advise that I can give you: Make the developers use Mozilla. Seriously, code that works on Mozilla is probably going to work on IE, but the reverse is not true. Using Mozilla will force standards compliance in the development cycle so that it won't have to be bolted on later. They're going to whine and bitch and moan, but make it happen. You'll save hundreds of thousands of dollars down the road.
Matthew
www.para-docs.com
/. finds me to be 20% Troll, 80% Funny