programming and human factors
by Jeff Atwood
The web is, to put it charitably, a rather forgiving place. You can feed web browsers almost any sort of HTML markup or JavaScript code and they'll gamely try to make sense of what you've provided, and render it the best they can. In comparison, most programming languages are almost cruelly unforgiving. If there's a single character out of place, your program probably won't compile, much less run. This makes the HTML + JavaScript environment a rather unique -- and often frustrating -- software development platform.
But it doesn't have to be this way. There are provisions and mechanisms for validating your HTML markup through the official W3C Validator. Playing with the validator underscores how deep that forgiveness by default policy has permeated the greater web. Dennis Forbes recently ran a number of websites through the validator, including this one, with predictably bad results:
FAIL - http://www.reddit.com - 36 errors as XHTML 1.0 Transitional. EDIT: Rechecked Reddit, and now it's a PASS
FAIL - http://www.slashdot.org - 167 errors as HTML 4.01 Strict
FAIL - http://www.digg.com - 32 errors as XHTML 1.0 Transitional
FAIL - http://www.cnn.com - 40 errors as HTML 4.01 Transitional (inferred as no doctype was specified)
FAIL - http://www.microsoft.com - 193 errors as XHTML 1.0 Transitional
FAIL - http://www.google.com - 58 errors as HTML 4.01 Transitional
FAIL - http://www.flickr.com - 34 errors as HTML 4.01 Transitional
FAIL - http://ca.yahoo.com - 276 errors as HTML 4.01 Strict
FAIL - http://www.sourceforge.net - 65 errors as XHTML 1.0 Transitional
FAIL - http://www.joelonsoftware.com - 33 errors as XHTML 1.0 Strict
FAIL - http://www.stackoverflow.com - 58 errors as HTML 4.01 Strict
FAIL - http://www.dzone.com - 165 errors as XHTML 1.0 Transitional
FAIL - http://www.codinghorror.com/blog/ - 51 errors as HTML 4.01 Transitional
PASS - http://www.w3c.org - no errors as XHTML 1.0 Strict
PASS - http://www.linux.com - no errors as XHTML 1.0 Strict
PASS - http://www.wordpress.com - no errors as XHTML 1.0 Transitional
In short, we live in malformed world. So much so that you begin to question whether validation matters at all. If you see this logo on a site, what does it mean to you? How will it affect your experience on that website? As a developer? As a user?
We just went through the exercise of validating Stack Overflow's HTML. I almost immediately ruled out the idea of validating as XHTML, because I vehemently agree with James Bennett:
The short and sweet reason is simply this: XHTML offers no compelling advantage -- to me -- over HTML, but even if it did it would also offer increased complexity and uncertainty that make it unappealing to me.
The whole HTML validation exercise is questionable, but validating as XHTML is flat-out masochism. Only recommended for those that enjoy pain. Or programmers. I can't always tell the difference.
Anyway, we validated as the much saner HTML 4.01 strict, and even then I'm not sure it was worth the time we spent. So many of these validation rules feel arbitrary and meaningless. And, what's worse, some of them are actively harmful. For example, this is not allowed in HTML strict:
<a href="http://www.example.com/" target="_blank">foo</a>
That's right, target, a perfectly harmless attribute for links that you want to open in a different browser tab/window, is somehow verboten in HTML 4.01 strict. There's an officially supported workaround, but it's only implemented by Opera, so in effect .. there is no workaround.
In order to comply with the HTML 4.01 strict validator, you need to remove that target attribute and replace it with JavaScript that does the same thing. So, immediately I began to wonder: Is anybody validating our JavaScript? What about our CSS? Is anyone validating the DOM manipulations that JavaScript performs on our HTML? Who validates the validator? Why can't I stop thinking about zebras?
Does it really matter if we render stuff this way..
<td width="80"> <br/>
.. versus this way?
<td style="width:80px"> <br>
I mean, who makes up these rules? And for what reason?
I couldn't help feeling that validating as HTML 4.01 strict, at least in our case, was a giant exercise in to-may-to versus to-mah-to, punctuated by aggravating changes that we were forced to make for no practical benefit. (Also, if you have a ton of user-generated content like we do, you can pretty much throw any fantasies of 100% perfect validation right out the window.)
That said, validation does have its charms. There were a few things that the validation process exposed in our HTML markup that were clearly wrong -- an orphaned tag here, and a few inconsistencies in the way we applied tags there. Mark Pilgrim makes the case for validation:
I am not claiming that your page, once validated, will automatically render flawlessly in every browser; it may not. I am also not claiming that there aren't talented designers who can create old-style "Tag Soup" pages that do work flawlessly in every browser; there certainly are. But the validator is an automated tool that can highlight small but important errors that are difficult to track down by hand. If you create valid markup most of the time, you can take advantage of this automation to catch your occasional mistakes. But if your markup is nowhere near valid, you'll be flying blind when something goes wrong. The validator will spit out dozens or even hundreds of errors on your page, and finding the one that is actually causing your problem will be like finding a needle in a haystack.
There is some truth to this. Learning the rules of the validator, even if you don't agree with them, teaches you what the official definition of "valid" is. It grounds your markup in reality. It's sort of like passing your source code through an ultra-strict lint validation program, or setting your compiler to the strictest possible warning level. Knowing the rules and boundaries helps you define what you're doing, and gives you legitimate ammunition for agreeing or disagreeing. You can make an informed choice, instead of a random "I just do this and it works" one.
After jumping through the HTML validation hoops ourselves, here's my advice:
But the question remains: does HTML Validation really matter? Yes. No. Maybe. It depends. I'll tell you the same thing my father told me: take my advice and do as you please.
+1 to no target and no javascript opening a new browser window.
I can't say it strongly enough. I *HATE* this.
The javascript is actually worse than the target. If you're used to command-clicking or control-clicking to get a new tab, the javascript says screw you, I'm doing what I want and not what you want
I *NEVER* want a new window, now that I have tabs.
Now someone going to come along and say, I should be using browser X instead, it does what I want.
They have no Idea what I want. I choose the browser I'm using for my own reasons. Web developers shouldn't be telling what browser I should use. *THAT* is why there are standards to validate against. If you're following the standards /any/ (compliant) browser should render the page correctly. If it doesn't it's a bug in the browser. If you're coding to a particular browser, you're intentionally putting bugs in your code.
Writing strict xhtml is not hard. You just need to learn about a dozen standard practices that are the most common mistakes. After that it usually takes a few minutes to fix the errors in validation that are more edge case.
If you learned web development the wrong way (like most of us, including me) then yes it's difficult to change, but it's not impossible and you should change for these reasons...
Cross browser compatibility. Generally speaking strict xhtml removes the need for 90% of the browser hacks people use and rely on these days. I write international sites that have to render in Opera, Safari, IE 6+ and FF 2+. My current project has one IE6 specific external style sheet with literally one CSS class override to fix a 1 pixel offset caused by a floating point error in dividing full width by 50%. It's a fully supported non-hack hack that I can live with.
Strict Code-Like Rendering you reference. You'll never reach the strict, code like interpretation of a programming language if you keep making developers support these cross browser incompatibilities because you refuse to see the benefit of strict xhtml code. As long as a majority of people keep writing poor html, browsers will still have to support it because otherwise the business community would scream murder when their sites don't render properly after a browser upgrade. Then we end up with transitional standards creating a third class of difficult-to-clean-up code.
I'm not sure why you don't think CSS isn't validated by the w3c (http://jigsaw.w3.org/css-validator/), or how you believe JavaScript isn't validated when it's parsed by the browser, but they are, and fortunately they're more consistent because I'd rather not mentally parse other peoples lazy preferences when reading their javascript code.
The only downside you mention is the lack of a _target attribute, which is not supported because there's a new CSS3 standard for that - it's a css attribute - target-new: window on anchor tags. But because the community dug themselves a hole, the adoption has been slow, and delayed. But on a more philisophical approach, unless you're doing a web application with a calendar or prompt popup, don't open a damn new window in ~my~ browser, if I want a new window, I'll hold my ctrl key when I click the link. If I want to leave your site to view another link, I will. And if you're developing a web application, then you're likely using javascript anyway so go ahead and use that to open the window and stop fussing. You're definitely over reacting to a very inisgnificant aspect of strict markup.
The bottom line is write strict code, it will make your life much easier once you learn it, and it will make everyone's life easier when we all do it. Hearing people shy away and fear strict xhtml is like the hearing vb6 developers shy away from .Net. Stop whining, and keep improving those skill sets so you don't end up like a dinosaur.
Marcus Pope on March 6, 2009 8:35 AMPersonally, I can't wait for HTML 5 to be widely supported -- it actually supports semantic elements that are useful for document markup. XHTML -- trying to squeeze document markup into a data container model -- was a mistake from day one. I understand the sentiment behind it, that being that forcing well-formedness (which XML demands) would clean up the worst of the mess. But XML is the wrong model for document markup. For instance, there is no particular reason why a browser (or other user agent) should render sibling paragraphs, headings, line breaks, rules or logical divisions in any particular order -- they are just data buckets, and as long as the hierarchy is maintained the data set is identical regardless of the order. Documents don't work that way.
HTML is not a poor cousin of XML, it is a different language with a different aim, and the only thing they have in common is the superficial similarity of angle brackets to mark elements, attributes and data -- and that came from SGML. XML is the odd duck in the flock, and the one thing it cannot do properly is document markup.
Stan Rogers on March 6, 2009 8:39 AMI view invalid markup a sort of technical debt that can build up and make things extremely hard later on down the road. It may be a good idea to only hit 90% valid on an initial release if it means you are first to market, but the longer you sit on these inaccuracies, the more risk you are taking for later.
Like any other technical debt, it pays to pay it down. When I have gone to 100% valid, it often fixed anomalies that were showing different depending on browser. Also, what is going to happen when people start using IE8 if you haven't paid down this debt?
Bryan Rehbein on March 6, 2009 8:40 AMBoy, I imagine the quality of the code that you write is just superlative. Do you just vomit it out, and so long as it (sometimes) runs to the intended effect, ay okay?
Ah, that's nice. If it's not valid, then no care was put into it and it is vomit - Your argument is so insipid I feel like just writing this reply is a huge waste of my time. Suffice it to say, however, that just because I don't subscribe to the idea of having my mark up validated by a predetermined set of rules does not mean my HTML is not semantically relevant, well formed, and consistent across browsers. That is all.
Paolo on March 6, 2009 8:40 AMWow, Jeff, how DO you get through all these comments!? I'm not going to bother reading any of them, so maybe mine is redundant. Feel free to ignore.
I'm currently playing with my new Kindle and the source formats for creating my own eBooks. They are XML-based, a common thing in our world today, and the content is written in XHTML. I used to be all for the simple seat-of-your-pants HTML style of things until I began using Blogger (all tags must be closed) and also seeing how poorly it translates to lighter-weight, stricter renders like eBook Readers (this isn't to say a CSS/Script-heavy page doesn't fall apart as well). The advantage to me is how quickly write tools to process XHTML whereas HTML is another matter entirely.
While StackOverflow is something of a web application for developer collaboration, it's also a valuable repository of information. And as such, anything you can do to make it more accessible is worthwhile. All that said, I haven't had a problem reading questions even with NoScript enabled and my first blush searches on Google for technical issues are still always suffixed with site:.stackoverflow.com.
Neil C. Obremski on March 6, 2009 8:42 AMHTML validation doesn't matter. See why using the Perfect Web Search Engine: http://dev.quickfire.org/perfect/
Alex Lambert on March 6, 2009 8:45 AMI am really split over this. I validate all my xHTML as strict xHTML. I just like the fact that it is neat and tidy xHTML, and should, render correctly everywhere. Now that last part isn't true because of various reasons, but validating can be useful for other things. Google ranks, finding bugs, etc.
Xeon06 on March 6, 2009 8:46 AMMy dad gave me advice too. He said: If something's worth doing, it's worth doing right. Don't be lazy.
Steve-O on March 6, 2009 8:56 AMJust as an added reference...
http://stackoverflow.com/questions/7940/how-important-is-w3c-xhtml-css-validation-when-finalizing-work/7951#7951
Just turn on debugging in your browser and watch what happens...
Mac on March 6, 2009 8:59 AMThank you so vary much, you have no idea how much this helped me.
patrick on March 6, 2009 9:03 AMSo, immediately I began to wonder: Is anybody validating our JavaScript? What about our CSS?
http://jigsaw.w3.org/css-validator/validator?uri=asperous.us
asperous on March 6, 2009 9:05 AMJeff wrote:
After jumping through the HTML validation hoops ourselves, here's my advice:
1. Validate your HTML. Know what it means to have valid HTML markup. Understand the tooling. More information is always better than less information. Why fly blind?
I know I am thinking abstractly (about the color of bikeshed so to speak) but wasn't your last post about how the key to getting things done was figuring out which pieces of information to ignore? I am not sure that it changes your main point but telling us that we should validate because more information is always better seems like a weak argument.
Greg B on March 6, 2009 9:16 AMYou should really educate yourself about the reasons behind these decisions. Asking ... who makes up these rules? And for what reason? is pretty silly when you have a big fat W3C logo right above that sentence.
The core guiding principle is: separation of concerns. As a programmer, you should understand that principle.
HTML is supposed to encode CONTENT, information, data, whatever you want to call it.
CSS is supposed to encode PRESENTATION
JavaScript (ECMAScript) is supposed to encode BEHAVIOR, interaction
So, to address your examples:
- The target attribute encodes BEHAVIOR (what the browser should do). It should not be in the HTML layer
- Width of a table cell only matters in DISPLAY / PRESENTATION (and should be in your CSS stylesheet, not inline style attribute in HTML).
Rick Dailey on March 6, 2009 9:21 AMJeff, great article, but I slightly disagree with you no a couple of points.
First off, there does exist a validator for CSS, and in conjunction with your flavor of HTML validation it really does check that what you're doing exists in the standard. This is especially important for CSS because there are so many proprietary extensions to CSS that are supported in certain (*cough*ie*cough*) browsers, and not supported or poorly supported in others.
What makes this much less useful is that the standard itself is not completely supported in all browsers, Javascript especially. But regarding just the markup, I've found that when I make an effort to produce strict standards compliant code, I end up with far fewer cross-browser compatibility issues.
No, standards validation won't solve all of your site problems. However, it does eliminate the chance for a great deal of them, and better yet can help to point out problems that *aren't your fault*, like issues with a certain browser rendering a CSS attribute for example.
Finally, I disagree on one of your points. My hand-crafted forums system at a couple of my sites validates to the XHTML 4.01 Strict standard just fine, and it has lots of user generated content and a similar parsing system to stackoverflow. Yes, it was partial hell to get it to work that way, but it can certainly be done. I don't think it makes sense to discourage users. After all, if you really feel strongly about treating HTML as code (as mentioned in a previous blog post) don't you think the HTML should follow the same syntax verification as the rest of the code in a site?
Nicholas on March 6, 2009 9:21 AMOwen Briggs had an interesting point of view on this, a while back.
This is an attempt to make a code that can go decades and centuries, getting broader in scope without ever shutting out it's early versions. Because that's what we need the code to do: this code is for recording what we think. There are no paper backups of the web. Every day we put more on it that we're not putting in our traditional medias. If we don't use extensible code, then our current history evaporates with the next minor tech change. We've never had this problem before. Before a mark on a page could go centuries; there'd always be daylight to read it by. This is a new problem and it required a new solution. ... We have to validate because that's the only way to know our code won't fail as the syntax develops.
http://thenoodleincident.com/tutorials/box_lesson/validation.html
I tend to agree. Plus, if you have the right mindset and are willing to think about what you're doing; its not even really that hard to write valid code that does what you want.
Josh on March 6, 2009 9:25 AMso the summary really should be : standards compliant html/xhtml is hard - lets go shopping!
mikester on March 6, 2009 9:35 AM@Mark T. Tomczak
Looks iike you don't know much about future web browsers, acid3 test and work done on HTML5.
You ask What market forces will compel Microsoft to make their HTML valid? How about this: http://validator.w3.org/check?verbose=1uri=http%3A%2F%2Fwww.msn.com%2F ?
Re-coding a page costs resources: money and time. —sure it does. That's why it is better to build it right way from the start—and that also minimizes the number of issues you have to deal across different browsers. Proper code most of the time works fine across firefox, opera and safari, some tweaks might be needed for less capable (you know the name).
And the incentive is there—it is to be professional.
Rimantas on March 6, 2009 9:37 AMAt least Stackoverflow.com now renders correctly in Opera (the only compliant browser) thank you!
If you're using firefox, the following add-on is a real boon if you are doing the HTML validation exercise.
https://addons.mozilla.org/en-US/firefox/addon/249
I just wish they had something similar for CSS!
Evan on March 6, 2009 9:44 AM@Rimantas
Thank you for the input, but could you expand on it a bit? I don't quite follow how the fact that www.msn.com validates is a market force. Are you implying that Microsoft now has a policy to crank out standards-compliant code? That's good for them (and should simplify the lives of some browser developers), but it shifts one company's website out of the 94% bracket and into the 6% bracket; it's hardly a compelling reason for the other 94% to follow suit, not when they're still learning how to do HTML from the For Dummies series instead of the w3c standard.
You also mention a critical sticking point with standards adoption: as long as the browser that ships by default on most people's personal computers requires some tweaks, writing proper code is neither necessary nor sufficient to make my website show up correctly on most people's personal computers. I'm back to per-browser testing, which I would be doing anyway; writing the code to be standards-compliant and THEN still needing to do per-browser testing adds one more thing to my list of things-to-do, a thing that gives questionable gain.
More predictable behavior in dynamic pages is a significant gain. Making my page standards-compliant is definitely going into my debugging toolbox for pages with dynamic content. I'm not convinced it matters as much for pages without dynamic content.
Mark T. Tomczak on March 6, 2009 9:54 AMOne good reason for implementing your website in XHTML:
It means your content is in XML. Hence it's manipulable with XML tools, can be generated with XML tools and packages, can be run through XML transforms to present it in new formats or organize it differently, and so on.
If you're not hand-coding your site, and you're generating the content via code - and I hope most of the readers are programmers - then it's at least worth considering.
A better and more in-depth explanation from the Deki-Wiki folks at MindTouch, here: http://www.mindtouch.com/blog/2009/02/23/is-that-xml-in-your-wiki/
Clifton on March 6, 2009 9:56 AMBut you should care. Because if you're anyone who writes anything that needs to scrape HTML (screen readers for the visually impaired immediately comes to mind), then having a strict definition of HTML and conforming to it makes it a hell a lot easier to work with.
Compare that with the total mess of malformed HTML now. A lot of sites are simply unworkable with screen readers.
Calyth on March 6, 2009 9:59 AMHmm...
-- 8 --
Errors found while checking this document as HTML 4.01 Transitional!Result: 66 Errors, 87 warning(s)
[...]
Line 12, Column 126: document type does not allow element LINK here.
#8230;rastination and the Bikeshed Effect /
... One common cause for this error is the use of XHTML syntax in HTML documents.
-- 8 --
Jeff, if you don't want to do XHTML, then why you're even trying it?
Vinzent Hoefler on March 6, 2009 10:00 AMValidation is definitely the way forward.
Validated HTML (plus validated CSS) doesn't guarantee that your page will render properly in all browsers. That much is obvious.
But conversely, you can't really complain about that pesky inconsistent renderings if you are feeding the browser invalid markup and just leaving it to guess what you actually meant (GIGO).
Graham Stewart on March 6, 2009 10:04 AM“Look again at the list of failing websites. They are in a category that makes up 94% of the content on the world wide web. What market forces will compel Microsoft to make their HTML valid? What about Sourceforge? Slashdot? CNN? The main page of Google?”
I’m no expert, but this seems like a rather complacent argument for not writing valid code. In order for a browser to render the 94% correctly it only needs to have workarounds for the mistakes in those websites. And how much effort would it take for these big sites to correct their pages? I suspect it wouldn’t be too difficult as they are mostly generated code. So if say in a years time most of the sites had improved to the point where a mostly conforming browser rendered them fine, do you think manufacturers will put a lot of effort in maintaining all there workarounds to support the percentage of the remaining 6% of the WWW with invalid code.
In any event, if it is as easy to write valid as invalid code, why take the risk?
I'm sad to see nor many people bringing up accessibility as a good reason to try to keep 'close' to validation.
validating isn't really needed, it's meaningful markup and a good separation of content and presentation that helps from my understanding.
A little note about accessibility, a salesman who works for our company has a total color blindness, thus if our software were to rely solely on color to help run the UI, he would automatically have a handicap with using his computer. While total color blindness is rare, should we account for it at all?
The same statement can be changed, if we're still supporting IE6, even though it's getting a lot more rare, should we account for it at all?
Screen readers arn't common either, should we account for them? Does valid xhtml really help them parse the data on screen? Do screen readers ignore 'style', 'id' and 'name' attributes?
http://www.freedomscientific.com/jaws-hq.asp - something tells me, by looking at their markup, that JAWs might actually work just fine with the majority of sites and not be partial to xhtml, unless of course they don't follow their own guidelines.
Tricky situation, it isn't about validation, validation doesn't matter so much as accessibility in my eyes, but everyone should do user testing, right?
this mat on March 6, 2009 10:09 AMYou brought up CSS validation... are you aware of the W3C's CSS validator?
http://jigsaw.w3.org/css-validator/
Andrew Care on March 6, 2009 10:14 AMAlso -- in terms of JavaScript -- what about JSLint?
Andrew Care on March 6, 2009 10:17 AMJeff, if I were a woman, I would have your babies.
I'm using HTML 4 with plenty of errors. I have always felt this way about using validating when my coworkers treat it as the be-all end-all, it really is taking away from what we're trying to do...hopefully having people visit use our website.
Your word is gospel to me (most of the time at least).
Dr. Bob on March 6, 2009 10:25 AMDoes it really matter if we render stuff this way..
td width=80
br/
.. versus this way?
td style=width:80px
br
I mean, who makes up these rules? And for what reason?
Actually, the width attribute in tables has been deprecated, and has been for years. The correct way to do this is to use CSS -- either embedded into the HTML or (preferably) as a separate page. Sooner or later, that width attribute will disappear.
Originally, HTML was a means to helping you understand the context of the document. If you were indexing the document, h1 through h6 tags could mark subject headings while ul and li would mark out lists, etc.
The problem started with Netscape's center tag. Center doesn't tell you anything about the context of the page. It's a formatting direction. Originally, formatting was really left up to the browser, but now Netscape was taking that right away from the user.
Soon, formatting tags proliferated, and we started getting the This page is best scene with... lines all over the place.
HTML 4.0 was a move away from formatting codes embedded in HTML, and allowing HTML once again to render context and not formatting. The result is that the webpage is free of formatting and contains more content. Content in HTML can be arranged, so that main content is on the top of the HTML file even if it isn't actually displayed there.
XHTML is merely the next step. Browsers render a page at a time, and aren't the real target of XHTML. Browsers will always render sloppily coded pages and always be rather forgiving. Instead XHTML is aimed at the massive indexers that someone might use to figure out what information is actually on their page.
While a browser doesn't have to figure out what is on the page it is rendering, the indexer does, so any coding error in the XHTML might make the page impossible to index. Google's indexer does its best to figure out the content of a page, but it does its job so much better when XHTML is used, and styling is saved in a style sheet.
I've seen this myself with my own pages. Fixing XHTML glitches didn't necessarily earned me a higher page rank, but it did help put my pages into the correct search results.
David W. on March 6, 2009 10:26 AMI've read through most, if not all, the comments and I don't think anyone has commented on the business side of this argument.
Say you have a moderately sized site and you need to allot labor hours to this project. Let's say you get a very good scripter/coder/hacker to review the entire's site code in 20 hours at a rate of $100/hour (some make more, some make less). Is it worth $2,000 to the business owner to have a validation review completed? What about the opportunity costs associated to using the manpower? Now, let's combine this with Jeff's recent technical debt article and even with overall lower costs, is it worth it now? The answer is probably still no.
The discussion is not as clear cut as of course you should write valid markup when you have to justify the costs of doing so especially if you're dealing with an already existing non-validating codebase.
hagrin on March 6, 2009 10:38 AMI try to make my html valid because i think its fun!
Adam on March 6, 2009 10:41 AMHarvey Dent sums it up quite nicely: You thought we could be decent men, in an indecent time! You were wrong.
guillermo on March 6, 2009 10:44 AMThere is a good reason for producing validated HTML:
If something does not display the way it should, and your HTML and CSS (there also is a CSS validator on W3C.org BTW!), then you can go to the browser vendor and say You suck! My page is totally valid, your browser screws it up... please go and fix it!
However if they test your page and it has hundreds of validation errors, they will not care for your bug report. They will say First go and fix your page, maybe it WILL display correctly once you did that and *THEN* we can talk about our browser.
Using valid markup makes sure your bug reports are taken seriously and they make sure browser bugs are found and fixed and this is something everyone profits of, as the more correct browsers work, the more webmasters can rely on correct working browsers, the less special browser hacks they must use, the better their page will render on any browser the user wants to use - the better the web experience for everyone.
Mecki on March 6, 2009 10:45 AMI agree with Eddie on the FxCop analogy. That lint checker allows you to customize the rules for your business or particular application, persist those changes in a project, and even suppress particular violations (with text justifications) in a persistent manner. This keeps the noise down if done regularly.
Bill Sorensen on March 6, 2009 10:49 AMSimilar agrument goes for correct spelling. Who cares if you get it right according to some arbitrary authority's judgement, as long as people understand you?
That's a crappy argument, if a tempting one.
Engligh spelling is meaningful. Aside from being wary of dislexic traps such as anti and ante, words have roots in multiple languages and in order to spell words correctly, especially unfamiliar ones, you need to understand what the components of language MEAN.
It doesn't matter how I spell/punctuate/validate as long as people/browsers understand me? Ah, but do you really understand YOURSELF?
Spraff on March 6, 2009 10:55 AMWhere the hell is Catto when you need him? I scrolled through the whole darn thread, not a single Hey Now Jeff anywhere.
DavidD on March 6, 2009 11:03 AMWriting valid xhtml strict IS NOT HARD WHEN YOU KNOW THE RULES. If you happen to know the rules, you should do it. If you don't know the rules, do whatever you want. Amazingly, the rules are quite easy to learn: write your markup in xhtml, validate it, and fix problems.
Let's say the site you are building hinges on faulty (x)html. There is no guarantee that markup written against the spec will act as expected in every browser, present and future. Work with the spec, and you know exactly what will happen. It's that simple.
Granted, you probably won't run into many cases where this will affect you, but if you do it could drive you insane. And it is quite dumb that target is invalid.
glompix on March 6, 2009 11:08 AMI love it when people proudly attach those valid html logos to their sites. About 80% of the time I click them, the validator produces a bunch of errors. I guess they were valid before a bunch of changes though :p
Jacob on March 6, 2009 11:24 AMI love the argument about Screen Readers - Write better html code to let Screen Readers programmers write crappy Screen Readers. html is standart for all browsers, why write Screen Readers that does not know html?
I know its cool to write good html, i even write html with right formatting, but it just for fun. I remember that at collage i was tought to write xml pages than transform them with xslt. why nobody is doing this? its more fun.
I love debates like this, its almost like tables vs css pseudo-tables. everybody would like to push as many standards as possible. its ok if they make sense, but with html validation nobody cares. if you are bored go for it.
ehhh on March 6, 2009 11:32 AMI'm surprised no one has mentioned the one self-interested reason to write valid markup. Maybe I'm behind the times here (not much of a jQuery coder), but don't browsers go into quirks mode if your markup doesn't match your DTD?
Granted, whatever the opposite of quirks mode is, it's not W3C-clean perfection. Most (all?) browsers still break the spec even when they say they're in standards mode. But in my experience getting the browser out of quirks mode can really help with some of those CSS layout problems that can get you banging your head against the screen.
Ben D. on March 6, 2009 11:34 AM@ehhh: I love debates like this, its almost like tables vs css pseudo-tables
Have you ever tried to make a minor change to someone else's table-driven layout?
Ben D. on March 6, 2009 11:37 AMThis reminds me of the the broken window syndrome.
I suspect that such a neglect doesn't resonate very well with programmers for obvious reasons, while it might be different for others, who doesn't understand the importance of protocol standards - or standards in general, because it doesn't affect them in the same way. If it looks the same as before, why bother fixing it, right? We know better; we should know better.
http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy
http://en.wikipedia.org/wiki/Fixing_Broken_Windows
Dennis Decker Jensen on March 6, 2009 11:52 AMI absolutely can't stand target=_blank so I have a hacked up version of the blank must die greasemonkey script that gets rid of them.
target=_blank is right up there with changing visited links to be the same color as unvisited links. It's like these self styled web designers trying to make browsing as difficult as possible.
Firefox DOES support custom DOCTYPEs. It's just that it only supports them in XML or XHTML (and not just XHTML served at text/html).
Elijah Grey on March 6, 2009 12:22 PMThats right Jeff. Nobody should bother writing markup that can be read by screen readers and braille screens. It's just too difficult to do and time consuming and won't make a difference. All those disabled people don't use the internet anyway. Especially not programming websites. And nobody uses reduced functionality browsers on their mobile devices. And nobody cares about their google ranking. And nobody needs a standard way of parsing web pages. Most people will see the web sort of the way it was intended anyway. We shouldn't have to cater to a minority who are different from us. It's too much hard work to do things the right way. Fuck everyone else, I'm OK. Standards are for other people to adhere to.
Alex on March 6, 2009 12:23 PMXHTML validation is all the more difficult that the W3C validators are broken: they don't understand perfectly valid custom namespaces.
Bertrand Le Roy on March 6, 2009 12:39 PMI have to admit that I read almost every Coding horror post, I listen to each podcast of the Stackoverflow podcast and yet I almost always disagree with you. (Weird, sorry) .. This time, however...
I COULD NOT AGREE MORE!
Thanks a lot Jeff! Excellent post. I'm glad someone said it ;-)
Arnór Heiðar on March 6, 2009 12:58 PMWhat, I have to use alt in images? Why I can't use the title tag, which works in all browsers while alt doesn't work on Firefox? Why can't I use align in images? How am I supposed to center an image then?
Screw it, I'm gonna use Transitional.
Alex on March 7, 2009 1:23 AMSpeaking as a freelance web developer, I strive to maintain (X)HTML standards in all of my work. I primarily use XHTML 1.0 Strict. I also do my best to use semantic markup. Within these limits, structure (the XHTML) is separated from presentation (the CSS). When you have valid semantic structure in your code, the presentation can be changed in a wide variety of ways simply by changing the CSS. (See csszengarden.com for many examples.)
As Scott mentioned above, I'm also using RDFa in some situations.
What's one of the best reasons to use valid code? Because it's never finished. You'll be back to work on it again later (or someone else will) and you'll thank yourself for having written code that's easy to understand.
Dan J on March 7, 2009 1:36 AMThe Browser Security Handbook paints a detailed picture of how laxness -- particular inconsistent interpretations -- leads to potential security flaws in all web browsers:
http://code.google.com/p/browsersec/wiki/Main
Yuko on March 7, 2009 1:50 AMThe reason why coding correct html is such an important issue, is because it's a standard. As a software engineer you should be aware of the importance of standards. It minimizes ambiguity
The fact that browser cover for our mistakes is besides the point.
Thomas Winsnes on March 7, 2009 2:46 AMignoring standards and ignoring validation is bad practise. There really isn't anything more to add.
Kale Kold on March 7, 2009 3:00 AMNice blog.......I'm glad you have brought attention to this issue...
ice hockey equipment on March 7, 2009 3:06 AMJeff did a reddit engineer quickly fixup the site or did you make a mistake first time around, I think that was fast.
Tim M on March 7, 2009 3:30 AMOf course everbody could use his own language, and ignore conventions. But it complicates understanding each other. Errors aren't errors when there are no rules, it's anarchy - and anarchy is seldom useful.
I'm a good example: i'm not a native englisch-speaker, and that makes it catchier to understand me in that language. Same goes for HTML and Browsers.
I prefer to stick to a standard, so i could proof it automatically with tools. I'll spider my sites periodically and get a report, and when a page does not conform to a standard, i'll get a message. In most cases it is an error, which could harm the layout on some browsers, in rare cases severe disfunctions results.
With wespiva (http://www.wissing.com/wespiva) all the xhtml-sites under my liability were spidered from time to time, with no effort, and errors are reported and corrected.
I find life is this way much easier, better i find the errors before the customers do.
It is not very professional to live with errors and accept them, only hobbyist may do so. It is easy to avoid these html-mistakes, i'll see no important reason not to follow some standards. It makes life with a group of developers much easier. If every member would follow his own standard, chaos is programmed.
toettoe on March 7, 2009 3:38 AMWhat I don't get is first building a site and then validating it...
When writing the (X)HTML, try to write it valid from the start.
Jimmy Shelter on March 7, 2009 3:56 AMI have to say that I disagree with this blog post. Also I myself find writing valid XHTML very easy.
Strom on March 7, 2009 4:13 AMWeb pages are not software. By definition they are documents.
Excessive script and CSS is an attempt by secretaries to pad their parts. This breaks presentation more than faulty HTML anyway. HTML documents are supposed to use flow-based rendering.
Trying to make a silk purse of a sow's ear is ridiculous anyway.
gag on March 7, 2009 4:27 AMThere are great reasons to validate. Accessibility in all its forms is absolutely important, and coding in such a way as to protect the delivery of material to screen readers, mobile phones, and so on is indeed smart and thoughtful.
But -- as someone on Google's Search Quality team -- I would like to bust the myth expressed in the comments here that Google specifically adjusts the ranking of sites based upon how well they validate. Google does not. The Googlebot is quite hardy and is typically capable of crawling and indexing even pages that validate rather poorly. And we at Google recognize that there are many pages with original and compelling content on the web that don't strictly validate (or even come close), and it would not be in our users' interest for us to rank them under, say, strictly validating but low-quality pages.
Adam Lasnik on March 7, 2009 5:30 AMA lot of people on here are saying the battle for validation can't be won.
One thing I've certainly noticed in my experience is that older developers are the ones that tend to not care about validation and younger ones, brought up on CSS floats, XHTML and jQuery, make valid sites without seeing it as a chore as it's the only way they know how.
Not that older developers aren't good at their jobs, but as the first generation web developers retire there will be a lot of developers left over who don't need convincing.
Rhys on March 7, 2009 5:41 AMI find that if you validate your markup as you go you are prone to much less errors.
A good validation tool allows you to find structural flaws otherwise difficult to see.
And, in my expericence, CSS JS behave much better with valid markup than otherwise.
João Gradim on March 7, 2009 5:46 AMI love XHTML, but that's a personal preference.
If you're intent on using the target attribute, though, please make sure the user always knows in advance that it will open a new tab or window. It's rude to pop things up on people without warning them about it. (Although really it should be the user's choice where they want to open the link.)
Deborah on March 7, 2009 6:08 AMAh, that's nice. If it's not valid, then no care was put into it and it is vomit - Your argument is so insipid I feel like just writing this reply is a huge waste of my time.
Then why did you lower yourself to reply? Ultimately you know your lazy, hackish rhetoric is a scarlet letter that you have no business in this profession.
What your reply ultimately screamed out was I am a hack, and Jeff just validated my hackishness so I feel that I am among friends. Let it all out! Jeff, as I think many unfavourably learned, is the king of the hacks (pretty much every one of his entries over the past year has been variations of correctness is for chumps! Just hack it baby!), so he has grown a larger and larger fanbase of code terrorists.
Dennis Forbes on March 7, 2009 6:59 AMThe interesting thing to do is to use Validation as a tool and not as a goal. Why my code is invalid? What is the source of errors? Which script, libraries, etc create invalid code?
So basically for me it helps me to create a better framework or script at the source. I don't want to validate every pages, but I want to be sure that the page which are produced are valid. That means I have to create checking steps in my code, or to use the appropriate tools. For example using an xml library to replace an element by another more than doing a regex, checking and sanitize the input of forms, etc. etc.
karl on March 7, 2009 7:08 AMHere's a thought. If everyone used valid html there would be no monopoly by MS on the web browser space...
Think about it this way, designers spend their lives ensuring that the produce websites that render correctly in the majority of browsers. So it becomes a self-fulfilling prophecy that the most popular browsers stay the the most popular browsers.
I can't bring out a new browser tomorrow that will knock the socks off IE, Firefox, Safari or Opera because for anyone to use my browser it has to render all their favourite sites well, which as it turns out were designed to just work on the common browsers rather than be valid.
So I have to replicate the rubbish that already clouds the big name browsers just to get a seat at the table. Rather than simply producing a browser that displays valid content correctly.
Think or all the extra processing power and resources that our browsers consume so they are able to account for the numerous invalid commonalities that may exist out there.
In my opinion, the onus is on the designers to produce valid markup, and then encourage their users to use a browser that respects and correclt displays that valid markup.
Oh glory be the day when content providers have the balls to say, Sorry this site might not work on your browser because... well... it rubbish. We design according to accepted standards which are respected by these browsers...
Pigs may fly...
Adrian on March 7, 2009 7:15 AMYeah, old developers (40+) like frames, font face tags, tables and don't understand or care about css. And the javascript they write is inline, at best a click attribute on a link or button, which I think is ok, but not the best alternative (better = mybtn.click = function() { ... }).
And those developers who can only concentrate on server code, and have designers who make their markup I think have good days, so comfortable life compared to someone who works in a smaller firm who has to do everything by himself. It's a lot harder trying to be an expert in a lot of topics than just one.
Yeah, validation is not a priority. But speaking of web pages, there is absolutely no difference for me between the red and green you choose for PASS/FAIL. (Needed source code to see the colors).
Paxinum on March 7, 2009 7:55 AMI care mainly about validation for finding malformed html like missing tags and invalid nesting of tags. This is one reason web development seems so frustrating. I just spent a few days updating some 10 year old code.
Just for fun, I tried validating my wordpress blog. It was invalid because its been hacked. Again!
Brian
I'm really surprised no one has mentioned anything about performance. I tend to agree with most of Jeff's comments. I really didn't care much about validation until I looked at browser rendering performance. HTML 4.0, XHTML, Strict, Transitional or whatever, as long as it validates you will see much better performance with browser rendering. That is the difference the end user will be able to notice not whether you use br or br /.
Will Morgenweck on March 7, 2009 8:48 AMThis post could only have been written by an ASP.NET developer.
Kevin on March 7, 2009 9:18 AMHey now, Jeff..
Looks like you need to be sent back to school since you seem to have missed the whole point of MVC, Separation of Concerns etc.
As for your examples, both are incorrect (both in concept and syntax).
(X)HTML is meant to give structure to the document.
CSS is meant to give the document a presentation.
The two should not mix.
Andy on March 7, 2009 9:54 AMUltimately you know your lazy, hackish rhetoric is a scarlet letter that you have no business in this profession.
Alright. I'll make sure I'll forward your ultimate judgment to the folks over at Digg, Yahoo, Microsoft, Google, Flickr and just about every other site in the Internet. I'll let them all know that although their websites are popular, functional, and well made, Dennis Forbes decided that they were were made by lazy programmers with no business in this profession, so they're going to have to start hiring. *rolleyes*
Paolo on March 7, 2009 10:36 AMI'm disappointed in you Jeff. I'm pretty confident that most of what I feel the need to say has already been said above, so I'll only touch on a few things. At the company where I work, upper management puts great emphasis on being able to prove things. Prove that the bill of materials is correct. Prove that we have our costs under control. Prove how long it takes to manufacture a product.
If one of your web pages doesn't render properly, validation helps to prove that you wrote your code correctly. Sure your code compiles, but there's warnings. I validate all my code to XHTML 1.1, even though my doctype is 1.0 Strict with RDFa support. (RDFa is not why I started using XHTML, but it's an added bonus for me. I switched to XHTML mainly because it forces you to write cleaner and more consistent HTML. It's more strongly-typed.)
And like Andy said, as an MVC person you should appreciate keeping things separated.
Scott on March 7, 2009 11:36 AMUsing divs and CSS to manage site layout is what matters.
Anonymous on March 7, 2009 12:25 PMI couldn't help feeling that validating as HTML 4.01 strict, at least in our case, was a giant exercise in to-may-to versus to-mah-to, punctuated by aggravating changes that we were forced to make for no practical benefit.
Indeed, I think a good compromise is to validate as HTML 4.01 Transitional.
So what have you done with your perfect, validating web pages?
Such a brilliantly clever response. I am defeated.
Dennis Forbes Who?
It burns.
I think anonymous up there captured the essence of the code terrorists. No standard? No tests? Seriously, you really think this?
These are the people who leave the legacy of garbage that other people have to replace.
Dennis Forbes on March 8, 2009 1:18 AMTo me, if you need to think about making a page valid you're looking at the problem from the wrong angle. Standards compliant design should be something you write instinctively because it feels right. How do you expect different browsers to render a page the same way if there's no set syntax.
Echilon on March 8, 2009 1:26 AMTo the validation nay-sayers, first let me say I can write valid HTML just as quickly as you can write invalid HTML, so the alleged time saving by not validating is a poor argument. What it really demonstrates is a lack of skill and understanding on your part.
A web page *IS* a data structure whether you like it or not. Your markup represents a tree -- the DOM tree -- that the browser builds when parsing your HTML. If that markup is malformed then the browser must guess what you meant, so you can't predict what tree it is going to build. This becomes important when you try to apply CSS to it: is node B a sibling of A, or a child of A? That depends on what guess a particular made. You write a style of A B { color: green; } and some blocks aren't getting the color, because the browser guess wrong and made it a sibling. How much time do you waste figuring that out? There goes your time savings (which you didn't really have to begin with).
Now try writing some javascript to modify that DOM tree to get your fancy web 2.0 effects. Good luck, because the tree structure is not what you thought it was.
Oh, you don't care, as long as it looks good in the majority browser? In case you haven't noticed IE's market share is declining. (now down to 67.44% according to http://marketshare.hitslink.com/browser-market-share.aspx?qprid=1 ) Is your audience in the tech sector? IE's share there is significantly less than in the general population. Do you have non-US users? Same there.
As for Coding Horror's 59 Errors, 63 warning(s) -- I corrected them all in under a minute just by running Tidy against it. Wow. That sure busted my budget.
All that said, I'm not even in the 100% valid camp, but I know why we aren't valid and the effect it has. We use Dojo to enhance our pages (google for progressive enhancement) and its dojotype= attribute causes validation to fail, but the page is structurally and semantically correct.
Finally, I find Paolo's actual hostility towards validation to be appalling. We're interviewing for 2-3 contractors to speed up our next project phase, and, while not a hiring manager (because I'm pure techie) I am an interviewer and in my position I have veto power. I'd never hire him (and I'm sure he wouldn't want to work for me, with that attitude) and I've rejected a couple of people already because in spite of their claims of being expert web developers they didn't understand separation of concerns or structural integrity. Oh well, they probably didn't need the job in today's booming economy anyway.
I'm not usually this sarcastic, but I think the attitudes expressed by several people in this thread display a total lack of comprehension of what the web *could* be, and what it could offer over traditional print media besides the obvious ease of distribution. Kudos to those that clearly do get it.
Hey, I don't care about the foundation my house sits on, as long as I can get the exterior paint in cornflower blue.
I agree fully with this post. 100% validation is for self-important know-it-alls, most of the rules are so obscure it's simply a waste of time. And XHTML makes the language harder to write. Not getting behind that, no way no how.
Even XHTML 1.1 is easy to validate once you get used to it. I have been building so many valid websites that I don't even have to pass the validator to know my code is valid (I do validate it anyway).
I completely agree: we live in a malformed world. Getting 58 errors for an HTML 4.01 transitional doctype on Google's main site can really discourage anyone.
We validated as the much saner HTML 4.01 strict, and even then I'm not sure it was worth the time we spent.
Again, once you get used to it, you spend less time in things such as: why the **** that CSS selector is not working?!
Txau on March 8, 2009 5:39 AMWhat these standards are trying to do is remove the design from the content. Both the a tag target attribute, and the a tag width attribute are mixing design and functionality in with what should be the content. HTML should just contain the content of your document, while the CSS and the JavaScript should maintain its design.
There are workarounds, and these workarounds are actually better then sticking all of this design and functionality into your HTML.
I mean, come on... It's 2009, content and design should really be separate entities.
Rob Loach on March 8, 2009 5:55 AM@Gimlock:
Maybe I'm a self-important know-it-all but surely the tangled mess of different browser rendering quirks that you get with non-valid HTML/CSS are far more obscure than the rules which are openly published for everyone to read??
Graham Stewart on March 8, 2009 6:06 AMSuch a brilliantly clever response. I am defeated.
Thus why you didn't answer the question? Oooh - SNAP!!
Dennis Forbes Who? on March 8, 2009 6:23 AMOut of sheer curiosity I decided to go back and validate a couple of my latest projects. It took me about 30 minutes a pop and it was a bunch of meaningless edits that had absolutely no bearing on whether my HTML was well formed or not. They validate now, though, so YAY, I am not a hack anymore! Dennis, I crave your approval, will you hug me now? *rolleyes*
Paolo on March 8, 2009 6:44 AMME GLAD NO MUST FOLLOW RULES. YOU DO WORK TO GROK MESSAGE; NOT PROBLEM MY. GOOD KNOW OK TO BAD STRUCTURE, GRAMMAR, LONG AS YOU UNDERSTAND.
*ahem*
A Gould on March 8, 2009 6:48 AMWhat's with so many web developers using XHTML over HTML?
Refer to
http://hixie.ch/advocacy/xhtml
and
http://www.dev-archive.net/articles/xhtml.html
What's with so many web developers using XHTML over HTML?
Especially when no version of IE supports it.
Anonymous on March 8, 2009 7:38 AMthat is probably the reason why my iphone screams when i go to stackoverflow with it. you don't care but the device does.
rad.ekg on March 8, 2009 9:57 AMAlright. I'll make sure I'll forward your ultimate judgment to the folks over at Digg, Yahoo, Microsoft, Google, Flickr and just about every other site in the Internet.
Wow, so did you develop one of those sites? Hey good for you. Oh wait, no you didn't, and instead you're trying to leverage the success of another to justify your own failures. Sorry, it doesn't fly.
Sometimes, although it is very infrequent, there are somewhat justified reasons why sites don't validate. Reddit, for instance, only fails when they inject failing ads (so their core system developers did a great job, including with user contributed content, but they are too trusting of injected ads). And many of those sites have been getting much, much closer to validation. Digg has a very small number of errors now, possibly ad related. Other sites might have succeeded despite the fact that the presentation layer was put together by pure hacks, but in the case of Slashdot we know that presentation changes are a nightmare for them because of the mish-mashed hack of a presentation they have.
Dennis Forbes on March 8, 2009 10:28 AMThe validation was marginally useful, because we did have a few extra close tags hanging around in a few pages and it helped us find those
Yeah, that's what I meant by egregious errors. Having random or mismatched closing tags isn't just a curiousity. It's usually an indication of a serious structural problem that will hose countless hours when things don't operate as expected. Being able to catch those is a massive win of having a cleanly validating page.
Dennis Forbes on March 8, 2009 10:36 AMJoe Audette
Founder of mojoPortal an Open Source CMS that does produce valid Xhtml.
Sounds a bit like a douch, but whatever. I thought I'd check out Joe's cool XHTML certified mojoportal tool. So, I went looking for a site powered by mojoportal. The first one on the list on mojoportal.com is joeaudette.com. Seems fitting that we should test his hypothesis. So, I went to the page. The front page passes the XHTML validator. Click on the Developer Articles tab on the top and of the page ( http://www.joeaudette.com/techarticles.aspx ). It has no fewer than 473 errors according to the w3c validator. He didn't even check his own page before making a post like this?
Hilarious.
steve on March 8, 2009 10:45 AMWeb standards are bullshit. There is no official reference implementation, no quality test suite, the documents themselves are huge and often ambiguous, making writing a good implementation virtually impossible.
Thus there are none. Every implementation is different and everyone adds their own idiotic extensions to it.
Validation might check structure - though no one else does - but it doesn't check semantics, making it a waste of time.
We shouldn't spend any more effort on trying to fix the web. The whole bloody thing should be exterminated and replaced with something sane.
anonymous on March 8, 2009 10:59 AM@Dennis Forbes Wow, so did you develop one of those sites? Hey good for you. Oh wait, no you didn't, and instead you're trying to leverage the success of another to justify your own failures. Sorry, it doesn't fly.
So what have you done with your perfect, validating web pages?
Dennis Forbes Who? on March 8, 2009 1:15 PMcite: XHTML offers no compelling advantage -- to me -- over HTML, but even if it did it would also offer increased complexity and uncertainty
The opposite is the case. The complexity and uncertainty are decreased. if you have no validation-error, the reason for a crashed rendering in a browser is found much easier and faster.
The xhtml-output of your developer-team is unified and easy to understand for each member, even for new members, which know the standards.
You don't have to think how to write the tags and attributes, the rules are set and well-known.
XHTML reduces ambiguity, and there are many tools for proofing - no other way exists to find many errors so easy.
Don't make me think, use Standards!
toettoe on March 8, 2009 1:45 PMME GLAD NO MUST FOLLOW RULES. YOU DO WORK TO GROK MESSAGE; NOT PROBLEM MY. GOOD KNOW OK TO BAD STRUCTURE, GRAMMAR, LONG AS YOU UNDERSTAND.
Huh. Bit of an All Liars paradox here.
If your point was that grammar makes it easier to understand your point, you've made that point very clearly. But by doing that, you've proven that good grammar is unnecessary to make your point very clearly. But then you haven't made your point very well...
My head is spinning.
Tom on March 9, 2009 3:47 AMOnce, someone called me for a problem in a webpage.
He had no clue on what was happening, and why the design was completely broken.
Tha validator reported a problem about a UTF-8 invalid character that it could not handle.
I always validate my pages.
Non-validation is a technical debt.
Yeah let's code crap 80's html; nobody cares .. browsers should handle this; not my problem.
*ahem*
Seriously, I fully disagree with this post, it sounds like a IE6 only web-developper speaking (sorry Jeff). Hoppefully i'm not feeling alone, after reading some comments.
flob9 on March 9, 2009 5:51 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |