Become a fan of Slashdot on Facebook


Forgot your password?

Do You Care if Your Website is W3C Compliant? 624

eldavojohn wonders: " Do W3C standards hold any importance to anyone and if so, why? When you finish a website, do you run it to the validator to laugh and take bets, or do you e-mail the results to the office intern and tell him/her to get to work? Since Opera 9 is the only browser to pass the ACID2 test, is strict compliance really necessary?" We all know that standards are important, but there has always been a distance between what is put forth by the W3C and what we get from our browsers. Microsoft has yet to release a browser that comes close to supporting standards (and it remains to be seen if IE7 will change this). Mozilla, although supportive, is still a ways from ACID2 compliance. Web developers are therefore faced with a difficult decision: do they develop their content to the standards, or to the browsers that will render it? As web developers (or the manager of web developers), what decisions did you made on your projects?
Update: 05/20 by C : rgmisra provides a minor correction to the information provided. It is stated above that Opera9 is the only browser to pass the ACID2 test, however "This is not true - Safari was the first released publicly released browser to pass the ACID2 tests." -- Sorry about the mistake.
This discussion has been archived. No new comments can be posted.

Do You Care if Your Website is W3C Compliant?

Comments Filter:
  • Depends on Usage (Score:5, Insightful)

    by foundme ( 897346 ) on Tuesday May 16, 2006 @06:48PM (#15346261) Homepage
    For commercial sites, it's all about ROI. So your PHB is unlikely to approve any spending unless you can prove significant loss of sales as a result of non-compliance.

    On the other hand, if I'm building a site in my spare time, and it's targetted at Slashdot audience, I would be very careful with all the standards because (1) I can approve my own time and (2) I am more concerned about peers' feedback than ROI.

    I guess it's the humanization of the site that makes you care about compliance.
    • Can you please explain your sig?
    • I'm going to chime in on this thread. I'm going to assume that when you say 'usage' you mean the target audience of the site? If so, that's really *NOT* an excuse, logical argument, nor valid defense for non-compliance. There is only one excuse for non-compliance and that is a mandated use of Microsoft technologies by management for the development of a website. Notice I did not call that a logical argument, nor a valid defense.

      Now, for ROI, I'm sorry, but if *ANY* user with a *FREE* web browser (or m
      • by lukewarmfusion ( 726141 ) on Tuesday May 16, 2006 @11:39PM (#15348063) Homepage Journal
        It's important to note the difference between increased revenue and ROI. Just because more people can access your site and become customers doesn't mean that the business will make more than they spent making the site compliant.

        That's the end of my devil's advocacy.

        Standards-based, accessible websites have a bigger ROI than is necessarily measurable. These sites tend to produce better search engine results, be faster to download, use less bandwidth, and improved usability. And if you have an altruistic bone in your body, such a site improves the overall quality of the web.

        So the ROI is definitely there, if you know how to make the case for it.
        • by vux984 ( 928602 )
          So the ROI is definitely there, if you know how to make the case for it.

          Right, but merely "shooting for compliance" and "actually getting there" can be the same thing as far as most of those roi benefits.

          In other words, if compliance is an objective, and you actively endeavour to achieve it, even if you miss the green "your page is 100% valid" result, you usually reap most of the roi benefits you refer to, whether you fix all the "errors" or not.

          Its sort of like ISO9000 and other "organizational" status sym
    • by hobo sapiens ( 893427 ) <TEA minus caffeine> on Wednesday May 17, 2006 @12:17AM (#15348230) Journal
      For commercial sites, it's all about ROI
      Aaargh! You imply that developing a website using web standards takes longer. False! It _does_ require that you exercise more care. Do it for more than one website and it'll become second nature, meaning things like using closing tags on everything, quoting attributes, and properly nesting tags.

      I have developed sites both using tag soup AND strict HTML and XHTML. It takes no longer to do things the standards way, and using standards will almost ALWAYS make maintenance easier and therefore faster. That's ROI.

      Finally, I use Firefox's tidy validator []. It takes no time to validate your code (literally, it gives you a status bar icon indicating success or failure) and I have found that more often that not, checking for validation errors helps you find logical errors in your scripting code (e.g. incorrect criteria with a loop over a recordset).

      It pays to use standards. I speak from experience. That doesn't mean that you have to slavishly adhere to them in certain situations. 99% of the time, though, there is no real excuse to ignore them.
      • Aaargh! You imply that developing a website using web standards takes longer. False! It _does_ require that you exercise more care.

        Sorry. If you're doing something more complicated than building a 10-page static site, or even something with a little PHP-driven database, then it will take longer. It'll limit your choice of available third-party modules, and you'll have to evaluate each one you consider for its standards compliance. You'll have to hire more competent developers when you outsource. You may
  • Safari 2 (Score:5, Informative)

    by m0rph3us0 ( 549631 ) on Tuesday May 16, 2006 @06:49PM (#15346271)
    IIRC, Opera 9 is not the only compliant browser. I believe Safari 2 is also compliant.
    • Re:Safari 2 (Score:2, Informative)

      by Ant P. ( 974313 )
      And Konqueror (which Safari is based on), and iCab...
    • Re:Safari 2 (Score:2, Informative)

      by Anonymous Coward
      Safari and other webkit based browsers miss out one style on the acid2 test. Something to do with the scrollbars IIRC. So, although safari is extremely close to compliance, only Opera actually passes.
    • Re:Safari 2 (Score:5, Informative)

      by chasingporsches ( 659844 ) on Tuesday May 16, 2006 @06:59PM (#15346368)
      you do remember correctly. actually, safari passed it long before opera did.
    • >I believe Safari 2 is also compliant.

      But it's not compatible... with the computer.
  • by GigsVT ( 208848 ) on Tuesday May 16, 2006 @06:50PM (#15346279) Journal
    I validate every page.

    When you write a program, your compiler or interperter will tell you when you fuck up. When you write a website, your browser tries its best not to tell you when a page is fucked up.

    It's a supremely bad idea to rely on whether a browser can display your site to determine whether it is designed correctly or not. Even the next version of the same browser might do something unpredictably different with your tag soup.
    • by styrotech ( 136124 ) on Tuesday May 16, 2006 @07:39PM (#15346705)

      Debugging valid code in semi-compliant browsers is still much better than debugging invalid code in semi-compliant browsers.

      If something doesn't look or work properly, the first thing you should do is test whether or not it is your code that is wrong. It gives you more certainty whether or not it is a browser bug you are dealing with, and how to research working around it.
  • by Spaceman40 ( 565797 ) <`blinks' `at' `'> on Tuesday May 16, 2006 @06:51PM (#15346288) Homepage Journal
    If it's my own personal site, I want it compliant. Must be the OCD in my family, but I also feel like if you "compile" the site it should return with no errors.

    If it's for work, I'll get it done so it works in IE and Firefox. I'm not getting paid for adhering to the standards, and writing a standards-based site that will look right in freaking IE takes longer than it's worth.
    • by kebes ( 861706 ) on Tuesday May 16, 2006 @07:09PM (#15346446) Journal
      I believe your take on it is pretty typical. We all feel like we "should" compile the page to some gold-standard, but ultimately the most important thing (in the short term, at least) is getting the page to look right on the most-used browsers.

      I will add to this, however, that I use the W3C validator as a way to help fix bugs. Often if something is not showing up correctly in one particular browser, it can be fixed by addressing one of the errors that the validator picks up. I highly recomend checking all your pages. Even if they don't always pass, the errors will give you insight into how your page is being parsed.

      So in response to the original question "do you validate all your pages": I sure do! I check them all, and I fix any of the errors that are easy to fix. I also use it as an invaluable tool to get the page working in many browsers. Ultimately, however, if I have to depart from the W3C spec in order to get something looking right in an important browser, then I leave the errors in.
      • by Sique ( 173459 ) on Tuesday May 16, 2006 @07:32PM (#15346659) Homepage
        Moreso, if I have a program generating HTML code, I want that code to be standard compliant. To me it's the easiest way to catch bugs in my code, because if I program it with compliance in mind, but the code gets warnings in the validator, I know there are bugs lurking around, even if the output seems to show up correctly in the browser. I even let generated code indent correctly, because this is another easy way to spot lines where your assumptions about what the code is doing are different from the actual behaviour.

        And if there is ever the problem of being not displayed correctly in different browsers: For me starting with W3C compliance and then tweak the stuff to show up correctly in different browsers is more easy than coding for one browser and try do adapt to others. With the W3C compliance you know how the code SHOULD look like, and you can spot the browser dependencies better, thus bug fixing gets more easy.
    • It's actually not as hard as many people make out to make a standards-compliant site that renders correctly in IE.

      First: this is assuming "correctly" is not defined as "pixel perfect", which was not and is not the point of the web. I concede that in many real world situations, the client expects a pixel perfect recreation of a PSD they give you, in which case you may run into problems. Things like the 3 pixel jog [] will screw you over. But if by correctly you just mean "looks exactly the same so long as y

  • Websites? Mostly. Intranets? Screw it.
  • Standards (Score:5, Insightful)

    by grazzy ( 56382 ) <> on Tuesday May 16, 2006 @06:52PM (#15346297) Homepage Journal
    A standard compliant website more or less guarantees that your website will work atleast decently now, tomorrow and in the far future. A non-standard with hacks might just aswell not render at all in 4 years.

    I'm not religious about it, but I try to make it as compliant as possible as I go, run your pages thru the validator a couple of times and you'll pick up your errors quite quickly.

    Nowadays, about 60-70% of my pages validates automaticlly on the first try.
    • For personal sites, I always go with the standard, and check everything including CSS and Javascript, and make sure that it degrades properly on lynx and alike.

      But for sites I am being paid for, it is just too time consuming to be both W3C compliant and work in IE. Thus, unless I am specifically paid to do so, my pages will be tested on the major browsers and if they work perfectly across IE, Moz, Opera, Safari, and so on, damn the standard.
    • Re:Standards (Score:4, Insightful)

      by neoform ( 551705 ) <> on Tuesday May 16, 2006 @07:16PM (#15346522) Homepage
      Not only that, but it means that anyone else who takes control of the site and works on it will have a much easier time reading and understanding the code.
    • Re:Standards (Score:5, Insightful)

      by ClosedSource ( 238333 ) on Tuesday May 16, 2006 @08:23PM (#15347030)
      "A standard compliant website more or less guarantees that your website will work atleast decently now, tomorrow and in the far future."

      Sure, until a new non-compliant standard comes along or the big players have an economic motive to break it. There are no guarantees on the future of technology or future technology markets.
    • Re:Standards (Score:3, Insightful)

      by DerekLyons ( 302214 )
      A standard compliant website more or less guarantees that your website will work atleast decently now, tomorrow and in the far future.
      Sure - as long as those far future browsers can render any tags that you've used, that have been deprecated between the time you wrote the page and the browser was coded.
  • I do (Score:3, Insightful)

    by gEvil (beta) ( 945888 ) on Tuesday May 16, 2006 @06:52PM (#15346300)
    I do. However, neither my employer nor the guy who has a long-term contract to develop our website have any idea what web standards are. For them, if it works in IE then it's "standards compliant." Thankfully I've been making progress (in teensy tiny little chunks) with my boss over the past two years...
  • I care (Score:5, Insightful)

    by Anonymous Coward on Tuesday May 16, 2006 @06:52PM (#15346305)
    Because the W3C validator doubles as a good error-checker. If the W3C validator rejects my page, then chances are I will have display problems of some sort on some browser I haven't tested yet.

    Unfortunately the contrapositive is not true, if the W3C validator accepts my page then there is no guarantee I will avoid display problems. But it's a good first step.
  • A constant argument (Score:3, Interesting)

    by Kithraya ( 34530 ) on Tuesday May 16, 2006 @06:53PM (#15346317)
    This very topic is the source of a constant argument between me and my boss. I work to make our product adhere to the standard, even if it means leaving out some nifty interface tweak. My boss wants me to *strive* for IE-only.
  • by nacs ( 658138 ) on Tuesday May 16, 2006 @06:54PM (#15346321) Journal
    When I design and code a site, I do it by hand (usually vim or kate) and when I'm done, I always run it through the W3C validator to make sure I didn't leave out a closing
    or some syntactical error somewhere.

    Some people are obsessive about being W3C compliant and do it pretty much just so they can 'show off' the w3c comliant badge. I do it to make sure I didn't make any coding mistakes.

    This validation happens to have the nice side effect of making a site render correctly in most decent browsers.
  • ABSOLUTELY! (Score:4, Insightful)

    by scronline ( 829910 ) on Tuesday May 16, 2006 @06:54PM (#15346324) Homepage
    As long as every browser shows it properly. There are quite a few times that being W3C compliant doesn't display properly in every browser (Hello Microsoft, you reading this? Please pay attention as there will be a quiz on this later).

    Overall, I don't think W3C is the end all of web design, however. Even firefox was having a hard time rendering the W3C test page properly. However it does help make sure everything works, and then you can hack the code to fix bugs for broken (ie) browsers. The closer you can be to W3C the better you are over all for long term.
  • Write once, test everywhere.
  • by werewolf1031 ( 869837 ) on Tuesday May 16, 2006 @06:55PM (#15346328)
    The article's webpage breaks if you change the text size in your browser.

    Ok, so maybe not so much "ironic", but considering the topic, that is pretty damned funny... or sad, depending on your perspective.
  • Despite the lack of support you get for all the w3c standards I find it is a good place to start to check your work.

    Using the validator checks your syntax while it checks compliance. Once you have error free markup you can decide from there if changing your content to comply with some standard is worth it. For simple things it usually won't make a difference in most browsers. And if some tricky bit of markup that makes your page look just right in IE or whatever your target browser is and it's not compliant
  • I know that my code isn't compliant with XHTML standards and I'm sure I do things which ARE NOT standardized but often help with cross browser issues.

    As such, 90% compliance should be achieved by all code. People who code to a non-standard better be ok with Firefox and Safari users bitching all the time.

    I myself prefer Firefox so by coding to Firefox, I can pretty much gurantee a high level of compliance and cross browser compatibility.

    All in all, I stress cross browser compatibility above w3C compliance. B
  • Test then Hack (Score:3, Insightful)

    by rueger ( 210566 ) on Tuesday May 16, 2006 @07:00PM (#15346384) Homepage
    I suspect that most people write for their favorite browser, then test with alternatives and hack the code to make it work.

    Pretty poor practice, but likely the norm.

    I'm overseeing a web site redesign right now for client whose members are largely Mac users.

    The coding crew hired by the designers are working with Internet Explorer though, so nearly every feature and many design choices need to be fixed so that the site will work for our Safari users. Or even non-current versions of Safari.

    We specified from the beginning that everything on the site be platform and browser neutral, and are becoming somewhat unpopular for continually saying "But it doesn't work in Safari..."

    Ulitmately what is needed is for clients of web design firms to demand that all work be compatible with at least Safari, IE, Mozilla, and Opera. Only then will designers create sites that are cross compatible from the beginning, instead of "fixing" thinsgs after the fact.
  • No and Yes. (Score:3, Interesting)

    by savala ( 874118 ) on Tuesday May 16, 2006 @07:01PM (#15346386)

    No, I don't care. The validator is a mechanical tool. It's inherently flawed, understanding nothing of semantics, easily tricked into validating things which never should validate, and in a number of cases throwing incorrect warnings and errors. Having your website validate is a first step. A guideline to doing things the right way. It's not completely necessary. The <canvas> element (as specified by the WHATWG [], and implemented by Opera, Mozilla/Firefox/SeaMonkey and Safari (I'm reasonably certain)) will cause errors to be thrown, yet one can imagine cases where its use is already perfectly acceptable. (Just as long as you don't use it on a client website, or at least not without full understanding of the implications by the people there of using something which can change out from under them at any moment, and their responsibility to track those changes.)

    Yes, I care. I'm a professional web developer. Of course my website validates, besides also being completely accessible and being as semantically meaningful as it can possibly be. It's just a little showcase of my technical expertise. And yes, I care, as in: if you as a fledging web developer come to me on IRC or on some mailinglist for help with your website, you'd better be damned certain that your website validates before bothering with me, as I'm not going to spend any time on what would otherwise almost certainly turn out to be a problem caused by your invalid code.

    Those two points made: wow, what's with the harping on ACID 2? Yes, it's a nice test to spur browser makers on to come closer to being perfectly interoperable, but it tests a pretty arbitrary range of rendering bugs, and all browsers save for IE are pretty much interoperale on it at this point. (Firefox only on the reflow branch, to be sure, but that's set to land Real Soon Now, and as has been explained often [], ACID 2 came at the worst possible time in the Mozilla development cycle.

    • you'd better be damned certain that your website validates before bothering with me, as I'm not going to spend any time on what would otherwise almost certainly turn out to be a problem caused by your invalid code.

      OK, so what happens when somebody asks you "I get this and this and this error; how do I modify my page to make it validate?" What good is it to declare yourself closed to such questions? And what happens when it turns out that the web server is modifying the page on its way to the W3C's valid

  • do i care? (Score:5, Funny)

    by bitkari ( 195639 ) on Tuesday May 16, 2006 @07:04PM (#15346418) Homepage
    <marquee><blink> nope. </blink></marquee>

  • by mattdev121 ( 727783 ) on Tuesday May 16, 2006 @07:05PM (#15346422) Homepage
    What people need to stop doing is comparing how a browser renders the Acid2 test to its compliance with web standards. If you bother to read the Acid2 page, you'll see that its purpose is to see how a browser renders INCORRECT code.
    To me, compliance is very important. Not only can you be sure that it will render properly in every proper, compliant browser, but it will also be easy to add on to and change stuff.
    Besides, as long as you aren't trying to jump through IE css-fix hoops, compliance is usually as easy as encasing all of your variables with quotes.
    • by Bogtha ( 906264 ) on Tuesday May 16, 2006 @07:16PM (#15346523)

      If you bother to read the Acid2 page, you'll see that its purpose is to see how a browser renders INCORRECT code.

      Have you actually bothered to read the Acid2 page? Because I hear this repeated all the time, and it's downright misleading.

      There is a checklist of about a dozen things the Acid2 page tests. Incorrect code is just one of them. It is necessary to include incorrect code in a test like this. How else are you going to check whether a browser follows the CSS error handling rules?

      It's incorrect code, sure, but it's incorrect code that has a defined rendering according to the CSS specifications. It's not something a compliant browser would trip up on. There is a correct way to parse the incorrect code, and the Acid2 page tests to see if a browser parses it correctly - among many other things it tests for.

      Where are you guys getting this idea that the Acid2 test is all about error handling? It's a very small part of the test, but plenty of Slashdotters seem convinced that the test revolves around broken code and nothing else. Was there a weekly meeting I missed wher eyou all got this myth drilled into your heads?

  • Reasons to validate (Score:5, Informative)

    by JimDabell ( 42870 ) on Tuesday May 16, 2006 @07:06PM (#15346431) Homepage

    Reposted from something I wrote a while ago []

    You cannot prove anything about the future... but you can identify trends.

    Before Netscape 1.2 came out, it was a common, non-standard hack to use multiple title and body elements to get crude animation. Netscape 1.2 came out, and screwed these pages up. Following standards ensured forwards compatibility with Netscape 1.2.

    Before Netscape 2.0 came out, missing quotes on the end of an attribute were detected as errors by Netscape 1.x and compensated for. Netscape 2.0 came out; it did not. Large sections of pages disappeared. Following standards ensured forwards compatibility with Netscape 2.0.

    Before Netscape 3.0 came out, people were careless with their ampersands, failing to correctly encode them in URLs, for example. These were detected as errors by the current browsers, and compensated for. Netscape 3.0 came out; it did not. Lots of broken links everywhere. Following standards ensured forwards compatibility with Netscape 3.0.

    Before Netscape 4.0 came out, people were still careless with character entities, omitting the trailing semicolon (I believe this was a property of many graphical editors, such as Frontpage). This was detected by the current browsers, and compensated for. Netscape 4.0 came out; it did not. Following standards ensured forwards compatibility with Netscape 4.0.

    Before Netscape 6.0 came out, people used a variety of non-standard Javascript techniques and layer elements, detecting Internet Explorer, and serving them alternative code. Netscape 6.0 came out, it didn't support the proprietary Netscape-isms of previous releases. Following standards ensured forwards compatibility with Netscape 6.0.

    More recent problems include stylesheets served with an incorrect content-type header, and table-layout images being broken up with lots of little gaps.

    This list only includes Netscape behaviour, as that is the only list I have to hand. (Thanks to this article []). I'm sure similar things apply to other browsers.

    There is plenty of evidence that sticking with standard code results in forwards compatibility.

    There are really only two important properties of future browsers:

    • They are likely to support at least as much of the specifications as the current version
    • Nobody can test in them

    Thus, my overwhelming desire is to simply treat future browsers as I would any other browser I couldn't test in: code to standards, and when I get a chance to test, fix up what is necessary.

    There are very few good reasons these days to write invalid code. Mostly it's just ignorance and apathy that causes people to write invalid code.

  • by Andy_R ( 114137 ) on Tuesday May 16, 2006 @07:10PM (#15346464) Homepage Journal
    Last time I looked, there was no way of embedding Flash in a page that validates and actually works in most browsers. Therefore, I gave up on validation.

    (oh and just because lots of sites and ads do annoying things with Flash, please don't assume that I do... like any tool it can be used or misused.)
  • by Dracos ( 107777 ) on Tuesday May 16, 2006 @07:11PM (#15346476)

    Is a fool who doesn't deserve to be involved in web development.

    The Web would never have been much more than an academic experiment without web standards. Anything that has a sufficiently large group of people that use it at various levels needs standards. Think road traffic is bad now? Imagine if there were no lines on the roads, no standardised street signs, or even pavement. Getting anywhere would be total chaos, and most of us would be doing it on foot.

    Sure, Opera 9 is the only browser released for public use that passes acid2, but the Gecko [] codebase achieved this a few weeks ago. Unfortunately, we'll likely have to wait for Firefox 3 in order to experience it.

    IE7b2 is complete as far as standards compliance is concerned, so you might as well go ahead and test it now. It still has the worst compliance compared to all other non-MS browsers.

    The distance between any W3C recommendation and the browsers is a result of 2 things: vagueness in the document, and how any browser vendor decides to interpret it (if at all).

    The biggest threats to web standards aren't MS, WHATWG, Motorola, or any other entity.

    Number one: Quirks Mode. As long as browsers try to correct invalid documents, there is not real incentive for valid documents to be produced. Interoperability can't be fully achieved, and machine-to-machine exchange of data remains tenuous.

    Number two: Nomenclature and Authority. Part of the W3C's problem is the terms they use to identify the stages of a standard. "Draft" is understandable, but labeling a final document "Recommendation" almost begs people to ignore it at will. Furthermore, the W3C just produces documents, and there is no body anywhere to monitor and enforce standards compliance among browser vendors. I believe the W3C should be absorbed into an existing technical organization which people actually respect, probably IEEE.

    Anyone who doesn't care about web standards might as well go back to 1998-99 and try to keep riding the bubble.

    • One question for you: Have you ever been a PAID web developer? And I don't mean doing something for your local club, but have you even developed web sites full time in order to pay your rent/mortgage? Somehow, I really doubt it....

      Try giving your speech to somebody who is paying you for your time, THEN get back to us.
    • by Blakey Rat ( 99501 ) on Tuesday May 16, 2006 @09:00PM (#15347295)
      I'd be more inclined to follow the standards if the standards didn't suck. For instance, CSS is incapable of doing simple math. (Why can't I make a measure 5em+10 pixels? Seems obvious to me, especially since em isn't a constant, but CSS won't do it.) Why is it so difficult to center something vertically? With tables, it was trivial, but with CSS it's significantly harder. (I haven't found a way of doing it with less than 2 divs.) Why do CSS measures typically go by *screen* measures and not *page* measures? When I say I want a div 10 pixels from the bottom, I don't mean the bottom of the screen, I mean the bottom of the entire page, idiots.

      Anyway, CSS is just frustrating as hell to use. IMO, it's not significantly better than doing layout using tables. Especially since WYSIWYG editors will show you the table layout in progress, but usually choke on CSS layouts.
    • by zx75 ( 304335 ) on Tuesday May 16, 2006 @09:25PM (#15347409) Homepage
      Anyone who answers "YES" to this headline without a "but..." isn't doing this for a living where making it work and look correctly is more important than standards compliance.

      I follow the standards to the best of my ability and test in all major browsers until something breaks (thanks IE, thanks a lot) which is when I break out the hacks until the page works correctly for everyone.

      So do I follow standards? Well, when you get right down to it, no, I don't. I follow them up until the point that they prevent me from doing my job, then they get tossed out the window.
  • I run my own indie web design business (targeting artists and musicians), and also do web design through my full time job (local newspaper - we do contracted web design, too). I make sure that ALL my clients' sites are HTML 4.01 Strict compliant (Or XHTML Strict), and work hard to make them at least functionional for people using TTS readers and text-mode browsers. When it comes to rendering for IE, I usually specify a second IE-only stylesheet.

    Once standards compliant, I test in all major browsers, plu

    • I make sure that ALL my clients' sites are HTML 4.01 Strict compliant

      So what do you do when you want to start an ordered list at a value other than 1? Example: the track listing of the album Follow the Leader by Korn that must start at 13, or top 10 lists that must start at 10 and step by -1. In HTML 4.01 Transitional and XHTML 1.0 Transitional, the deprecated value attribute of the li element does this, but like other deprecated elements, it's not present in Strict. How do you work around this? Until I

      • So what do you do when you want to start an ordered list at a value other than 1?

        I believe that the numbers in an ordered list are part of the document, not part of the presentation of the document.

        Take the track listing for Follow the Leader and put it into a table with columns "Track #," "Title," and "Length." Then you can't use ordered lists anymore (at least, not while retaining useful semantics). And, if you allow the users to sort the table by columns other than "Track #", then you cannot use any kind
  • I've never much been one for standards compliance in the past. I designed for the best browser around (mostly Netscape at the time) and didn't look back. Then again, I was a newbie then.

    These days I'm trying to go standards-based but the simple fact is that CSS is powerful and thus complex. The fact that various browsers interpret it differently is a major PITA as well. I've been trying especially hard to eliminate tables and I'm starting to come to the conclusion that it's a stupid idea, because CSS ju

  • table vs. div (Score:2, Informative)

    by Lauritz ( 146326 )

    I would like to ask a follow-up question: Do the replacement of tables with div-elements really help anybody (besides giving job security to web developers)?

    Note that I am not at all against css. But I just find the table-tag very usefull for layout. If you need to do a three-column layout it will be much easier and give cleaner code to just use a table, than to use one of the many [] css "hacks" needed to give the wanted result in most browsers. If you want the layout to do something "extra" (eg. "make the

    • Re:table vs. div (Score:5, Informative)

      by Bogtha ( 906264 ) on Tuesday May 16, 2006 @07:29PM (#15346632)

      Do the replacement of tables with div-elements really help anybody

      You're asking the wrong question. It's not about replacing <table> elements with <div> elements. It's about using the most appropriate element type and leaving the presentation up to CSS. Sometimes that means using a <table> element, sometimes that means using a <div> element, and sometimes it means using something completely different, like <ul>.

      If you need to do a three-column layout it will be much easier and give cleaner code to just use a table

      The thing is, it's not easier or cleaner. In fact, it's usually the opposite. With CSS, you develop the layout code once, and apply it to all the pages on your site simultaneously. With tables, you have to hack up stupid <tr>s and <td>s for each and every page you do. Mindless, boring, repetitive work.

      I also feel that it would be semanticly much cleaner to have a table with one row and three cells than to have three or four divs nested and floated in strange ways.

      This sentence makes no sense. Semantics describe what individual parts of the page mean and are encoded with HTML elements. They have nothing to do with the layout or CSS. Why would "floating something in a strange way" be semantically wrong? Floating things happens on a completely different conceptual level to the semantics. On the other hand, describing something as a table, when it's really a heading or an image, is obviously semantically wrong.

      • Re:table vs. div (Score:3, Informative)

        by Valacosa ( 863657 )
        "With tables, you have to hack up stupid s and s for each and every page you do."
        Not true, due to the magic of PHP and server side includes. Sure, the table may be ugly, but I still only have to hack it once.

        NOTE: I use CSS. However, I have found it's much easier to flog tables into doing what I want, DIV's have never been that co-operative for me. CSS beats <font> tags any day, though.
    • The problem with tables + content + screen readers is that screen readers can't read through tables like your eyes can, so things don't actually get interpreted correctly (There is a firefox extension that mimics screen reader output, I highly recommend trying it out to understand how horrible the web is for visually impaired persons).

      The technical reason for using div's rather than tables is growing more and more prevalant today. The seperation between content and display is a very important distinction th
  • I care, but unfortunately certain browser developers [] don't give a rat's ass, so attempting to get a page to render perfectly in ALL major browsers without being ultra-conservative and without having to rely on browser hacks like quirks mode or conditional comments is not an easy task.

    Furthermore, many [] open [] source [] projects [] generate HTML output that is so far from compliant that it's easier to just give up and rely on quirks and conditional comments to make things work, in comparison to spending the many man-
  • Contrary to some earlier posts, saying "my own stuff I care, but at work, it just has to work" -- it's my employer's policy that all our sites should be fully valid XHTML/CSS. Therefore, any site I make, must pass. Well, I say "must" - in practice nobody superior to me actually checks these things as far as I know, but I damn well make them valid anyway.

    In practice - our main website actually doesn't validate! Our (proprietary) content management system munges code, so that even if I enter valid xhtml,

  • Earlier this year, I was significantly less knowledgeable in webdesign. And I had quite a hostile attitude [] towards standards zealots. Heh, that page even has a load of factual errors that must have really clouded my judgement on the whole issue, not to mention the stupid ideas (don't you just hate reading old blog posts?).

    A lot of stuff has changed since then. My site has a new URL, it now carries a basic doctype and a lone meta tag.

    I've developed my ideas a lot since then, through discussion about this iss

  • On my Ruby on Rails sites, every (changed) page is automatically re-validated every time I make any change that would affect a page.

    (I use the assert_valid_markup or assert_valid_asset plugin)
  • by firegate ( 134408 ) on Tuesday May 16, 2006 @07:53PM (#15346811) Homepage
    but I don't think W3C qualifies as a "standard" - it's simply a guideline at this point, and as much as we all might like it to evolve into a true standard, it doesn't qualify when only one or two obscure browsers properly support it. Granted, IE's marketshare has fallen in recent years, but it still boasts a claim to well over 80% of the browser market, and as long as it maintains such a vast lead, IE compliance IS the standard whether we like it or not.

    Flame on, but remember that I am on your side here - just more of a realist ;).
    • Who really cares about the W3C anymore?

      The article talks so much about how not supporting multiple devices and such will slash your market share. He's obviously either academic or on one of those lame standards committees. How much business do I really lose because all 20 of the Palm Pilot surfers don't visit my site? It has ZERO impact to my business and I could care less about those users.

      And, almost by definition, standards are 1-3 YEARS behind technology so embrace as needed, but don't let them hold you
  • How I write web pages (and web applications): Code it, open in Opera, look for obvious errors, hit Ctrl-Alt-V to validate the page using the W3C validator. If W3C says the page is valid HTML, my work on that page is done. Else, fix what the validator marks as wrong. If a browser can't render the final page properly, the browser is broken, not my page. I don't have to test my page for hours with a heap of browsers, some quick validator runs are all I need.

    No, I'm not a web designer. I prefer pages that can

  • Only if... (Score:5, Interesting)

    by GWBasic ( 900357 ) <slashdot AT andrewrondeau DOT com> on Tuesday May 16, 2006 @08:24PM (#15347041) Homepage
    Only if it doesn't compile.

    On a more serious note, the only way to solve the problem is to have browsers shame non-complient pages. Specifically, if IE7 displayed a dialog that said, "This web site is constructed improperly and might not work as expected" every time it hit an invalid page, things would change VERY FAST.

  • oh, the irony (Score:3, Interesting)

    by circletimessquare ( 444983 ) <circletimessquare&gmail,com> on Tuesday May 16, 2006 @08:36PM (#15347129) Homepage Journal
    i'm working with xml and client-side xslt to render xhtml output on the client browser

    it's almost impossible to make nonstandard code this way

    the irony is that firefox and ie have no problems with this, while opera doesn't support xslt transforms at all

    so the most compliant standard browser isn't up to snuff with the most compliant type of code methodology

    (which, in a way, makes sense, because by avoiding xslt work, opera can continue to be the extremely lightweight browser it is... you can't support everything if your biggest selling point is how lightweight you are)
  • by Metasquares ( 555685 ) <> on Tuesday May 16, 2006 @08:40PM (#15347150) Homepage

    I not only validate my pages, but I also don't use any HTML or CSS "hacks". Sometimes this means using tables for non-tabular data. Sorry to trample on current web dogma, but users won't notice "semantic code" - they will notice a site that doesn't render properly in their browser due to CSS hacks. I didn't have to change a thing to make my sites work in IE7. If you use hacks, you probably can't say the same.

    Besides, if you truly want a semantic web, you should code your pages in OWL []! It's the logical conclusion of the current trend. I specialized in knowledge representation and reasoning and I could never understand what that language was getting at.

  • by Anonymous Coward on Tuesday May 16, 2006 @08:55PM (#15347251)
    W3C compliance doesn't really translate to a net gain or loss of income if you're running a commercial site, nor a loss of traffic if a non-commercial site, nor does it provide you any legal protection no matter what kind of site you're running.

    But if you're selling something, especially selling something to government entities in the US, or you're developing educational and informational sites for the public, compliance with web accessibility standards is of the utmost importance and trumps W3C any day of the week.

    Of course, good W3C compliance makes it easier to retrofit non-508-compliant pages. And 508-compliant pages are much easier to make W3C compliant, conversely.

    But at the end of the day, it's whether the site is accessible to everyone, not the coding standard, that really matters to the bottom line or the lawyers.
  • by yoz ( 3735 ) * on Tuesday May 16, 2006 @09:25PM (#15347411) Homepage
    Microsoft has yet to release a browser that comes close to supporting standards

    This is often shouted and an easy way to bash MS. It's also completely wrong.

    Every web browser released by Microsoft from IE3 onwards has been more standards-compliant than any Netscape browser released around the same time. IE3 was the first major browser (outside of W3C testbeds) with CSS support. IE4 brought CSS-P support, while NS4 introduced the totally non-standard LAYER tag, then made a bad stab at implementing CSS-P under sufferance. IE5/Mac was easily the most standards-compliant browser on the Mac for years. The Mozilla project had been going for a while when IE6 came out, and Mozilla might be considered the better browser of the two if you rate standards compliance several miles above stability and speed.

    The reason IE6 is bashed so hard by designers these days is not that IE6 was a particularly bad release. It's that it's bad by today's standards, and nothing's been done to fix it. This is a different issue, and one that the IE7 team has been loudly busting a gut to address. (There is also the utterly shameful issue of IE6's many security problems, which is a different argument, but it's one of the main reasons I've been using Mozilla-based browsers since 1.0)

    And if you're still not convinced of anything other than Firefox's total superiority over IE in all standards-related matters, how about we dig up an issue of HTML4 compliance which IE's had right for years, and Mozilla/Firefox never has. []
  • by ichin4 ( 878990 ) on Tuesday May 16, 2006 @09:40PM (#15347489)

    It's a wee bit disingenuous to blame browsers for the lack of strictly validating web pages out there. I'd venture that upwards of 90% of the issues you see when you validate pages against the HTML 4.0 schema are not there because the author had to violate the standard in order to achieve the effect in some non-compliant browser. They are there because the author achieved the effect he wanted and did bother to check whether he had, or could, achieve it in a standards-compliant way. From the beginning, browsers tried to degrade gracefully in the face of invalid input, and as long they do that there will continue to be a lot of invalid input out there.

  • when i *finish*? (Score:5, Insightful)

    by croddy ( 659025 ) on Tuesday May 16, 2006 @10:20PM (#15347713)
    When you finish a website, do you run it to the validator to laugh and take bets, or do you e-mail the results to the office intern and tell him/her to get to work?

    no, when i *start* a website, i'm running it through the validator. producing valid html and css isn't some kind of bonus afterthought. it's something you do from line 1.

  • by kyndig ( 579355 ) on Tuesday May 16, 2006 @10:24PM (#15347738) Homepage
    I've read many of the comments on here, and man am I feeling like a heel. I know I'm not the only web developer that doesn't give a hoot about that little W3C compliant icon. As long as the site operates properly in Firefox, Safari, Opera, and IE ( as I've designed it to operate ), then that suites me fine. After 5 years of developing the same site, the only complaints I receive on it are ones about my poor design.

    This brings to mind the software developers that howl about their Interface Standards ( I can't even remember the acronym they use for these standards ) I've supported the development of software for the past 3 years, and have yet to look at these Interface Standards.

    I focus on the end-users eyeballs. If some developer comes along and wants to complain about my syntatical correctness - they can either copy/past my HTML to make it better - or provide a patch for my software. The regular users are quite satisfied.
  • by pavera ( 320634 ) on Wednesday May 17, 2006 @01:00AM (#15348394) Homepage Journal
    I attempt to follow standards as much as possible, however because IE is so hideously broken, it almost doesn't matter. I recently developed a site, ran the validator on it, it passes fine, it all works in firefox and opera, displays how its supposed to, everything's great right? Open it in IE, totally broken, things don't line up, the spacing is wrong, everything looks like crap... go through everything to fix it, get it so it displays "right" in IE, run the validator again.... oops errors all over the place...

    In short I don't think its possible to write a standards compliant page and have it display in IE properly, as long as this situation persists, it will be impossible to push "standards" on the internet. If the standards don't display correctly on 90% of the computers, what are you supposed to do?

  • by suv4x4 ( 956391 ) on Wednesday May 17, 2006 @01:26AM (#15348472)
    There are several types of them:

    Validation fanatics:

    They believe that they should unconditionally comply with the W3C (and the other) validators and this means they did a good page.

    They compare the validators to the compiler syntax checks other languages do before compilation. Of course, no compilator in the world will stop you from writing buggy crappy useless programs, but they don't like to talk about that.

    Another thing many of them don't assess, is that validators are just a guide, not God, and like any software tool, they have bugs and can miss plenty of code flaw types, or print code warnings or even code errors where there are none.

    An advice to validation fanatics: your web page won't be seen in a validator, it'll be seen in a browser.

    XHTML fanatics:

    Anything less than XHTML 1.1 Strict is crap. In certain cases they might do a great compromise and go for 1.0.

    XHTML is just a rehash of HTML4 as an XML dialect. Unless you need to take advantage of your code being XML, there's no big advantage to using XHTML now* . All of the talk about future compatibility or how HTML 4 is obsolete is nonsense. Browsers will render HTML 1 for ages to come, same can be said for HTML 4.1, which still a nice, valid standard.

    *exception: mobile browsers strictly requiring XHTML Mobile Profile this is still no XHTML 1.1 support, like many XHTML fanatics believe.

    What XHTML fanatics forget is, it's not easy to write a real XHTML page nowadays, that would run in both existing and old HTML browsers (that actually includes IE6: over 85% market dominance) and XHTML browsers.

    XHTML fanatics sometimes make basic mistakes, like putting contents of [style] or [script] blocks in comments, or forgetting to put them in CDATA blocks, in both cases, the resulting code is a broken XHTML page if it runs in strict mode. The reason they don't see it, is that XHTML browsers interpret XHTML like HTML, since it's served with the HTML MIME Type (if served with Application/XML, it'll break IE).

    "No tables for layout" fanatics

    So yes, W3C said it's not recommended to use tables for layout. And it's indeed not nice: the classic usage of tables for layot is a huge mess of plenty of table cells, 4-5 nested tables in one another, the code is unreadable and unmanagable without a WYSIWYG editor (and that in itself, spells trouble if the web dev/designer has no clue).

    However, fanatics go further: they open the source of most site they visit, looking for "clues": if you do use tables for layout the site is marked invalid, the site author an idiot, and the site's actual contents discarded.

    If you ask a "No tables for layot" fanatic for help and he sees you use a table, you can be laughed at, insulted, bashed on and so on.

    The funny reality: CSS is still defficient as a layout tool for some pretty basic layout schemes. The workarounds include laughable stunts like 4-5 nested [div]-s or more (i.e. table tag mess in its new form), 3000px wide bitmaps with transparent areas and so on and so on.

    So these types of fanatics will advise you to either go for display-type:table (not working in IE), go for the ugly hacks, or change your layout. The irony you need display-type:table in CSS is worth a separate post on its own.

    Truth is, there's no drawback to using very simple tables styled with CSS for your layout, if there's no simple way to do it with CSS. No modern search engine or browser in the world has a problem with tables. No modern screen reader has problems with tables. No modern mobile browser has problems with tables. Try it in Opera (SHIFT+F11) and see how horizontal layouts made in tables are properly broken up vertically to allow for easy reading on a mobile device.

    "Don't use crappy browser" fanatics

    These guys believe it's their mission to talk, enforce, advice and so on their visitors to switch from their "crappy" browser (usually IE), to a better browser like Firefox. They also don't mind l

Life in the state of nature is solitary, poor, nasty, brutish, and short. - Thomas Hobbes, Leviathan