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
Only mozilla/netscape are truly cross-platform, and available to anyone for free. Don't let the choice be made for you!
A web-based application, developped in the second half of 1990ies, containing cludges for Netscape 4 and other workarounds. Some parts of the code - unfortunately the most important ones - were coded in a few night sessions, and need a major rewrite since at least two years.
Our new plan: A facelift that makes the application look a little better, and no more development except for a little customizing. It has to stay like this for at least a year. During that time, we will develop a completely rewritten version of the application, with a redesigned data model, a new modular approach, conforming to standards, faster, with a lot of new features, new ideas and new bugs.
(And because I am the one who does the main design and coding, I will make sure that all output is nice and valid HTML 4 with CSS. If browsers can't display it, it's not my fault. Netscape 4 is dead and will no longer be supported in the new millenium.)
Tux2000
Denken hilft.
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.
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.
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.
The development house I work at has a primary goal of our applications working on any of our major supported browsers. The major supported browser are based on Web statistics on the browsers our customer actually use. We dropped Netscape 4.7 finally a few months ago (thank god).
This seems a sensible approach, unless you can force you customer to use a specific browser, you need to make sure the app works on their browser. Standards compliance is one way to shoot for compatibility, but knowing the quirks of each browser, and testing on each browser, is the only way to ensure things actually work.
In general this approach results in standards compliant work that will work on future browsers. For example, when Safari came out we only had to make minor adjustments to our CSS files to make everything look perfect on Safari.
---
I support spreading santorum
As with any programming project there are multiple solutions...the hard part is picking the best one for your situation. I don't know what sort of backend technology you are using (php, .net, j2ee, etc.) but in my experience I've found that its best to create the front end in Dreamweaver because it creates good "cross browser" javascript and html that displays consistently across browsers. One rough benchmark is to design the page for Netscape 4. If it works there then it will work anywhere but in recent times I've started to give up on Netscape 4 because users really have no excuse to not downloading Firbird or Mozilla (if they don't want to use IE).
Another option you have is to store all the content as xml and apply an xslt transform to produce the HTML or to whatever standard you could possibly want in the future. This would also allow for customizability of interface for users. That would most likely require a large overhaul of your current system though.
I've built cross-browser compatible sites before and your best bet is to just keep the site as simple as possible with minimal bells and whistles invovling javascript, dhtml, and such. Flat html is the way to go and even then it gets hairy when Netscape 4 is invovled. I'm just glad that at my company I develop internal web apps for only IE 5.5+. It's one less thing to worry about when devloping which is always a good thing.
Been There, Done That. The company I work for builds an advanced online asset, work order, project, task, crm management system that uses CSS, JS, and XHTML extensively. If you're really set on doing this, plan on only being able to support two browsers (harsh, but reality). The latest Netscape/Mozilla and IE6 are the only two that are practical to support right now. IE5.5 and older versions of Mozilla/Netscape have such broken CSS support that you'll never get a complex CSS layout to look equally good and be almost 100% spec compliant.
:)
The almost 100% spec compliant comes in where if you begin using the overflow attribute in your XHTML or a div based layout you have no choice but to come up with an additional stylesheet for IE users that uses Microsoft's proprietary CSS expressions. Most of IE's absolute positioning and width behaviours are completely broken when using div tags. The good news is that you'll probably only need a few lines in the IE specific stylesheet and you can detect the user-agent and only include the tag to ref the stylesheet for IE if necessary.
Additionally, you'll find that IE6 and Mozilla/Netscape also differ slightly in their DOM behavior and that IE6's support for some 'standard' spec tags like the tag are broken in their behaviour.
The only other browser that even comes close at the moment to being able to render complex CSS layouts that use overflow, etc. is Konqueror. Opera's JS/DOM and lack of full overflow support prevents us from supporting them.
You would be far better off choosing a simple, functional design that uses Javascript minimally, uses HTML 4.01 transitional and a table based layout and very basic CSS1 than trying to do a complex XHTML, CSS2/CSS3, DOM layout. You'll lose much less hair
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
we will develop a completely rewritten version of the application
Obviously I don't know the details of your situation, but in general it's a bad idea to start from scratch again. It almost always looks like the best solution to the developers (myself included), because we always like working on new projects, new ideas, etc., but when you really sort out the risks and costs it's often hard to make the case.
First of all, time estimate: version 2 -- especially since you're adding new features -- will probably take as long as version 1 did to reach a useable level. Don't forget the common estimating pitfalls (like, "a year feels like an awfully long time") just because you're looking forward to working on fresh code. If version one took "the second half of the 90s" version 2 may not be stable (let alone feature-complete) before 2006.
Given that, do you really know what the needs of your customer base will be over the next few years while your application remains static? All of your new code will be useless in business terms until it reaches the functionality and stability level of the old version.
And because I am the one who does the main design and coding, I will make sure that all output is nice and valid HTML 4 with CSS. If browsers can't display it, it's not my fault.
Heh... of course by definition it *would* be your fault. Remember those "cludges for Netscape 4 and other workarounds"? Well, you still gotta do browser-compatibility testing (check your server logs to see what browsers are most important), and you might even have to break standards to work around bugs -- mostly bugs in IE, I'm guessing, since it looks like IE6 is going to be out there for a very long time.
My point: usually the better solution is to make your upgrades and improvements step by step -- even if you end up replacing ALL of the code when you're done! You don't have to release every step (especially since many of them won't change the user experience at all) but you do have to keep the whole thing working.
If you can automate testing you can start really tearing into stuff. Once you've wrapped good interfaces around some of those chunks of ugly crufty code, you can sit down and write a replacement component from scratch. At the end of the day, drop in the replacement, run the tests, fix bugs, and go home. Once you have the mess tidied up nicely (and still working) you can start changing functionality.
I don't know what language you're working with, but obviously a good IDE or editor will help immensely with this stuff.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
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
I applaud you and your organization. It's a hard choice to go standards-compliant, but for the survival and evolution of the Internet it is the only viable choice. There's some amazing stuff you can do with plain CSS (menus without ECMAScript, anyone?), and a little ECMAScript so there's no reason why any proprietary extensions are needed.
Eventually when browsers can rely on users producing correct code, their bloat will be reduced and they may see great speed gains.
I have personally found Opera to be the most-compliant in average use. Moz would be more so, but there are some basic things in CSS that disturb it. IE is getting better.
Marxist evolution is just N generations away!
Designing with Web Standards was recommended here, in a recent discussion on DHTML and javascript.
While the review I've seen on Amazon point out that it's more of an evangelical book (with a decent explanation of the technologies involved) than a technical roadmap, the table of contents (pdf) looks good. It seems that the book addresses the real world issues of refreshing an existing site (what to update vs. what to leave as-is) and instead of flash-bashing, a somewhat objective analysis of where it belongs on a site. I haven't bought it myself, but we plan on refreshing 18 global sites sometime soon (with a team of 3), and hope to do them in a way that expands our use of standards without having to burn a million hours grepping out <font> tags.
Really, I don't see a question there...
Extremely high priority, and yes.
One big reason: lower total cost of maintainability.
1. Remove any test for "what browser the user has". A lot of sites would improve considerably if they would just send their IE-specific stuff to any browser. Often the alternative code is broken because they never test it, or worse it is some crap that says "You need IE". This also forces users to change the browser id to IE, which is throwing off surveys as to browser popularity.
2. Just do all your work with IE if that is what most people have. Try the site now and then in Mozilla, Opera, and Safari, which will get most of the alternative engines. Just make sure it is readable and somewhat usable. It really should not be all that hard.
I always thought there's more to this, and this expression doesn't say it right. It should be "content, structure and aspect". Content is the actual (linear) content; structure is the way it gets displayed in 2 dimensions; and aspect is the final touch (fonts, colors). Usually people bundle the last two together, but as a fellow poster said above in real life you have to separate them eventually doing something server-side or using XSLT.
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
Jesus Christ, I'm so tired of these Air Force web apps that don't work or only half work in Mozilla Firebird. CAMS, CBTs, PWRR Manager. Oh, and yesterday I found that the IDEA program website sends all their ASp generated web pags as text/plain.
Phillip
But I've opted to use XWT for the simple reason that browsers are NEVER 100% compatible with each other or anything else. I decided pretty quickly that until these issues are ironed out you're going to be heading for a whole bunch of trouble. XWT provides web applications on any browser by d/l a jar to the browser, it renders locally, uses xml-rpc over http for server communication and means you can reuse any java code that you have made/can find. It's not perfect, but it's a whole lot closer to what you need than trying to be "standards compliant".
Why don't you still use JavaScript, however use cross-browser code? JavaScript conforms to ECMA 262 - and any standards compliant browser will understand it (more than will understand JScript or ECMAScript).
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)
...our app is only native to IE 5.5...
This is pure crap. The browsers wars were in full swing with MSIE 4 and Netscape 4. By MSIE 5.5 - the air had cleared. Standards were released LONG before MSIE 5.5:
CSS Level 1 - 17th Dec 1996
HTML 4 - 18th Dec 1997
CSS Level 2 - 12th May 1998
XHTML 1 - 26th Jan 2000
These standards were complete, and have been for many years. HTML/CSS1 have been complete standards for many years, and are honoured pretty damn well. XHTML and CSS2 are nearing the same level of support.
Whilst I support your move to standards compliance - it sounds like poor research on behalf of dogas' company is to blame. Unless of course, the application coding began before 1998.
http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dnie60/html/cssenhancements.asp
I have found that IE really loves fucking up when reading the DOCTYPES. The W3C specification lists the DOCTYPE definition as using three lines (and in my experience won't validate otherwise - at least when writing XHTML) but IE decides that is incorrect and will ignore the definition thus NOT switching to strict mode and totally screwing up the rendering of your document.
I fully agree with using HTML/XHTML strict mode only. It will only benefit you down the line. If it is a personaly site I tell the IE users to get over it or get Mozilla. If that is not an option I just rethink my layout so that all browsers will render the page fairly accurately in strict mode.
Certainly there are situations in which server-side technology is necessary to generate the page content from the data sources, but it's pretty amazing how well you can separate layout and presentation from the page content simply by using a decent XHTML page and good CSS. A great example I recently discovered is the cssZenGarden. The site provides a basic XHTML page with no real presentation information. When viewed without the CSS it's quite bare text, no images, just some various levels of headers and some bulleted lists. However, webdesigners are challeneged to create unique/interesting designs simply through the use of CSS (no modification of the XHTML is permitted). A few of my favorite designs are sub:lime, Not So Minimal, and Burning , but be sure to check out the others.
And what happens when tinfoil-hat-wearing paranoids like myself, who have all scripting turned off, visit your site?
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
X-browser support is paramount in my organization. We develop our apps to run on IE, Mozilla and Netscape, using platform independent DHTML components like Milonic's DHTML menu and the cool new WebTabs DHTML tab widget . The need for us to supply Opera support has also been growing in the last year.
You cant use the app? Er.. that's like saying "OK, so what if i dont put petrol in my car, how am i supposed to drive it then?". Besides, most applications are not built for tinfoil hatters.