Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Do You Care if Your Website is W3C Compliant?

Cliff posted more than 8 years ago | from the design-decisions dept.


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.

cancel ×


Sorry! There are no comments related to the filter you selected.

A relevant quote (1, Insightful)

c0d3h4x0r (604141) | more than 8 years ago | (#15346260)

In theory, whatever works in theory works in practice. In practice, this is not always the case.

Re:A relevant quote (5, Informative)

globalar (669767) | more than 8 years ago | (#15346637)

Aside from the all-important issue of "does it look right?", there is the professional issue of what sort of standards you should apply to your work. It's difficult to come close to a more extensive (and yet simple to implement) baseline metric of quality control with HTML/CSS than the W3C parser. Sure, I could go through and decide how I am going to do everything, but that's time-intensive and inflexible. Running something through the parser gives me a fast and consistent report. I can do whatever I want with the results, but they are there.

It does not solve problems for you or guarantee much of anything, but it allows you to see your formatting code in a more objective way. As a bonus, it can help you spot potential problems, mistakes, and open your eyes to some of the structure you are relying upon.

I always use the Tidy [] Firefox extension [] . It is a little friendlier than the online W3C parser interface. Disclaimer: not a professional web designer.

Re:A relevant quote (2, Informative)

ErisCalmsme (212887) | more than 8 years ago | (#15346940)

This is a Yogi Berra quote. "In theory there's no difference between theory and practice. In practice there is." ;)

Re:A relevant quote (1)

codewarren (927270) | more than 8 years ago | (#15346963)

In theory, the w3c makes the standards and browsers strive to adhere to them.

In practice, the browsers are the standard and the w3c is a lame duck. Why should I care if my website is standards compliant according to the w3c? My customers don't know what the w3c is.

When theory and practice disagree, the theory is wrong.

Re:A relevant quote (2, Funny)

Frogbert (589961) | more than 8 years ago | (#15346974)

Sure that makes sense in theory, but in practice it probably doesn't.

Depends on Usage (5, Insightful)

foundme (897346) | more than 8 years ago | (#15346261)

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.

Safari 2 (5, Informative)

m0rph3us0 (549631) | more than 8 years ago | (#15346271)

IIRC, Opera 9 is not the only compliant browser. I believe Safari 2 is also compliant.

Re:Safari 2 (2, Informative)

Ant P. (974313) | more than 8 years ago | (#15346292)

And Konqueror (which Safari is based on), and iCab...

Re:Safari 2 (2, Informative)

Anonymous Coward | more than 8 years ago | (#15346337)

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.

No, Konqueror's good (2)

bssteph (967858) | more than 8 years ago | (#15346362)

The latest release of Konqueror (3.5.2) does not incorrectly show scrollbars, so it "actually" passes.

Re:Safari 2 (5, Informative)

chasingporsches (659844) | more than 8 years ago | (#15346368)

you do remember correctly. actually, safari passed it long before opera did.

Re:Safari 2 (1)

mobby_6kl (668092) | more than 8 years ago | (#15346441)

>I believe Safari 2 is also compliant.

But it's not compatible... with the computer.

konqueror also passes (1)

billmustdie (862610) | more than 8 years ago | (#15346468)

Konqueror 3.5.2 is also displaying it perfectly.

And to answer any doubters - no, there is not a scroll bar. (as per usuall complaints)

To answer the original question, yes I do code to W3C. Mostly so I don't end up in an eternal "chase the latest bug" problem others run into when new browsers appear, or even just new versions.

Of course there are some compliant pages that refuse to render right in one or two browsers on the first pass, but debugging them against various browsers is alot easier than getting an IE web page to render correct in firefox, for example.

Re:konqueror also passes (2, Informative)

gdchinacat (186298) | more than 8 years ago | (#15346816)

So, I had to try this out and see it for myself. And, sure enough it rendered correctly. Then I started noticing the problems.

Here is a screenshot [] after "scrolling" using either the scroll wheel or up/down keys (despite the fact — as you point out — that there are no scroll bars).

And another one [] after a resize of the window. I restarted konq before doing the resize, so the issues aren't left over from the scrolling.

Also, note in the resized screenshot that the progress bar is stuck at 37%.

So, IMO, close, but not quite. However, close is better than most of the other browsers out there.

Re:konqueror also passes (1)

beelsebob (529313) | more than 8 years ago | (#15346897)

If you read the ACID 2 page, you'll discover that it specifies that redering should bugger up if you scroll.

Re:konqueror also passes (3, Informative)

Mornelithe (83633) | more than 8 years ago | (#15347000)

From the Acid2 page:
If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll.

Changing the size of the window has similar effects. Konqueror is exhibiting correct behavior; the test wasn't designed to keep the face constant after scrolling or forcing the browser to adjust the positioning by resizing the window. It's just supposed to display correctly after you click on the link that jumps you down to the face.

Because it's a good idea (5, Insightful)

GigsVT (208848) | more than 8 years ago | (#15346279)

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.

Re:Because it's a good idea (4, Insightful)

styrotech (136124) | more than 8 years ago | (#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.

That all depends... (2, Insightful)

Spaceman40 (565797) | more than 8 years ago | (#15346288)

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.

Re:That all depends... (4, Insightful)

kebes (861706) | more than 8 years ago | (#15346446)

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.

Re:That all depends... (4, Insightful)

Sique (173459) | more than 8 years ago | (#15346659)

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.

Re:That all depends... (2, Informative)

soliptic (665417) | more than 8 years ago | (#15346975)

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 you don't literally measure pixels", it rapidly gets easier.

Broken box model? No problem. Just don't use padding, and use an extra internal div with margin instead. Yeah, the hardcore purists say will say "but that extra div isn't semantic". But... let's face it... your first div probably wasn't semantic, was it? Furthermore, what's better - one extra div, or an enormous maze of tables (the old school approach), or standards-busting deliberate CSS hackery (seemingly the preferred method of standards junkies, which always completely puzzled me. Let's just say I'm slightly smug now they're all sh*tting themselves trying to fix their deliberate CSS hacks in advance of IE7).

I think one extra div is no small price to pay and voila, box model is sorted.

I'd say there are pretty easy, non-standards-breaking workarounds for most of IE's quirks. If you MUST use alpha transparent PNGs then you'll be stuck. But if you're not bound by a designers' PSD it's not actually as bad as all that.

Depends. (1)

Spy der Mann (805235) | more than 8 years ago | (#15346293)

Websites? Mostly. Intranets? Screw it.

Standards (4, Insightful)

grazzy (56382) | more than 8 years ago | (#15346297)

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.

Re:Standards (1)

LLuthor (909583) | more than 8 years ago | (#15346387)

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 (3, Insightful)

neoform (551705) | more than 8 years ago | (#15346522)

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.

I do (2, Insightful)

gEvil (beta) (945888) | more than 8 years ago | (#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 (5, Insightful)

Anonymous Coward | more than 8 years ago | (#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.

Safari passes Acid2 (0, Redundant)

Pendersempai (625351) | more than 8 years ago | (#15346314)

For what it's worth, I just ran the Acid2 test through Safari and it passed.

A constant argument (2, Interesting)

Kithraya (34530) | more than 8 years ago | (#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.

Re:A constant argument (1)

rufty_tufty (888596) | more than 8 years ago | (#15346353)

For my own interest, why does you boss what IE only? What's there to gain from this?

Re:A constant argument (1)

westlake (615356) | more than 8 years ago | (#15346947)

why does you boss want IE only? What's there to gain from this?

IE may still be the browser of choice for his target audience and that is where he needs to spend his time and money.

Re:A constant argument (1)

xs650 (741277) | more than 8 years ago | (#15346847)

Say hello to Bill for me.

There's more than one reason to be compliant... (2, Insightful)

nacs (658138) | more than 8 years ago | (#15346321)

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! (3, Insightful)

scronline (829910) | more than 8 years ago | (#15346324)

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.

The Java Standard of Web Development... (1, Flamebait)

creimer (824291) | more than 8 years ago | (#15346327)

Write once, test everywhere.

Oh, Irony... (3, Funny)

werewolf1031 (869837) | more than 8 years ago | (#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.

Re:Oh, Irony... (1)

Ant P. (974313) | more than 8 years ago | (#15346465)

It also breaks if your default font isn't Arial.

Re:Oh, Irony... (5, Insightful)

kebes (861706) | more than 8 years ago | (#15346528)

More specifically, if you run the article page through the validator [] it fails with 60 errors. The truth is that the vast majority of pages out there will fail. It's a catch-22: as long as browsers are not compliant, web-pages won't be compliant... and as long as web-pages are not compliant, what's the point in standards-compliant browsers?

It doesn't hurt (1)

just_another_sean (919159) | more than 8 years ago | (#15346364)

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 it's probably not a big deal.

For the most part though I find if I write to the standards first and make exceptions only when absolutely necessary my pages will look good in just about any browser. But maybe that's just me, I am also not a fan of using flash, heavy javascript or just about anything else other then html and css.

Compliance... to an extent (1)

Foofoobar (318279) | more than 8 years ago | (#15346377)

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. But often the two are the same.

Test then Hack (2, Insightful)

rueger (210566) | more than 8 years ago | (#15346384)

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. (2, Interesting)

savala (874118) | more than 8 years ago | (#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.

Re:No and Yes. (1)

tepples (727027) | more than 8 years ago | (#15346683)

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 validator?

I try for both (1)

Seta (934439) | more than 8 years ago | (#15346402)

I try to both be standards compliant, and work on all browsers as well. I do sites for myself and friends in XHTML + CSS and so far my biggest challenge has been making things work correctly in all browsers, and still maintaining compliance since every browser has varying levels of compliance. So far i've been victorious, however one thing I can say about standards compliance, is that the current browser wars always have some tidbit about somebody being more compliant than somebody else. At least by using compliant code while still coding to browsers as well, I can be sure that while qwirks are worked out of the browsers, my sites will at least still look correct with the least maintainance. I've been happy with the results so far, so I have no reason to complain.

It's all about standards (1)

jbrax (315669) | more than 8 years ago | (#15346412)

Standards? That's what web is about isn't it? We need interoperability, and the best way to achieve it is by standards. And it's not too difficult to make you're sites validate. Then add the necessary workarounds for IE and other "not quite there yet" -browsers and you will end up having a decent site.

do i care? (5, Funny)

bitkari (195639) | more than 8 years ago | (#15346418)

<marquee><blink> nope. </blink></marquee>

Re:do i care? (2, Informative)

Ant P. (974313) | more than 8 years ago | (#15346488)

I hate to point this out, but *both* of those are in the current CSS3 draft.

Re:do i care? (1)

DeafByBeheading (881815) | more than 8 years ago | (#15346778)

Yeah, but I'm sure the <blink> tag will be deprecated as soon as the server-side blink tag [] takes off.

Acid2 is NOT A "Complaince" Test (3, Informative)

mattdev121 (727783) | more than 8 years ago | (#15346422)

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.

Re:Acid2 is NOT A "Complaince" Test (5, Informative)

Bogtha (906264) | more than 8 years ago | (#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?

Re:Acid2 is NOT A "Complaince" Test (1)

WilliamSChips (793741) | more than 8 years ago | (#15346628)

The Acid2 test only actually tests whether or not the browser can pass the arbitrary obscure CSS features that Acid2 demands. More important is being able to render actual pages.

The value of a smoketest (1)

tepples (727027) | more than 8 years ago | (#15346723)

More important is being able to render actual pages.

But if a CSS engine can render Acid2 correctly without including a lot of Acid2-specific bullshit hacks, then it is more likely to be able to interpret standards-conforming web pages correctly.

Reasons to validate (5, Informative)

JimDabell (42870) | more than 8 years ago | (#15346431)

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.

Using Flash = Validation Fail (2, Insightful)

Andy_R (114137) | more than 8 years ago | (#15346464)

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.)

Re:Using Flash = Validation Fail (4, Informative)

Bogtha (906264) | more than 8 years ago | (#15346554)

Last time I looked, there was no way of embedding Flash in a page that validates and actually works in most browsers.

Look [] again [] .

Re:Using Flash = Validation Fail (1)

Andy_R (114137) | more than 8 years ago | (#15346845)

While the 'state of the art' may well have moved on, most of the linked methods look pretty familiar. I've done a lot of tests with similar methods, but only for a site where part of the spec was 'no javascript' (necessary to meet the highest British accessibility rating avaialble at the time, which we were shooting for), and you had to be fairly flexible with your definition of 'most browsers' to use these hacks. Specifically, all versions of IE for Mac only worked if you sacrificed all versions of Safari, and vice-versa, while Netscape 4.7 for Mac didn't just degrade to the text/static alternative, it crashed entirely.

Re:Using Flash = Validation Fail (1)

Stalin (13415) | more than 8 years ago | (#15346561)

Please give us an example of Flash used well for a web site design and not some video or game. I have yet to see a site completely designed in Flash that I didn't close after a few seconds because of either 1) not being able to navigate the wretched thing or 2) not being able to access the content immediately. Waiting on some animation to play before being able to read the content tells me that the content isn't worth waiting for.

I don't mean for this post to be an assault, but put your money where your mouth is (so to speak).

Oh, and embeding Flash appropriately does not cause validation to fail -- []

Re:Using Flash = Validation Fail (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15346834)

As others have pointed out, you can (unfortunately) embed flash movies in a standards compliant page. However, Flash isn't a web standard and never will be so there is little point in validating your markup. Besides which, I think that pages should fail validation if they embed flash content.

Re:Using Flash = Validation Fail (1)

Malc (1751) | more than 8 years ago | (#15346884)

Sure there is: include a .js file that document.writes the Flash object. You might need to do that anyway with IE7

Anyone who answers "no" to this headline... (4, Informative)

Dracos (107777) | more than 8 years ago | (#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.

Re:Anyone who answers "no" to this headline... (0)

Anonymous Coward | more than 8 years ago | (#15346546)

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

I'm living in Silicon Valley and you'd be surprised how many people around here are doing exactly that right now.

Re:Anyone who answers "no" to this headline... (1)

NineNine (235196) | more than 8 years ago | (#15346589)

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.

I'm a standards nazi. (1)

SocialEngineer (673690) | more than 8 years ago | (#15346479)

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, plus lesser used ones. I make sure each site is at least functional, if not exactly what it should be.

I tell you what, it is hell trying to get people to understand why standards compliance is important. They always seem to say "but this works, doesn't it?" - I hate that. Sure, it works NOW, but the code is bloated, it is useless in TTS readers, and it may not always render properly.

What's the Strict equivalent to li value? (1)

tepples (727027) | more than 8 years ago | (#15346799)

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 IE supports CSS counters, which are the W3C's official alternative to li value, user agents are still in the HTML 4.01 Transition.

Or have you carefully worded everything in your clients' web sites to avoid having to create such a list?

Re:What's the Strict equivalent to li value? (1)

briansmith (316996) | more than 8 years ago | (#15346946)

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 of HTML/CSS auto-numbering--you don't want the tracks to get renumbered just because they are presented in a different order.

Re:I'm a standards nazi. (0)

Anonymous Coward | more than 8 years ago | (#15346957)

You sound like a professional web developer, most web developers are cowboys who have no understanding of the medium. This is why we see sites done entirely in flash and sites that do not function without javascript. I've been thinking of making a mugs gallery, sites operators that have been ripped off and sold non-functional web solutions. There are just too many ecommerce sites developed using ASP to make that practical, __doPostBack() is a total abomination!

More or Less (1)

drinkypoo (153816) | more than 8 years ago | (#15346489)

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 just doesn't seem to behave as it is supposed to on any browser.

So basically, I do as much standards compliance as I can do fairly easily, and my overall layout both on the work website and my home website is completely CSS-based with no tables. There are still some tables on the work website because until I go to dynamic content on those pages I'm not going to CSS because I don't want to have to maintain the annoying CSS that will replace the tables, I want it to be autogenerated.

table vs. div (2, Informative)

Lauritz (146326) | more than 8 years ago | (#15346511)

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 center column 400px wide, but allow it to grow if the cell contains a wide image, pushing the right column") it will (probably) be impossible using divs, but trivial using tables.

One reason to not use tables, that is usally given, is that tables should only be used to tabular data and not for layout, as to not create problems for blind users. But just an empty alt-attribte on an image signals to the user-agent that the image is for layout only, a empty summary -attribute on a table could for example be used to signal that the table is for layout only. My guess is that, that convension would be much easier for user agent implementors to use that to parse through all of the css hacks. 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.

Re:table vs. div (5, Informative)

Bogtha (906264) | more than 8 years ago | (#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 (0)

Anonymous Coward | more than 8 years ago | (#15346711)

The topic was html, not xml, so it is not about marking every bit of information up precisely. It is about presenting a pice of information for easy consumsion for a human (blind or otherwise). So you comment makes no sense :)

Re:table vs. div (4, Informative)

Bogtha (906264) | more than 8 years ago | (#15346746)

The topic was html, not xml, so it is not about marking every bit of information up precisely.

Actually, it's HTML that has semantics, XML is just a markup syntax, so it's definitely about marking information up precisely.

It is about presenting a pice of information for easy consumsion for a human (blind or otherwise).

Yes, and in order to decide upon the best presentation, a user-agent (e.g. a browser) needs to know what kind of information it is getting. Hence marking up tables as tables, headings as headings, and lists as lists, not marking up everything as tables.

Re:table vs. div (1)

fean (212516) | more than 8 years ago | (#15346776)

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 that programmers, of all people, should understand well. With proper XHTML, I can pull data into any program I want and parse it correctly, because the data is store linearly, rather than in a table, where it might be leftImage-content-rightImage-leftImage-content-rig htImage... Specifically, I can pull an XHTML page into Flash, parse it out and extract important content. Templating becomes so much simpler that it's now a trifle to change/tweak a site's layout.

I've yet to see any layout that's "impossible" with divs (though it took a long time to figure everything out, and some of the code is VERY confusing), but it is Impossible for a table'd website to display information coherantly on my Treo, PSP, and in my desktop browser of choice. Don't even get me started on the whole printing tables issue.

The point of the matter is using tools for what they're made for (especially when they're perfectly competant)... I can almost guarantee you use a microsoft product for making web pages, considering your "Why don't they just add more processing to the user agents, rather than make me use standards" paragraph.

If you'd like to see the div vs. table arguement personified, look at my resume [] . I want to make a note that the only Javascript on the page is used to determine what browser the user is using, and create work-arounds for IE's lack of :hover attribute and poor handling of .png images (Both of these are addressed in IE7 thankfully). I dare you to try to recreate that site with tables and minimal javascript. Then, after you're done, make it print out nicely.

Tables limit your ability to really create sites that are unique, keep your data in formats that are impossible to use afterwards, and are ultimately the same as using a crescent wrench as a hammer... Yes, it works, but the hammer works better, and thats what it's made for... Just because you grew up using a wrench as a hammer, you're inclined to use it, but if you switched over, you'd realize how much harder your life was.

I only care if it won't work with Firefox or Opera (1)

WillAffleckUW (858324) | more than 8 years ago | (#15346576)

because those are my default browsers.

If it's flash, it's really annoying, especially those auto-follow-the-mouse-show-teardown ones that don't let my move my mouse around, which really annoys me as I have multiple tabs open and I hate the advertisers who do that and will never buy their products.

So, no, I don't actually care if it's W3C compliant, so long as it works with both browsers - I use Opera for email and Firefox to surf the web for news and sites.

I do care, but. . . (1)

kimvette (919543) | more than 8 years ago | (#15346588)

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-weeks it would take to fix rendering problem of the various modules and plugins one would often use in conjunction with those projects.

My employer requires that I care! (1)

soliptic (665417) | more than 8 years ago | (#15346601)

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, it doesn't come out valid at all. This should be fixed in the next update hopefully... although even then it will take a huge overhaul to bring our vast website into 100% standards compliance. Until then, at least all our non-CMS microsites are valid. I've also helped persuade them to use Plone [] as the basis for our new intranet, partly because it adheres to pretty much every web standard under the sun.

Even if they didn't have this policy (and outside work, where I'm under no such direction), I still care. Why? Well... hmmm... frankly, I think it's about a typical geek trait as much as anything. Confused?

Basically, although one could reel off the supposed reasons why standards are all good (cross browser rendering, accessibility, etc), but there are counter-arguments to these anyway. (Cross browser rendering? Barely any browsers REALLY support all the standards, and the hugely dominant one doesn't do so at all. So the pragmatist could argue standards aren't the de facto route to platform-independent equivalent rendering. Accesibility? It's doubtless possible to follow standards and be inaccessible, and vice versa...)

No, if anything, the real reason I love sticking to standards is that good old geek habit of enjoying a challenge. Let's face it - it's easy to make a site that looks good in one browser and sucks in the rest. It's easy to make a site that looks good if you just do the whole bastard thing in flash. It's easy to make a site that looks good across all browsers if you ignore the standards and fill your markup and CSS with hacks. But make a site that looks good across all browsers, using the onion skin of gracefully degrading web technologies (Server side language of choice->XHTML->CSS->JS) and nothing more, and all 100% standards compliant?

Now that's a real challenge ;-)

I'd link you to my employer's site, or some of the standards-based microsites I've done, but it's a charity, and I don't want to land them with a bandwidth bill :-)

I care (1)

pci (13339) | more than 8 years ago | (#15346612)

I'm almost OCD when writing sites to be at least HTML 4.0 transitional, and if I have a few minutes to kill I go for HTML 4.0 strict or XHTML 1.1 strict.

Yes I'm retarded, but I just don't feel like I have fully completed a public facing page until it is compliant.

Search ranking (0)

Anonymous Coward | more than 8 years ago | (#15346613)

My ISP tells me that sites that are compliant rank higher in searches. That would be a powerful reason to comply. Is he right?

Both yes and no (1)

qa'lth (216840) | more than 8 years ago | (#15346635)

Surprisingly, I both do and don't care.

My current project uses the name="" parameter inside of tags, which isn't part of the standard, but is surprisingly useful anyway.

I also make use of the _ trick for dealing with IE's boneheaded CSS.. which definitely doesn't validate.

Take those two out, and everything does validate. It's not great, but it does work nicely on IE, Moz, Opera, and Safari, which impresses me nicely. :)

Kinda (1)

bcat24 (914105) | more than 8 years ago | (#15346642)

The answer for me is yes and no. IMO, it's a very useful tool when developing a website/webapp/whatever. That said, in the Real World, there are more important things than validation. (/me carefully glances around for standards zealots.) Stuff like semantics, security, and accessibility. It makes me sad to see a "valid" site loaded with crappy '90s DHTML, layout tables, and a bunch bad alt attributes. I'd much rather see a good, modern site that happens to have a few validation errors.

Fun pages: Yes. Work pages: No (1)

Leviathant (558659) | more than 8 years ago | (#15346673)

Ironically, I only validate my hobby site for XHTML/CSS2 strict compliance. I like to pretend that it keeps me on my toes. However, I don't actually design any of the sites I work on at my job, and they're done entirely in Visual Studio, which makes them entirely unfriendly to standards. I realize this is a lame excuse, but it is far too time consuming, and our clients generally do not care. I obviously am aware of all the benefits, given the attention I've paid compliance via my large-ish hobby sites, but there's not enough motivation to adhere to that in our developing environment. I might as well add that my happy-go-fun sites run PHP/Perl/MySQL on Apache, and the sites I get paid for run on IIS.

Not really (1)

linvir (970218) | more than 8 years ago | (#15346706)

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 issue on Slashdot, coincidentally, but my overall opinion is still that if the HTML is of a good quality and it renders right in about half a dozen major browsers, my job is done. My opinion of standards is that they aren't black and white. There are two layers to almost every rule and standard: the beautiful theoretical layer, and the beaten and twisted practical layer. My 'validators' are the very programs people will use to view my work. Internet Explorer, Firefox, Konqueror and so on.

I think people like the W3C validator because it pats them on the back and gives them big green 'YOU WIN' feedback. It's a way to have something tell you that you made a good site without taking into account the content and aesthetics, which for some people is a crutch.

Obviously there's a balance between these two sides, one which I have yet to reach. My experience is that the real experts don't tend to have extreme views on stuff like this. An extreme view impairs your ability to know when to use the tool for its intended purpose.

Some people will do the typical Slashdot thing with this, which is to take everything you disagree with as a sign that the person who said it is evil or a dickhead. The reality is that there are different kinds of pathetic nerd. Some enjoy the inital creation almost exclusively, and others get equal enjoyment out of the refining stage at the end. I'm the first kind, the typical lazy programmer who prefers writing cool new features to debugging. So please take a deep breath if you're thinking of singling me out as the cause of all evil in society.

standards first (1)

headlessspider (859133) | more than 8 years ago | (#15346770)

i try to apply the standards first. if that doesn't work (obssessive/compulsive website owner wants top and bottoms exactly aligned with top and bottoms of images) then i go with deprecated standards.

Yes, of course (1)

swimmar132 (302744) | more than 8 years ago | (#15346795)

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)

I hate to break it to you guys... (3, Insightful)

firegate (134408) | more than 8 years ago | (#15346811)

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 ;).

Great point!! (1)

i am kman (972584) | more than 8 years ago | (#15346913)

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 hostage.

Validating is less work (1, Flamebait)

Tux2000 (523259) | more than 8 years ago | (#15346819)

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 be scaled up and down using the browser settings, as preferred by the user. I prefer simple, formatted text (simple HTML, perhaps without CSS) to webpages that torture the browser into a pixel resolution grid. Those pages are easily written, easily validated, easily rendered, and look pretty good in all browsers.


Funny you should ask... (1)

Solra Bizna (716281) | more than 8 years ago | (#15346850)

I just finished work on a website. I decided to make it completely XHTML and CSS compliant. And to my shock and horror... it rendered perfectly in every browser I tried! (note: did not and will not try IE) So from now on, I'm definitely coding to the standards.


Uh. (1)

floamy (608691) | more than 8 years ago | (#15346863)

Yes. A browser passing ACID2 is much different than XHTML being actual XHTML.

Hmm (1)

RalphSleigh (899929) | more than 8 years ago | (#15346864)

I write nice valid code for Firefox, then mangle it for IE, the only time I had to break standards for FF was on some kind of image map name thingie.

Now why is /. forbidding the validator?

Re:Hmm (1)

JayTech (935793) | more than 8 years ago | (#15346953)

Maybe because they have 7 errors? LOL. Try c&p the source to see for yourself.

Validation has zero value to the end user (0)

Anonymous Coward | more than 8 years ago | (#15346866)

All the end user cares about is if it displays correctly in their browser.

Screw standards and do browser based testing.

If you want to do both, fine, but its a waste of money.

However, you should use CSS because from a design perspective it is easier and reduces duplication.

Don't you mean "Is your IDE W3C Compliant?" (1)

Salamanders (323277) | more than 8 years ago | (#15346941)

What the hell, why do I have to worry about this crap? English, which has WAY less defined grammar rules, can still be decently parsed by MS Word and display a squiggly green underline under the sentences that don't work right.

Where is my free, lightweight, W3C editor with a squiggly green underline?

Re:Don't you mean "Is your IDE W3C Compliant?" (0)

Anonymous Coward | more than 8 years ago | (#15346992)

Squiggly line not included [] .
And while I've not used it Nvu [] looks interesting.
Of course, real mean use emacs^Wed.

P.S. Captcha sucks fat donkey balls, and ain't exactly standards compliant...

Compliance is of utmost importance (1)

Abu Hurayrah (953237) | more than 8 years ago | (#15346959)

Without a doubt, I try to make every webpage I design that is more than just a quick test script comply, at the very least, with one of the X/HTML doctypes - whether it's transitional or strict. I do this at work & at home, on my own personal projects. Naturally, you're limited with what you can do when you have to design for IE, but that's called the "Real World". I'm blessed at work to have co-workers that agree with this, for the most part. Sadly, our working code base is not compliant, but you do what you can.

The best point I saw mentioned above was that compliance is the best bet that what you make work on a website now will also work in the future. If you design for one particular platform or agent, then you'll be out of luck if that changes. This is really only a discussion for someone who is shortsighted - along the same lines of reasoning as the ones that think 1GB of RAM is more than you'll even need & you'll never fill up those new 750GB hard drives. Sadly, human beings are far better at seeing what they've already passed than what is coming up, and don't seem to be able to extrapolate from that.

Standards-compliance is one of those good design practices that carries with it the lessons learned from the past. Coupling it with separation of presentation & content (e.g., XHTML & CSS), a standards-compliant website ends up being really nice.

But, the vast majority of otherwise intelligent developers will probably succumb to the ideology of instant gratification & short-term gains - "I did it in five minutes!" - "It works on 90% of people's computers". This is the same flock that doesn't leave comments in their code & think no one else needs to understand it after it's done - including themselves!

Firefox with HTML Validator Extension (1)

munwin99 (667576) | more than 8 years ago | (#15346960)

Title says it all.
It may not be 100% perfect, but it's damn good.
Write the code with a text editor, then check the page with Firefox and the ext. Most of the time IE is damn close to working (IE6 anyway), the way Firefox does.
Caveat - I am not a pro designer, and do not use heavy javascript, and only moderate amounts of CSS.
Check OSWD for compliant designs, and use them as a base. This saves me lots of time (once again, I'm not a pro designer).

In a word (or two) (1)

Trogre (513942) | more than 8 years ago | (#15346972)

Hell yes!

I validate... Kinda (1)

DamnedNice (955496) | more than 8 years ago | (#15346983)

I design and code my sites in Visual Studio; though the ASP.NET C# code generates additional HTML that can't be checked from within VS2005. I try to keep that part as close to W3C as possible, but sometimes compliance just makes it harder to get things done. The CSS validates, usually... The biggest problem I see is alot of web hosts add non-compliant tracking code to each page.

No (1)

musselm (209468) | more than 8 years ago | (#15347002)

N-O means no.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>