Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming The Internet IT Technology

Developing a Standards-Compliant Web App? 85

Posted by Cliff from the dropping-the-platform-specific-features dept.
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."
This discussion has been archived. No new comments can be posted.

Developing a Standards-Compliant Web App? More

Developing a Standards-Compliant Web App?

Comments Filter:

  • Standards Compliance (Score:5, Insightful)

    by polyp2000 ( 444682 ) on Tuesday January 27, 2004 @06:08AM (#8098244) Homepage Journal
    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.

    • Re:Standards Compliance (Score:4, Insightful)

      by ajagci ( 737734 ) on Tuesday January 27, 2004 @06:30AM (#8098322)
      Standards compliance is always a good thing. But dont for a moment think that it means crossbrowser/platform compatibility.

      Standards compliance clearly does not mean cross-browser or cross-platform compatibility: almost all standards define certain behaviors as "implementation dependent" or "undefined", and they often leave many issues completely unmentioned (and hence undefined).

      In order to write something that works cross-platform, it doesn't just have to be standards-compliant, it also has to avoid all implementation dependent or undefined effects in the standard. Depending on the standard, that can be easier (Scheme), moderately difficult (Java), or very hard (C, C++).

      • Re:Standards Compliance (Score:2, Interesting)

        by p3d0 ( 42270 )
        You're right, of course, but I think she was talking about web applications, where most people's browser doesn't support the standards. This problem is far worse with web apps than with Scheme, Java, or C++, although the latter did suffer severely with this problem a while back.
    • On the current project I'm working on I test on Mozilla 1.5 and then test on IE 5.5. IE has problems rending standard HTML but with minor tweaks the pages appear properly on both browsers.

      This works for me!

  • 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 ve

    • 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 proba

  • separating content and presentation (Score:5, Informative)

    by ajagci ( 737734 ) on Tuesday January 27, 2004 @06:26AM (#8098309)
    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.
    • So what exactly is your advice? Basically do a bit of everything, but not too much? I don't see how that's helpful.

    • Re:separating content and presentation (Score:5, Insightful)

      by BigJimSlade ( 139096 ) on Tuesday January 27, 2004 @10:04AM (#8099606) Homepage
      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.

      I'd have to disagree with that. Most of the standards movement for web design focuses on "semantic markup". Only headings, paragraphs, and the like should be included here. No fonts, colors, etc. This is your content. Yes it has tags, but when using XHTML 1.0 Strict it is also XML, meaning that an XSLT could be used to generate that content from some XML source on the server if necessary. Using CSS to do placement & styling of elements is very feasible for 95+% of the market.

      As others have mentioned, standards compliant != cross-platform. However, standards compliance is very much supported by the technologies you mentioned.

      Additional reading:
      A List Apart [alistapart.com] - lots of articles on integrating useage of standards-based web design
      Jeffery Zeldman's Weblog [zeldman.com] - a big proponent of web standards
      • Uh, no. A web document is currently a three-part ordeal:

        1. Content. This is your data, text, articles.
        2. Structure. This is the XHTML. Tables, links etc.
        3. Layout. This is CSS. Style, display and layout.

        One may need server-side stuff for the content part.
      • I'd have to disagree with that. Most of the standards movement for web design focuses on "semantic markup". Only headings, paragraphs, and the like should be included here. No fonts, colors, etc. This is your content. Yes it has tags, but when using XHTML 1.0 Strict it is also XML, meaning that an XSLT could be used to generate that content from some XML source on the server if necessary. Using CSS to do placement & styling of elements is very feasible for 95+% of the market.

        You're missing my point.
        • I guess I'm missing your point too.

          Have you seen the CSS zen garden? [csszengarden.com]

          100s of attractive layouts all using the same XHTML document.

          • While those designs vary color and text a lot, they actually illustrate how primitive CSS is: almost all of them are single column text with some stuff shoved into the margins.

            Some of the style sheets have deep knowledge about the content (i.e., the individual paragraphs). Almost all of them are highly resolution dependent and fail to render correctly for fonts whose metrics differ from those they assume. Many place things incorrectly at absolute coordinates and don't work correctly at small or large win
        • You don't know much about CSS, do you?

          The same XHTML document can be styled in completely different ways. Parts can be moved around, floated, made to disappear, etc. The only thing you need is to mark up each thing as what it is (paragraphs, blockquotes, headers, etc).

          And tables are a thing of the past, by the way. Tableless design is one of the things that allow for this kind of flexibility.
          • You don't know much about CSS, do you?

            You don't know much about layout, do you?

            Parts can be moved around, floated, made to disappear, etc. The only thing you need is to mark up each thing as what it is (paragraphs, blockquotes, headers, etc).

            Yup, but that's not what separating content and presentation means. In order to separate content and presentation, you'd have to be able to write interesting style files that work for lots of different kinds of content. But the set of CSS styles that actually wo
            • Ok. You really don't know what you're talking about, do you?

              Admittedly, you goaded me into looking for info on how LaTeX works (I had used it, but didn't study the format up close). It tends to be more strict than XHTML/CSS actually, and does require good markup of a document. If you want to see some reference, check out this document [cam.ac.uk].

              CSS is very flexible for making layouts. Please suggest what you think LaTeX can do that CSS can't. Prior to that, though, you may want to take a look at the spec [w3.org] (and yes,
              • Please suggest what you think LaTeX can do that CSS can't. Prior to that, though, you may want to take a look at the spec (and yes, most of that stuff does have good support, even in Explorer).

                Here are some things:
                • Write a style sheet that takes text, breaks it into screen sized pages.
                • Write a style sheet that breaks text into a sequence of columns of fixed width and with the same height as the viewport, letting the user scroll horizontally through the columns.
                • Write a style sheet that puts text into
                • Ok. Those things can't be done with pure CSS. You have a point there. They can be done with a combination of javascript/CSS, though (that last one would require server side technology), but they're actually kind of pointless.

                  What you're describing is stuff that graphic designers love and wish web pages could do. It's also stuff that doesn't work for the internet. You can't assume that everyone uses the same software/hardware, or that everyone has X font. The spec states that people should be able to custom
                  • Ok. Those things can't be done with pure CSS. You have a point there. They can be done with a combination of javascript/CSS, though

                    Oh? Give it a try. A lot of them involve some pretty tricky optimization, not the kind of thing you could do in JavaScript even if JavaScript had all the information actually available to it.

                    What you're describing is stuff that graphic designers love and wish web pages could do. It's also stuff that doesn't work for the internet. You can't assume that everyone uses the sam
                    • Ok. I'm sorry I jumped into this with an attitude. You seem to have thought this out well.

                      Although your statements about using columns in particular are true for CSS, I think you're selling the standard short. Check this out:

                      This is my site [overcaffeinated.net]
                      This is the exact same markup, when passed through a different stylesheet [overcaffeinated.net]

                      Both of those use the same markup. One is ~800px wide, the other 320px wide. This is a demo I'm preparing for a tutorial on some CSS techniques. The title images (Rants & Articles, News, a
                    • Both of those use the same markup. One is ~800px wide, the other 320px wide. This is a demo I'm preparing for a tutorial on some CSS techniques.

                      Yes CSS is useful. There are quite a few properties that can be abstracted out of the content using CSS (and even more with JavaScript). My point is just that CSS is still pretty far away from the kinds of separations of style/content that other common typesetting systems routinely achieve.

                      I didn't add extraneous divs to achieve the second layout, just structu
      • Mod parent up!

        I cannot stress enough that the 'future of web design' is pretty much now. (lack of W3C standards-compatibility in IE not withstanding)

        If you keep your xhtml to just raw DIV tags and data, you force yourself to use the CSS code for layout. Once this is done, you achieve an unprecedented degree of flexiblity in design, as you can modify the page in broad strokes simply by altering the CSS.

        For those interested: A perfect example of this is the CSS Zen Garden [csszengarden.com]. Click on any of the styles l
    • 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.
    • 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

  • Accessibility (Score:5, Insightful)

    by andrewmc ( 88496 ) on Tuesday January 27, 2004 @06:30AM (#8098323)
    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.

    • Re:Accessibility (Score:3, Informative)

      by __past__ ( 542467 )
      Making an accessible web app also makes it more usable for people without any disabilities actually, not to mention for non-people like search engines. The WAI guidelines [w3.org] are really a collection of best practices for web development - Even if you don't need to put up a triple-A conformance label on your app, it is always good to keep them in mind.

      The W3C WAI resource page [w3.org] has pointers to everything you need to know. A popular tool that helps evaluating web accessibility is Bobby [watchfire.com], but unfortunatly it isn'

  • Ask Slashdot? (Score:2, Funny)

    by Joff_NZ ( 309034 )
    Standards compliant pages? Why don't you just ask CmdrTaco et al?

    *cough*HTML 3.2*cough* :-)

  • It's a Noble Aim (Score:3, Interesting)

    by icerunner ( 587505 ) on Tuesday January 27, 2004 @06:36AM (#8098336)
    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 [w3.org].

    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 :-)
    • Parent is correct.

      It's nice that some of us can live in fantasyland where the theories of standards compliance are the only guidelines used to create the framework or "demo", before they finally hand the project off to the unlucky grunts who have to actually make it work in the real world.

  • Don't confuse the two! (Score:5, Insightful)

    by JimDabell ( 42870 ) on Tuesday January 27, 2004 @06:37AM (#8098338) Homepage

    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 [evolt.org].

    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 [w3development.de] 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" [gutfeldt.ch]. 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.

    • Don't get rid of table based layout - use tables for broad layout (columns, for example) and use CSS for styling and minor presentation details (indetation, spacing within your columns, etc). It's more cross platform compatible, it's more flexible, it renders faster on all common browsers, and it maintains at least the broad layout of your page in pre-CSS browsers. Maybe when CSS3 is finally around and supported it'll be suitable for full-page layout. CSS as it stands (and especially the pratical state of i
      • Go visit the CSS Zen Garden. Pure CSS-XHTML separation is available now.
        • Excellent stuff out there. Mod parent up.
        • That doesn't make anything I said not true. Especially the pixel-precision layout issues, which can be really annoying when you're generating dynamic content. Writing pure CSS layouts these days is just like writing table based layouts in the early 90s - you spend alot of time and energy accounting (with usually less than 100% success) for various browser issues, and with generally less than spectacular results. Theres no point in it, unless you're pedantic. Note that "Pure CSS-XHTML seperation" rarely succ

          • use tables for broad layout (columns, for example) and use CSS for styling and minor presentation details (indetation, spacing within your columns, etc).

            This is what I was specifically objecting to. For broad layout, pure CSS works fine. Yes, you have to hunt down the spacings the same as you do in a table, but your recommendation of using tables falls short, imho. I don't see a real reason to abuse tables as a page layout anymore. I've converted a page which is similar to your standard page from a t

            • I also think that tables can make a mess of things when you are working from a text editor, because unless you have very good indentation, you have to do trial and error and that's frustrating and error-prone.

              That's the reason I use tables for tabular display but not for layout.

  • Simple validation is the key. (Score:5, Informative)

    by ptaff ( 165113 ) * on Tuesday January 27, 2004 @06:52AM (#8098377) Homepage
    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 [w3.org] 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 [hotdesign.com] that summarizes the advantages.

    The css Zen garden [csszengarden.com] is a great example if you want to show colleagues why separating presentation from content is a neat idea.

    • Terminology! (Score:2, Insightful)

      by Anonymous Coward

      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.

    • Zen garden is great, but I think it's still more in the "this is where we can go" category than the "production website" category. You can make a site with all your presentation in CSS, but because of the buggy CSS implementation in some browsers that are still out there (cough*IE5.5) there are some things that you can't reliably do yet. What the site looks like is still the most important thing to a lot of clients out there.

      Your best strategy is still to use tables for the broad layout, as much as I hate

  • From an interoperability standpoint. (Score:3, Insightful)

    by Big Sean O ( 317186 ) on Tuesday January 27, 2004 @07:49AM (#8098528)
    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.

  • More reasons for standard/cross browser compliance (Score:3, Interesting)

    by okock ( 701281 ) on Tuesday January 27, 2004 @07:55AM (#8098554) Homepage

    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 [sf.net]) 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
  • 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 ti
  • 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

  • My 2 cents... (Score:3, Informative)

    by zonix ( 592337 ) on Tuesday January 27, 2004 @10:29AM (#8099891) Journal

    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 [w3.org] 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 [w3.org]. 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

    • 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 s

  • A Piece of Advise (Score:3, Insightful)

    by mchappee ( 22897 ) * on Tuesday January 27, 2004 @11:13AM (#8100417)
    I'm the lead developer of a commercial web-based document management system [para-docs.com]. 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

    • code that works on Mozilla is probably going to work on IE

      That's not true. There's gigantic amounts of CSS 2 that works in Mozilla, Opera and KHTML, but not in Internet Explorer. The most prominent areas are the selectors and tables.

      The only place where Internet Explorer usually gets things "right" is where it actually does the wrong thing, but what a newbie developer expects.

      For instance, text-align: center shouldn't centre block-level elements, just text. Internet Explorer gets that wrong, b

  • 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
  • Designing with Web Standards [zeldman.com] was recommended here, in a recent discussion on DHTML and javascript [slashdot.org].

    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) [zeldman.com] 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 belong
  • Really, I don't see a question there...
  • 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.

    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, whic
  • 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.
  • But I've opted to use XWT [xwt.org] 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 ne
    • And what happens when tinfoil-hat-wearing paranoids like myself, who have all scripting turned off, visit your site?
      • 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.
  • ripping out the IE proprietary Javascript in favor of ECMAScript

    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

Slashdot Top Deals

Adding features does not necessarily increase functionality -- it just makes the manuals thicker.

Close