Forum Moderators: open
I was just performing a quality check on recently changed pages and WHAM! 47 errors on a page. Yikes, where did that come from. To the untrained eye this would have been enough to make me hit the back button and just avoid the whole process altogether. The site works and looks just fine, I have no idea what those 47 errors were, are, will be. ;)
I check the first error in sequence and I left out a closing </p> element. Run validation again and tada, all is fine. Yes, one closing </p> element missing and it caused a cascade of 46 other errors. When I first started validating (a long, long time ago), I remember looking at those errors and gasping. Then I realized that if you take them one by one as they are presented, you'll find that many of the following errors are a cascade of the ones up top. Did that make sense?
I know we've had topics in the past on the most common validation errors and I think it is always good to refresh memories and alert new Webmasters that there is nothing to FEAR when validating documents. It may appear to be somewhat major at first but once you start addressing the errors in sequence, you may be able to go from 300+ to under 50 with just a few corrections in your HTML. The example I provided above with the closing </p> element is a primary error that many run into. Just one or two missing and/or incorrectly nested elements and validation is a mess.
Remember, take the errors one at a time and start at the very top of the validation report. Don't jump down to the middle of the report as that won't do you any good. You have to address the errors in sequence so that you don't end up "chasing the cascade".
W3C Markup Validation Service
[validator.w3.org...]
W3C CSS Validation Service
[jigsaw.w3.org...]
W3C RDF Validation Service
[w3.org...]
How many errors do you have on your home page this very moment? Let's get them corrected. No code dumps please. Just the first error in sequence and we can work from there. If you have hundreds, well, you'll probably need to follow along and work most of those out yourself. There will be many here who will most likely have upwards of 200, 300 and even 500+ errors. If you have errors in this number range, this is something that should be looked at soon as there are surely some in there that are potentially fatal in nature. I can understand a handful of common errors. But not a high number of uncommon errors, those could be trouble.
Why did you go that far? Have you tried to validate THIS page? Not that bad though validator reports 43 errors and 4 warnings
I've actually gone to my affiliations and have told them that if they could not provide valid affiliate code, I would not sell their product. Believe it or not, both that I've gone to in the years have fixed their code to be valid.
How could you threaten to not sell their products? That would just mean it's money out of your pocket, for what? What difference would it make if they make their code valid? Obviously they code the already had worked, else no one would use. If they change it to valid code, it will look the same, will act the same and will sell the same amount of product as it did.
How could you threaten to not sell their products?
Easily. I'm that kind of person. But, it wasn't a threat as you say. It was a conscious choice not to include their affiliate code on my web pages because it would not validate, period. :)
In this day and age, it is pretty much a moot point. You can easily drop that stuff into an <iframe>, switch to a Transitional DTD and validate, no big deal. Amazon is a prime candidate for the <iframe> element. So is any other third party content that does not validate. Throw it into an <iframe> and be done with it.
That would just mean it's money out of your pocket, for what?
The principle of the matter. I wasn't exactly starving at the time the offer was on the table. ;)
What difference would it make if they make their code valid?
A big difference for me. Why? Because I may tell an untold number of others that hey, this company is serious about their image and are willing to do whatever it takes to make "everyone" happy. And get this? They have a solid performing product too, well worth the affiliation.
Obviously they code the already had worked, else no one would use.
Ya, it worked, just like 95% of the code on the Internet works. That is because the browser manufacturers have spent thousands upon thousands of man/woman hours into the development of their product so it displays your borken code properly. ;)
If they change it to valid code, it will look the same, will act the same and will sell the same amount of product as it did.
Hmmm, it may not look the same nor may it act the same. And I feel that the product might sell just a little better if Webmasters could rely on the affiliate code being 100% error free, that would be a really big plus for me, obviously.
Pssst, the <iframe></iframe> element is your friend in this instance, it really is. I sure wish papabaer was still active here. Man, he could whip up a valid HTML/XHTML Strict website using <iframe>s all over the place. I learned much from him about using that <iframe> Element.
Now, however, I'm a little confused about something else;
valid HTML/XHTML Strict website using <iframe>sWhat am I missing? I thought iframes were not valid?
Hello! P1, that's a great idea. I missed that tidbit from papabaer, but it's so obvious once you think about it. In some cases it would also make things easier to manage. I will have to look into it WRT tracking and what not (i.e. calling the iframe source with a GET param from the enclosing page).
I've just started looking at affiliate stuff and it bugged me that it made it such a hassle to validate.
I will tell you one thing, all of my sites do validate that is the ones that I own.
To validate every line of code for every client would not only be next to impossible, it would be a major waste of time.
Websites for most people are to make money, I have not seen a difference in the SEs rankings to make me change my mind about this.
Some of you need to get off your soap boxes for a minute.
There is no need to throw around insults about stupid errors if the pages display correctly.
Maybe some day careful coders will get rewarded for the extra work, today though they are not, therefore if you have a sizeable lot of websites you administer it really is a complete waste.
Edited typo
...if the pages display correctly
"display" is such a "visual" word.
i wonder if the googlevision patent has been written yet...
I am not trying to imply if G don't care we should not at least make an attempt at coding our websites to validate.
On the other hand I would not hesitate faor a moment to publish pages missing an alt atribute cuasing it to fail.
What annoys me is things like & needs to be & ... I especially hate this when this affects links that have urls which include variables... so annoying.
"" IE8 is very strict, make sure you fix any errors using W3C validation, solved my problems. ""
Line 2, Column 506: cannot generate system identifier for general entity "colorScheme".
…href="css/styles.css?template=av-155&colorScheme=green&header=&button=buttons
✉
An entity reference was found in the document, but there is no reference by that name defined. Often this is caused by misspelling the reference name, unencoded ampersands, or by leaving off the trailing semicolon (;). The most common cause of this error is unencoded ampersands in URLs as described by the WDG in "Ampersands in URLs".
Entity references start with an ampersand (&) and end with a semicolon (;). If you want to use a literal ampersand in your document you must encode it as "&" (even inside URLs!). Be careful to end entity references with a semicolon or your entity reference may get interpreted in connection with the following text. Also keep in mind that named entity references are case-sensitive; &Aelig; and æ are different characters.
If this error appears in some markup generated by PHP's session handling code, this article has explanations and solutions to your problem.
Note that in most documents, errors related to entity references will trigger up to 5 separate messages from the Validator. Usually these will all disappear when the original problem is fixed.
[edited by: eelixduppy at 7:34 am (utc) on Jan. 29, 2009]
[edit reason] disabled smileys [/edit]
href="css/styles.css?template=av-155&colorScheme=green&header=&button=buttonsThe ampersands
&&Ya, we know, a real pain in the arse and one of the most common errors too.
Thanks!
href="css/styles.css?template=av-155&colorScheme=green&header=&button=buttonsThe correct valid example with encoded ampersands...
href="css/styles.css?template=av-155&colorScheme=green&header=&button=buttonsNote the addition of the
amp;&
Google has yet to release a validated version of any of their properties.
Google has started publishing some conformant HTML5 [html5.validator.nu] pages(!)
Why would they deprecate the ACRONYM Element? I don't understand that decision. It is different from the proposed replacement which is the ABBR Element. Those two elements have distinctly different meanings. It's unfortunate because many have confused the two over the years, myself included. It finally clicked one day on how to best make the decision between the two. But now we standards evangelists FAIL, FAIL, FAIL!
Am I going to make the changes to validate against the HTML 5 proposed standards? I don't think so, not yet anyway. I'd like to take this...
Error: The acronym element is obsolete.And do this...
Error: The use of HTML 5 is forbidden.Hey, I do have a sense of humor at times. Ask Simon. ;)
Pssst, don't tell anyone that I do everything in FrontPage 2003 mostly.
Heh, me too. I love the code view editor.
That said, I put a whole lot of blame on Front Page and IE for the whole validation problem to begin with. FP made it very easy to create some pretty horrendous code, and IE has always "forgiven" a lot of stupid coding mistakes.
I like seeing the green check marks. And I don't intentionally put any ad code on that won't validate (even had to get a special dispensation on my search boxes from Google)
It's just as easy to do it right the first time, and not worry about it later.
I put a whole lot of blame on Front Page and IE for the whole validation problem to begin with. FP made it very easy to create some pretty horrendous code, and IE has always "forgiven" a lot of stupid coding mistakes.
:-(
PEBKAC
Is that an abbreviation or an acronym?
Is that an abbreviation or an acronym?
It would be an ACRONYM under the HTML 4 Specifications.
It would be an ABBR under the HTML 5 Specifications.
Now tell me, who was the Scientist that felt the ACRONYM Element needed to be deprecated in HTML 5?
<acronym title="Problem Exists Between Keyboard And Chair">PEBKAC</acronym>
The nice thing is that proper use of doctype will allow you to maintain you validation.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
I knew that P1R
I knew you knew that. ;)
The nice thing is that proper use of doctype will allow you to maintain your validation.
I knew that WBF. :)
The W3C is an industry trade association.
(For a commercial enterprise, membership is appr. $65,000.00 US a year. Plus I'm sure there are other fees that crop up for various activities.)
I didn't vote for them, they don't solicit my input, and all I care about is the "common standard", that is, what the current crop of user-agents currently support and are likely to support long into the future.
If that's the W3C specs, so be it.
But, as browsers adjust their rendering engines to display the latest html spec, their rendering engines could easily break some or all of my pages, because a bad practice I copied from site to site, to site.
Now, I have 100s of broken sites, 10s of 1000s of broken pages. And lots and lots of angry clients.
...and months of work to validate sites, recoding, and much of it, out of my own pocket if I want to keep clients.
A page coded to standards, without use of hacks either in CSS or browser-specific conditionals in Javascript or HTML, will **ALWAYS** degrade gracefully over time in spite of browser versioning.
Code to standards = less work and increased client trust.
A friend recently sent me some "essential reading" which gives a lot of insight into why IE rendering is so very random at times.
MSDN: "HasLayout" Overview"
[msdn.microsoft.com...]
The first line of which starts "There are several bugs in Internet Explorer ...", and this is published on MSDN. If MS is willing to have that article on MSDN, written as it is by Markus Mielke, a program manager on the Internet Explorer team, you know something is fundamentally wrong with the product.
Satzansatz: "On having layout"
[satzansatz.de...]
This is a rather long article, but very, very detailed and worth the read.
After reading through these, I wonder why Trident (IE's rendering engine) hasn't been rewritten from the ground up yet?
A look on wikipedia about acid test compliance is quite revealing. All major browsers, except IE work with ACID2. IE8 is supposed to finally get ACID2 right, but isn't even close to ACID3, while most other browsers are either compliant, or close, and what they fail on in ACID3 are some esoteric and not fully accepted standards yet, while IE8 is an amazing scoring 20/100...
Last March at ACID3's release, all the other browsers at that time, were already scoring at minimum 41/100
Eventually browsers follow the standard though, or very close to it, so coding sites to the standard, and then conditionally fixing rendering issues, is the most future proof approach...especially if you keep your conditional hacks centralized, so if the rendering is fixed you can easily remove them.
Sure that's an initialism. :[ducks and runs]:
I can't say I've ever created a site with much content that didn't require browser specific conditionals, because IE is horribly, horribly, broken.
I can, but it requires backing off my ego, scrapping the idea that brought me to the browser clash, and approaching the problem in a different way, sometimes even applying a new design. It's just not worth forging it through for the very reasons you mentioned in the previous post.
