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.
@Paolo: 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.
What does well formed mean to you?
To me that sentence makes no real sense at all. Doesn't well formed imply that it follows a standard? If your HTML was invalid then surely by definition it was not well formed?
Graham Stewart on March 9, 2009 5:57 AMoh god, I really hate the target=blank, it just makes my experience worse, i do know were i want the webpage to be open, i don't need any web designer to tell me that i need a new windows if he thinks i need it.
other important point, there is a huge advantage to follow standards, how do you like have to make workarounds to have the layout look close, no the same just close, on IE and FF? well, i hate it, at least the standards give me a little faith that it will be the same, without workarounds.
and I do care if a website that I make is validated, it is simple, there IS people that NEED to use screen readers, they don't have option, if I have the option to make their experience better, i will try to, regardless if there is a lot of them to increse my view counter or not
augusto hack on March 9, 2009 6:02 AMFor a blog with a focus on best practices, this seems like a very perverse post.
kit on March 9, 2009 6:13 AM@Jeff: When it comes to #4, I'd argue you really want an *API*, not a brain damaged wow, we can scrape your site as XML! mentality.
Although I know of some actual programs that live scraping other sites pages, I was referring to what you say, an internal API to build XHTML, to build a piece of markup that may be placed inside a web page, or sent to a less forgiving parser :-)
Filini on March 9, 2009 6:29 AM@ Screen Reader Advocates
Does having a website validate mean that it is screen reader friendly? I'm sure it doesn't hurt, but placement of navigation links, descriptions in hyperlinks, alt and desc (used anymore?) tags on images seem to be more important than validation.
I wonder how many people actually have used their sites with a screen reader, but they can be downloaded for free (very nice plugins for FireFox).
Point is that screen reader browsers behave a lot like others like FireFox/Chrome/IE where they do their best to make sense of gibberish and in most cases do a great job at it, even if the page doesn't validate.
The number one reason to use XHTML over html is that it contains an X - in some way it sounds way cooler!!! That's a naming that has a lot of following nowadays. Lot's of shit contains XXX. I should say that web development has got all XXXX (X-racy) - he he!!!
xxx on March 9, 2009 6:37 AM(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.)
If it is user-generated code, it should be inside a code tag...If you're talking about posts, limit the HTML they can use and check to see if it is valid.
You don't need to use XHTML, just make sure you validate strict. It is easy to do, and important if you want to have a properly formatted page with CSS. There is no CSS for invalid HTML, there are only hacks.
matt on March 9, 2009 6:55 AMAs a front-end designer/developer, I'm one of the few who does actually care if a site validates or not. Sure, I don't spend all day pinging URLs at the W3C validator, but if I DO happen to discover that a site doesn't validate, it lessens my respect for the site. It's a sure sign that the person behind that site is either too lazy, too ignorant, or just doesn't care about what they're producing. Conversely, if *that logo* is present, and leads to a successful validation result, I'm immediately given confidence in that site.
I can't believe you actually thing 'target=_blank' is reasonable behaviour in the 21st century. The rest of us have moved on.
Five Minute Argument on March 9, 2009 8:03 AMwhy write prprly f u get yr msg undrstd nywy?
I think that's precisely why.
Boro on March 9, 2009 9:48 AMI must say, I'm incredibly disappointed with this post. If everyone just did as they pleased, the Web would be a very messy place. Oh wait...
Keeping standards is Web development 101. I can't believe I'm reading differently on this site.
It's one of the reasons I love Python so much. People are forced to keep their code readable, in terms of indentation standards.
Jon on March 9, 2009 10:00 AMi'm not trying to be mean, but having been writing html and xhtml as strictly as possible since about 1998 (html 3.2 eeewwwww), i gotta say - all i'm hearing out of this post is alot of misunderstanding and laziness.
janos erdelyi on March 9, 2009 10:04 AMoh yes, lazy boy! using the right spelling and the right grammar seems to be a good idea - in english as well as in html / css and javascript. it is not so difficult after all. dyslexia is a learning disability, but nothing to be ashamed of. it is diagnosed in people of all levels of intelligence. if you are not able to master the language correctly you can always stay with loose.dtd. from the accessibility point of view only correct parsing is required, not 100% validation. but if you are just too lazy, another profession might suit you better maybe.
marge on March 9, 2009 10:34 AMi think marge is taking things the wrong way
janos erdelyi on March 9, 2009 10:58 AMi'll expand on what i mean - just a little bit. i have little interest in writing a full article here.
this may sounds counter-intuitive, but it is actually EASIER to write for strict DTD's and it's it EASIER to write for strict XHTML over HTML. there are fewer rules, less loopholes, etc - however you wish to put it.
markup isn't hard per se. it's more of an exercise in discipline and rigor than anything else. that's why i use the term 'lazy'. i'm not trying to insult anyone. there are things i'm lazy with - but i'm not lazy with my profession.
janos erdelyi on March 9, 2009 11:05 AMSome people on here are out of control.
1. To those who say using target=... is annoying... sorry! This blog is obviously filled with readers who know how to use their browser. I write web apps for a health care company and see employees who get hired and have to be shown what a mouse is. Try explaining how to open links in new tabs when desired vs. opening them in the same window. If they click an external link, they think they're booted from your app! So, as a programmer, I try not to think of the 3% of the company that can use their browser properly. I think of the 97% who can't.
2. Code validation DOES help your scripts run better. Think about one o the cardinal rules... have you ever had two elements with the same ID on a page and tried to document.getElementById() in your js? To make things FULLY cross browser compatible, it is less likely you will be able to validate your CSS, but your HTML should be ok. It's a good guide to keeping clean, but don't let it break your heart f you have to deviate to get something to work right. The question should be, if you need to hack together some malformed html / css to get your page right, how can you limit that code down to the browser you're trying to fix while getting the other browsers to ignore it?
3. If you see a set of rules as just a way to make your life harder, then get out of programming! It's all rules... and generally strict ones at that. People who throw out standards completely are just shooting themselves in the foot. I've tried to debug pages with display issues, and it is by far easier to debug when the original author at least MILDLY tried to follow the standards. It does make a difference.
JJ on March 9, 2009 12:22 PMFrom Nick on March 6, 2009 08:16 AM
HTML is not a visual formatting language, it is a language for defining
document structure. [...] The correct way to define the appearance of your
site is with css styles. Doing this separates presentation from content, and
makes your content more re-usable.
The vast majority of HTML pages are not about document structure. They are in
fact about presentation. The web designer is making content to present to the
user to read.
Style, size and font attributes let's one express visual changes succinctly and directly. Using css styles, especially with external css files is unnecessarily complicated for many common cases.
Why make things difficult?
Now, *if* you need configurable and consistent style control across a set of pages, then great, use css styles when ultimately save more trouble than they cause.
But don't force their use.
Consider (if there actually was html allowed in these comments) bthis/b bolded word. How would it help anyone if I was force to have a css style to express that the word needed to be bolded? Using the b.../b conveys it directly and is easy to type. Sure, a machine could do it, but why force the use of more complex software when it is not actually necessary?
For supporting true structured data requests, HTML is pointless anyway. Just use web requests that return data in directly machine usable form.
rblaa on March 9, 2009 12:36 PMI think webstandards matter, how about having a lot of extra markup:
Each button was set up with a nine-cell table so they could place each corner image, and still allow the button to expand in all four directions according to the width and height of the text inside
a href=http://stopdesign.com/archive/2009/02/04/recreating-the-button.htmlhttp://stopdesign.com/archive/2009/02/04/recreating-the-button.html/a">http://stopdesign.com/archive/2009/02/04/recreating-the-button.html/a">http://stopdesign.com/archive/2009/02/04/recreating-the-button.htmlhttp://stopdesign.com/archive/2009/02/04/recreating-the-button.html/a
About the target not allowed, a workaround is fairly easy actually. Just rewrite the URL's with JavaScript :)
Since the validator doesn't run the JS, it'll never know you use target's on your website.
Working demo on my blog :)
Webdevblog.org on March 10, 2009 2:22 AMI run a couple of non-profit sites that validate to XHTML 1.0 transitional. It's not terribly difficult to do so, but the sites are also very simple in their design.
I think the main advantage to using valid XHTML transitional is that it is always well-formed markup; browsers parse these pages more quickly and they appear to load faster. They render more predictably across different browsers and they also render very well in wireless devices with no additional modification.
If you use a good HTML editor a validator and are familiar with web standards, it's just as easy to write valid markup as not, with the advantages mentioned above. Your mileage may vary.
Snorey on March 10, 2009 2:44 AMSnorey, is your website static or not? Makes a big difference of course... Generated HTML from a dynamic (CMS, Blog and so on) isn't always in your control (not self made) and can generate invalid code..
Webdevblog.org on March 10, 2009 3:00 AM@Tom: 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..
The point I was making is that while it's true you can get the point across using poor grammar (read: standards), it's merely passing the buck - you're making the reader (user) do the work for you. Misunderstandings are far more likely.
Re: rblaa
You realise that by giving a document a presentation you're implying structure? Structure and presentation are not mutually exclusive. So yes, a vast majority of HTML pages ARE about structure.
Style, size and font attributes let's one express visual changes
succinctly and directly. Using css styles, especially with external
css files is unnecessarily complicated for many common cases.
Isn't that what the inline style attribute is for? Rather than having a tag for EVERY type of formatting, you have css properties. Otherwise why just have b, i etc. and not the whole arsenal?
How would it help anyone if I was force to have a css style to
express that the word needed to be bolded? Using the b.../b
conveys it directly and is easy to type.
Isn't that what strong and em are for? They describe structure, and imply presentation. b just describes presentation without saying why it needs to be that way.
CSS is meant to make things simplier anyway. If you want to change the appearance of something, you don't have to go searching through all the content to change it. If you also want to apply all that change, you can instantly. And if you want to edit some content, you don't have to wade through a mass of presentation junk.
This is the typical post that Jeff posts when audience goes a little down. Nothing gets more traffic than a debate. Ofcourse he is wrong. He knows he is, we know he is. But being wrong in the right way can be fruitful.
Andrei Rinea on March 10, 2009 4:59 AMI would love to fix www.microsoft.com's XHTML errors, but I've got bigger fish to fry.
Joe Chung on March 10, 2009 8:27 AMre: rblaa
part of the benefit of using html to describe the TYPE of content and not the appearance of the content is searchability, or in more broad terms - machine readability. xhtml rules help with this also - it's simply easier to parse something with can be counted on to have a sane structure at the most basic level.
also, who here wouldn't want a smaller, faster browser? all this cruddy, invalid html support comes at a cost. any team who makes browsers has to add in the ability to drag in garbage and spit out gold. the cost in development time, testing time, speed, and space are not insignificant.
also, i think it's shameful for people who work professionally in a craft to care so little for what they are doing. (so that's not aimed at people who don't do this for a living, please calm yourseves ;))
janos erdelyi on March 10, 2009 8:48 AMalso, who here wouldn't want a smaller, faster browser?
I know I would. But I don't expect to see it when the browser has to implement a thousand pages of bullshit standard.
XHTML+CSS has a lot of good ideas, it really does. Javascript isn't half bad either, but I don't think it should have much use if you design the system properly.
The problem is the system isn't designed properly. It's a giant mess. It is overcomplicated with the folly of wanting to support web applications.
A new web should be designed with a lean, meaningful standard, covering useful stuff and ignoring useless stuff. It should have a comprehensive test suite and reference implementation from day one.
But this will never happen. Everyone will keep throwing more and more at the existing garbage, bloating up the worthless standard, bloating up the unstable browsers, bloating up developer's minds.
All we can do is wait for the inevitable day when it comes crashing down under its own weight.
anonymous on March 10, 2009 10:18 AM@Joe (three up): It's highly ironic that microsoft uses an xhtml doctype..
When it comes to validation: Know the rules, live by the rules (for a while at least) and learn when you can bend/break them. *Don't* break them out of misplaced laziness. Triggering standards mode makes me happy (use FFox+WebDeveloper and a green V will make you happy too).
This is just more communal jibber jabber. There *are* big problems with all this tag soup out there.
Charles on March 11, 2009 4:57 AMFrom Jon on March 10, 2009 03:09 AM
You realise that by giving a document a presentation you're implying
structure? Structure and presentation are not mutually exclusive.
Of course. My point is to argue against the notion that web designers must give an HTML document a display-agnostic structure in the usual case. In practice people don't do that. They in fact don't need to. Note that this is an orthogonal issue to the writing of clean maintainable code/html/markup.
It all depends what your goals are. Style sheets are a useful tool, but they need not be mandated for all cases.
Isn't that what the inline style attribute is for? Rather than having a
tag for EVERY type of formatting, you have css properties. Otherwise why
just have b, i etc. and not the whole arsenal?
It is not the precise syntax I was caring about. Inline style attributes are fine too. What I really object to is the forced separation of display and content, since the work required to associate them can cause unneeded complexity for the simple case.
If I just need to bold something, why would I use anything else except b? It's meaning is clear, and succinct. If I am not intending for the page to used in any other content other than this particular HTML usage, then why pay the cost of maintaining a display-agnostic content?
Do the work you have to and no more, and that work you do, do it right.
CSS is meant to make things simplier anyway.
I in fact use CSS when it helps me, notably when I have shared styles that give sets of pages a consistent look and feel.
From janos erdelyi on March 10, 2009 07:48 AM
part of the benefit of using html to describe the TYPE of content and not
the appearance of the content is searchability, or in more broad terms -
machine readability
This seems reasonable on the face of it. But when you dig into each problem, there are simpler ways to do it. Instead of forcing the web designer to take the care to have display-agnostic displayable pages (!), searching is solved by stripping out all markup.
As for machine readability in general, having any sort of processing based on scraping web pages to derive query or report results is asking for trouble. It is far easier to have the web site support a reasonable web service API where the artifical HTML parsing problem can be completely avoided, and results given directly in a form where they can be readily consumed.
also, who here wouldn't want a smaller, faster browser?
For what it's worth, I too would prefer a web standard that was not so lenient, with clean parsing rules.
rblaa on March 11, 2009 1:53 PMYou really should stop advocating sloppy quality. We all get that you're a kickass programmer, but as of late, you've been making people have doubts. First you say that the SOLID principles are bureaucratic and moot, and now you say that validating HTML is not that important.
Most novice developers will read your blog and fail to take your advice with a grain of salt. You have a large influence in the software development community and lately, you've been very callous. The more experienced devs will instantly recognize when you start spewing non sequiturs such as this blog post and actually give you the reasons on why you're wrong. Unfortunately not everyone will instantly recognize this or take the time to read the comments especially if they are being read in an a blog reader such as GReader which does not show comments.
Please be more careful on what you write in your blogs.
MikeA on March 12, 2009 8:51 AMValidation will be more important when google decide to make it a variable in the pagerank algorithm
All Inclusive Los Cabos on March 14, 2009 12:41 PMNot writing valid XHTML because you can get away with it is like saying you don't have to write good code if the compiler lets you get away with it. People need to realize that HTML is not just for making text look pretty. HTML IS code, and should be respected accordingly.
As what stated before, you should want to use XHTML and serve with an XML content type so you can use SVG. SVG is being supported a lot more on the mobile space and even though Adobe has dropped it it is still a very important technology.
Yes, IE doesn't understand it, which is why you need to do some content negotiation on the server. And, in some cases, it might be possible to serve up some VML for IE. Also, you can always generate PNGs from your SVG if you need to.
Yes, it takes more work to do this, but just because doing something is hard doesn't mean you shouldn't do it. The user experience comes first, always. If you don't respect your users they won't respect you.
One more voice on March 15, 2009 11:43 AMJeff: There's no need to make a horrible aliasy version of the valid HTML 4.01 icon by scaling up the thumbnail: W3C have an a href=http://validator.w3.org/images/valid_icons/valid-html401-v.svgSVG version of that icon/a and you can either use it directly, or scale it to a size of your choosing and then rasterize the result.
Gareth Rees on March 16, 2009 8:42 AMHear hear! I can still remember being chastised in front of the class by one of my tutors at University for not validating HTML - I should have asked him how many validation errors he thought Amazon had. (hint: lots more than mine).
Clare on March 16, 2009 11:43 AMEh, I can sympathize with both sides. Yes, standards are important, and yes, as a programmer I vastly prefer strict error handling than sloppy ah, we'll make sense of your code somehow, don't worry. In theory, XHTML is nice enough. In practice, it's almost useless because of lack of support, inconsistent backwards compatibility (allow the same MIME type as HTML for backwards compatibility and make a few other concessions and then pretend it's compatible, and ignore the half dozen differences that would make a proper HTML parser choke on even the simplest XHTML document.
And then we have the even older HTML4.01 which was just a huge mess from the beginning and just.... sucks. It's a pain to parse, not a single browser does it correctly (it's ironic that the article Jeff linked to actually uses browsers shortcomings at parsing HTML as a reason not to use XHTML) and other agents have a hell of a time extracting data from it too (Certainly doesn't make it easier for the semantic web or microformats to take off if parsing a web page is all but impossible)
So we have a choice between the spec that works in theory, but not in practice, and the one that's completely flawed in theory, but which actually works ok'ish in practice because everyone are willing to bend the rules a bit, and browser vendors go to the most insane lengths to make sense of malformed HTML.
Thank you, W3C, for making web development such a hell. It's like every other bad decision in the history of computers rolled into one. All the messiness of the Windows API, x86 CPU's and C++ rolled into one.
jalf on March 17, 2009 9:28 AMI agree, nobody gives a rat's ass about validation in the real world. Only overstuffed pompous web developers who probably sucked up to their mother's all their lives and still do at the age of 35. Just give it 5 to 10 years (if the web is still around), either validation will kick in and a web page won't display at all until it's valid -or- validation standards will become such a problem, they'll just fall off the end of the earth and be one of those I remember the day when... things. For the time being, who cares if if validates!
Nobody on March 18, 2009 10:08 AMActually the doctype trick works well in Konqueror as well (as of 4.2.61 at least).
divide on March 20, 2009 6:15 AMTo answer your question I mean, who makes up these rules? And for what reason?, this is why:
HTML: HyperText Markup Language
What wikipedia says about markup language: A markup language is a set of annotations to text that describe how it is to be structured, laid out, or formatted.
Markup language describes the *STRUCTURE*, not whether that structure should float: right or have a red background. This is what makes width=80 bad and style=width:80px good.
At first everyone complained about the apparent lack of standards on the web, and now that we have them everyone started complaining it's too strict.
Yes, damn it all, let's make it even more strict! I don't see anyone complaining about C++ compilers not allowing sloppy code mixed with..oh I don't know..PHP? ..yet everyone picks on HTML. WTH?
dr. Hannibal Lecter on March 20, 2009 6:30 AMAs a web developer, I can't understand why people make such a big deal about coding in html or xhtml, I prefer xhtml because it appears much cleaner in my eyes and validating isn't hard, we do it on every project and very rarely have to bend the rules for complete cross browswer compliance. Whats the big deal? if you find it that hard, what else do you struggle with?
Mark Scott on March 20, 2009 10:12 AMnext thing you're going to proclaim 'vote tables for layout'...
Mark Scott on March 20, 2009 10:13 AMBadly need your help. Awesome website, glad we found you. Help me! There is an urgent need for sites: kitchen islands. I found only this - a href=http://purifiersair.biz/Air purifiers uk/a. Select flights to track from airline websites with the yapta browser add on. To book your flight visit palas travel cheap airline tickets travel deals. Best regards :mad:, Lobo from Kyrgyzstan.
Lobo on April 20, 2009 7:51 AMIn my opinion with a valid code by W3C you will be sure that your content will be indexed by crawlers.
Marcos on April 20, 2009 8:23 AMIn my opinion with a valid code by W3C you will be sure that your content will be indexed by crawlers.
http://www.otimizacao-de-websites.com
Marcos on April 20, 2009 8:24 AMExcuse me. If we fall, we don't need self-recrimination or blame or anger - we need a reawakening of our intention and a willingness to recommit, to be whole-hearted once again.
I am from Ireland and too bad know English, give true I wrote the following sentence: Low on thyroid, use synthroid to your benefit.
Best regards :-D, Lloyd.
Lloyd on April 22, 2009 7:05 AMSorry. What more felicity can fall to creature, than to enjoy delight with liberty.
I am from Cape and learning to write in English, give please true I wrote the following sentence: Purchase synthroid without a perscription.
Thanks for the help :o, Melba.
Melba on April 26, 2009 6:27 AMVery good your site ..
Structured content and relevant .. congratulations!
http://www.sexshopvendas.com.br
Sex Shop on April 28, 2009 8:26 AMThe very good post
the congratulations of this blog .. I will return several times
to check the content!
xhtml strict and all this fucking bullshit validation garbage is for those cum lickers who think validation is so important to our lives.
validation is a load of old cum shit.
those that think its so important need to fuck off and stop fucking their mothers.
people are dying in third world countries, and you think by making a shitty piece of html or css valid is going to improve your life?
life is too short to fucking waste on "validation".
validate my big black cock if you are so enthusiastic about it people.
fucking pricks
This goes to Nick, whos site is http://www.charcoaldesign.co.uk/
You talk a big game here, yet your site is invalid.
Do not speak when you can not backup what you act like you do yourself.
RJ on July 23, 2009 9:57 AMA lot of people make their own website. They are not pro designers and they have no clue about validation, and they are not departing. Their number is increasing and they will sometimes use tools that produce fairly valid code, but often not.
Most comments here are entirely focused on pro web development, but that's not 100 percent of the web and it never will be. Sorry, but you will never have an exclusive web club that eschews imperfection.
Eric on July 29, 2009 3:03 AMthis is a test here.
test on August 13, 2009 7:30 AMwww.codinghorror.com/blog/ got :42 Errors, 57 warning(s)
Mike on August 13, 2009 10:43 AMGoogle Seo,search engine optimization,seo techniques,google adsense
The concepts mentioned above are not olmassa for a site ..
Thank you for this article .. Anyone can inform ..
Google Seo,search engine optimization,seo techniques,google adsense
The concepts mentioned above are not olmassa for a site ..
Thank you for this article .. Anyone can inform ..
Typically when I see that button, my first thought is lets see how much of a lie this is. And about 70% of the time I'm right. :-)
Jason Baker on February 6, 2010 11:13 PM@Rick Dailey: Your comment makes too much sense - Jeff doesn't care because being reasonable and non-combative doesn't attract the quantity of traffic that Jeff has become accustomed to. Passionate opinions, even if uneducated, misguided or just plain wrong, polarize people and get them riled up. That's good for business.
In actuality, I guess the best result from posts like these is the resulting conversation, and that is what blogs should do - start or participate in a conversation with the readers. I just don't know that this particular conversation is useful...
Jason Bunting on February 6, 2010 11:13 PMOh boy Jeff... Please don't spread this kind of amateur misinformation.
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
_target is a usability issue. Nothing annoys me more than clicking a link and having it open in a new window without my approval. All links should open in the active window unless one explicitly says otherwise (eg. by middle clicking). The workarounds are kludges because you shouldn't use them! What's the point of technically conforming to the spec if you are only going to insert the same violations through a backdoor such as Javascript so they aren't detected by the validator! Pointless. Might as well not validate in the first place, if you don't believe in the W3C's take on these matters.
Does it really matter if we render stuff this way... ...versus this way?
Jeff, the two examples you gave are both bad. We're talking separation of concerns here. The second one with the style attribute properties should have been pulled out to a CSS document. How can you not know this, given that you've already made the somewhat flawed analogy between html and css as the model-view-controller architecture? Presentation data goes in a stylesheet, while the information goes in the HTML document.
anon for this on February 6, 2010 11:13 PMor you could use a view engine that outputs xhtml like
http://code.google.com/p/nhaml/
Good reading: http://www.cs.tut.fi/~jkorpela/html/validation.html
Simon Sigurdhsson on February 6, 2010 11:13 PMThe worst website I've found for W3C recommendations compatibility is:
www.amazon.co.uk
Approx 1300 errors and 136 warnings.
Jon Bevan on February 6, 2010 11:13 PMA simple compromise:
Use the validator to highlight *potential* errors, then correct the ones you agree with.
Jason Cohen on February 6, 2010 11:13 PMAs a mobile web developer i hated validation but it was a must for WML.
I know so obsessed with it that i validate most of the web sites i visit :S
I don't agree with this: 'The whole HTML validation exercise is questionable, but validating as XHTML is flat-out masochism.'
Different coders have different styles -- and many of the best websites don't validate -- but writing valid XHTML just isn't that hard!
Whatever -- I think the main reason to write completely valid (X)HTML is to avoid *malformed* code (e.g. missing end tags) rather than *invalid* code (e.g. an input as the direct child of a form element).
Whenever you see a validity error (e.g. with a Firefox add-on, or in a build process or whatever) you know there might be a problem with HTML structure. Malformed code can cause problems that are hard to debug. This is particularly true for pages that are built dynamically.
Likewise for CSS and JavaScript: validate to help avoid bugs, not for its own sake.
Sam Dutton on May 4, 2010 8:03 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |