HTML errors , eradicate them all?

Can anyone tell if a website has 50 HTML errors on a single page, are we suppose to sort out all of them or fix most fo them? and if there are only few HTML errors shall we let them be there? does it matter to google, search engines?

 

Really, there is no excuse for html errors on a page. They should all be fixed. There are a couple of problems with that view: The author may not be fully competent at html, otherwise there wouldn't be all those errors. That may be compounded by the generic CMS in use and the idiotic themes that are really poorly written (a huge percentage).

It may be that the page works as expected even with the errors. The problem there is that an error laden page tends to be fragile. A web page is a living document that gets content and presentation updated on a regular basis. Even the simplest change may trigger a breakdown. Further, markup errors may render the page unintelligible and un-navigatable to folks using non-graphic browsers or assistive technologies, e.g. plain text browsers, Braille displays, aural screen readers (Jaws, Emacspeak, Orca, etc.)

Not so much syntactical errors, but semantic errors can affect search engine ratings by applying the wrong weights to content, giving too much to some content and too little to other text. You end up ranked for the wrong search terms.

Disclosure: I have never delivered a generic CMS to a customer. I have been hired to fix them, though. I prefer a bespoke CMS; they are lighter, with cleaner coding, maintainable and more easily debugged.

In the end, fix the errors. You'll be glad you do.

gary

 

Hay Garry thank man for such detailed information. I owe you thanks and once again you're a rock star!

 

Gary can you advise me regarding the HTML & CSS on this , website if they are OK? and what implementations can we consider

http://www.desertsafarisdubai.com

 

Hello. I recommend you to read these articles and then start the site again:

http://cutcodedown.com/article/whats_wrong_with_YOUR_website_index
http://cutcodedown.com/article/progressive_enhancement

Don't forget to check accesibility issues with achecker.ca

 

Thank you Puntocom81, let me check it now

 

Damn, that achecker.ca thing has some serious issues. Or, rather, brings up a lot of potential issues that aren't issues.

 

Just because an error checker says there are a lot of errors on a page does not necessarily mean that there are. A single error can generate dozens or even hundreds of pseudo errors, that is, errors because of the cascading effect of the code. Best policy is to fix the errors one at a time starting at the top, then checking again. You will find that dozens of "errors" will disappear because they were never errors in the first place.

 

I'm sure there are better markup checkers, but I use Firefox's View source so I can find the errors more easily. In your case (apart from the bad markup):

<meta name="description" content=" Desert safari extravaganza in Dubai, absolute and sharing Dubai Desert tours available on all the days during the week. Most wanted Dubai Desert safari packages with ABA Tourism./>
<meta name="keywords" content="Dubai desert safari, desert safaris Dubai, desert safari in Dubai, Dubai desert safari tour, Dubai tours, desert safari tour Dubai, desert safari tours in Dubai, Dubai Desert safari offer, safari tour Dubai, Safari in Dubai " />

Code (markup):

Notice the lacking " at the end of the description.

Keywords should be no more than 7 keywords, not phrases.

<ul><li></a></li><li><li></a></li><li><li><a href="/sitemap.xml">Sitemap</a></li><li>|</li><li><a href="desert-safari-dubai-contact.html">Contact Us</a></li></ul>

Code (markup):

There you are closing non-opened a tags. By the way, why do you link to the sitemap.xml from the website? it should be in robots.txt this way:

Sitemap: http://example.com/sitemap.xml

Code (markup):

 

Thank you Dear

 

I built a few sites back in the day when I knew nothing about HTML (honestly, I still suck at it even today). So if I tried to eradicate ALL the mistakes on ALL my sites I'd have to spend several months just doing that. No thanks, don't have time for that. The best thing anyone can do is build everything the way it's supposed to be (best practices from A to Z). It's hard to change a large site with a few hundred pages and several css files to be what it is supposed to be. Seems like an utter waste of time. If it works in all browsers, is not slow or broken, I usually say "f*ck off, I am not changing nothing".

 

If the site is coded properly, it shouldn't BE a lot of work. Depending on what you have used, change the template, or the few pages that actually doesn't pull from database or similar.

