Why should I care about CSS/HTML/JS validity, when I'm going to be checking if it works in all browsers, anyway?
I never understood the whole "Does it validate!!??!" mantra with HTML. So, what, I can't add my own custom attributes to HTML elements (which makes lots of JS magic possible) because the HTML spec will go berserk over it?
IMO, cross browser testing trumps all this validation nonsense (which all browsers have some bug somewhere with, anyway). Enough.
If my compiler gave errors for things like "invalid syntax in IF statement: 'if (true)' -- REQUIRED SPACES ARE MISSING, SHOULD BE 'if ( true )'" then I wouldn't consider it any sort of technical achievement that my code compiles without warning.
137 warnings, 5 errors. Let's take a look at what expert advise the validator offers, so that our webpages will be forward compatible (or whatever the supposed purpose of this is for).
It complains about every href that has "=" or "&" in it, claims you must put an ALT attribute on images, says <tr></tr> is invalid... etc. It essentially complains about things that have no effect on anything, but for some reason or another the W3C decided to put into their standards and enforce it.
W3C: how about you come up with something useful... like, for instance, allowing me to center a fucking DIV with CSS. With tables, I can simply... just kidding. But seriously, I have qualms with W3C.
It complains about every href that has "=" or "&" in it
You should escape characters such as these, as they have different meanings in the source context. It's merely a courtesy that the browser knows what to do with them.
you must put an ALT attribute on images
This data is used not only as descriptive text, but as a replacement for missing images and for those who use screen readers.
<tr></tr> is invalid
Of course it is, it's empty. Why do you have an empty element? It shouldn't be there.
Worry about errors or don't, I certainly don't care either way, but there are good reasons for those errors. The only difference between compiler warnings and validation errors is you don't care about the latter. Major browsers are nice enough to allow you not to care. That courtesy doesn't magically turn syntax errors into style guidelines. Ugh.
So I should escape characters that are already inside of double quotes.. great. And the fact that all browsers support unescaped HREFs means nothing in the face of the almighty "Look! I validated!" claim.
ALT attributes provide descriptive text and are replacements for missing images. Great! Now, why are they required? Not to mention, any use of any attribute not on the list will get you unvalidated. Suppose I want to include some extra data for JS, like "_droptype" or "_isDraggable". Sorry! It's not on W3C's list of acceptable attributes so you fail validation, even though all browsers ignore attributes they don't know about.
An empty tag... why do I have one? Well, maybe because inside the tag I have server generate text.. .and instead of doing;
if ($text) echo "<tr>$text</tr>"
I do
echo "<tr>$text</tr>"
Would it be so hard to make the standard: "If theres nothing in the tag, treat it like it doesn't exist"? No.
Furthermore, I have blank DIVs to take up width/height sometimes. Then again, I'm sure there's some clever way to wrap 20 DIVs and put browser specific hacks so it actually validates... but I prefer to do it the way that works.
Major browsers are nice enough to allow me to not care. So show me errors that I need to care about. W3C validation, to me, is like saying "I memorized every little gotcha that W3C implemented... and still, everything works! Aren't you impressed? Five years from now, the site should still work! Forward validation! Yay!"
I understand your qualms, everybody has them. But aiming for validation is really a good thing because the validation plugin will then immediately notify you about screwups, by refusing to display that green checkmark.
Also a validating page puts you at least on some common ground with the browsers. That way you can focus on the known, documented inconsistencies without potentially adding new side effects through parsing errors.
One of our recent suppliers is a security provider that offers a service we want to resell.
Their management website has a "mailto:" button for support. It doesn't work.
How can you a) break a mailto link in the first place, b) not notice the support option doesn't work, and c) expect me to trust you with security with attention to detail like that?
Maybe you can add "Check basic functionality" and then I can forward this to them... ;)
Nice; the old I tried to send you an email about the problem but your email doesn't work...
In my experience this is often the result of a lack of communication between the person who can set the MX records and the person who builds the website.
I would alter those checklist items to:
a. check that advertised emails are functional and reach the correct recipients
b. check DNS records for validity and speed of access
Along with creating a sitemap, you should also add your site to the Google Webmaster Console/Yahoo! Site Explorer to monitor any errors and last crawl date etc.
Also, along with checking different browsers/resolutions you should also view the site on multiple PC's as colors tend to vary dramatically. Keep in mind that not all consumers use high end monitors/pcs like we developers do.
I may be missing the point but many of the items shouldn't be done on pre-lauch as indicated.
ex : HTML validation, it's not a good time to do it at this time, you can mess up the whole layout because of IE.
Custom 404 : a good page can be a big ammount of work...
Definitely a combination; depends largely on the structure of the organisation in charge of the website (e.g. whether or not they have access to dedicated testing).
It may be interesting to add another column to the list that allows individuals to take responsibility for each item, as there's definitely a range of skills required to tackle everything on here (from design to sys admin).