Also, remember that depending on what checker / tool you're using, some errors that pop up might be ignored. Like the errors showing if you do more than use "screen" as media-type when calling CSS. Those errors can be safely ignored. What you should check is errors with duplicate IDs, missing starting or ending tags, and similar. Those can quickly mess up your site.

 

You can see your HTML errors via view-source. On mozilla the code that contains errors is bolded and has color red.

 

Your design shouldn't contain error. You can check markup at http://validator.w3.org

 

One of the things about HTML errors to keep in mind is what document type is it? If you have errors in a HTML 4 Tranny or XHTML 1.0 tranny document, the site is guaranteed to be incompetently coded rubbish. Transitional LITERALLY means "in transition from 1997 to 1998 development practices" and should NEVER have been used for building new websites. It is so permissive of allowing garbage into a page that if it's showing errors... well, that takes a special kind of special; in the same way some Olympics are "special".

In a 4 Strict or XHTML 1.0 Strict document, there is no reason to have invalid code. PERIOD. The page should have been well written following the rules. It's that simple. The problem with this is a lot of the goofy crap people want to use on pages (iframes, target, the new HTML 5 stuff) doesn't even EXIST in strict... it doesn't exist for a reason (most such things being insecure rubbish or a middle finger to accessibility) but that doesn't stop most halfwits, morons, and fools from trying to use them.

HTML 5 on the other hand -- train wreck of bullshit because it's documentative, not authoritative. It's simply not written with even the CONCEPT of telling people how to make websites as part of its intent. In many ways HTML 5 is "the new transitional" in that it allows a slew of crap to be done that shouldn't be done, re-introduces old redundancies 4 Strict was trying to get rid of, re-introduces presentational concepts that 4 strict was ALSO trying to eliminate, and worst of all introduces all new pointless redundancies.

It WAS until very recently the same story as with 4 tranny - if you had validation errors it means developer ineptitude of the highest order was likely involved... the problem is they've made some new changes to the validation and rules that are absolute 100% grade A farm fresh 1948 Ford Super De Luxe filler taking their barely meaningful "validation" tool, and making essential bits of functionality now invalid.

See "media targets" where they've removed "projection" and "tv" as valid targets -- even though there are PLENTY of Kiosks and Tv based browsers that use those values... This change also makes ZERO huffing sense since WHICH media targets are valid should be NONE of the markup specifications damned business, and just further increases my lack of confidence in the WhatWG or W3C's competence, motivations, or even qualifications to be allowed to remain in charge of the specifications to build websites.

That they clearly have zero concept what the word specification even means anymore having a lot to do with said attitude.

As such, with HTML 5 validation much like with the pipe-dream that is CSS validation, it now comes down to not if the code is "valid" or not, but WHY is it invalid. There are things the validator will bitch about that are essential functionality or intentionally broken on the part of the developer, so like most automated tools it's important not only to know what is invalid, but WHY!

Now, all that said, as to the site you linked to...

Validation is the LEAST of your worries!!! Design-wise ALONE it's flipping the bird at accessibility with illegible colour contrasts, fixed metric (aka pixel) font sizes, and a fixed width non-responsive layout. Design ALONE it's an epic /fail/ showing utter and complete ignorance of accessibility norms; in the traditional "WCAG, what's that?!?" way.

As to the code, it's an old 4 tranny document meaning there's NO excuse for anything to be invalid -- that said it's surprisingly clean despite a nasty case of "DIV for nothing", lists wrapping non-list elements (big tip, if it's big enough to have a h3, it doesn't go in a LI, that's redundant semantics!), clearing DIV like it's still 2003, tables for layout, endless pointless META not one legitimate UA would give a flying purple fish about, lack of media targets, overstuffed keywords meta that would/should result in getting ignored or slapped down by search, etc, etc, etc...

The anchor inside <head> being the biggest glaring fault, as is the lack of closing a script, much less </body> and </html> being nowhere to be found... and the jQuery for nothing trash.

It needs a lot of work -- the design isn't even close to viable, and there's enough mistakes in the markup I'd be tossing it to start over from scratch.