Forum Moderators: open
There seems to have been a large upswing over the last 12mts in the popularity of validating ones pages against the W3C [w3c.org] (X)HTML and CSS standards. I view this as a positive thing for the web as I care deeply about accessibility which goes hand in hand with validating markup and paying attention to detail that such a regime imposes on page design.
Contrary to popular beleif though, many of my sites don't validate. And I really couldn't care less.
Let me explain:
Using a validator for your markup and styles is in my view essential when building pages. There are numerous benefits not least of which is that for cross-browser compatibility the task is made so much simpler if you follow the standards and then tweak pages as opposed to the reverse.
Pages do not however have to validate in order to provide the designer and user with all of the associated benefits. For those that program dynamic sites such as forums, datafeeds, interactive blogs and who knows what else, somtimes true, every page validation is just not realistic. I'm not saying impossible, just not realistic.
By the time you've got that dynamic content into your well designed and validated template, all kinds of things can start that validator spitting out errors and warnings left right and center.
Providing they're not enourmous, it just isn't an issue. If a page is accessible, adheres to good design and color principles and is easy and intuitive for people to use then it really doesn't matter what the W3C think does it?
Let's not let validation rule us, it's a tool like anything else and a damn good one too but it's not everything is it?
Nick
When building pages, I think it's important to make them validate. But, when the page gets ready for release - why not make it validate still? I have yet to encounter an example where I could find an excuse not to validate.
Is the page going to look any different if it doesn't validate this last step? No. Is it going to be less accessible? No. Will it affect its performance? No.
So why worry? The answer is plain and simple: pride! I take pride in my work, and I make sure it validates. That way, if you don't like my site, we're left with nothing but an argument based on opinions. "Oh, but I don't like that color!" But no one will have anything of worth to hold against me... :)
That's a very difficult thing to do, and very hard to pitch to clients (unless you take the line: "we deliberately insert bugs into your web pages; trust us it doesn't matter").
If I were such a client, I'd want financial indemnities against the day (or browser or search engine) when it does matter; plus a complete list of inserted bugs and the rationale for each. I'd be crazy as a client to expect anything less.
Life is so much simpler with valid code (not that valid code alone will win the day, of course).
My point really is that there comes a time where one must way up the benefit/pride factor against the time it takes to satisfy that and and getting the thing live...
Nick
Just to counter those arguments, what exactly do you gain from not using &, or not closing list items, etc?
Personally, the only thing I can think of is a couple bytes... And hey, if it's worth it to you - then that's fine. Personally, (and again, these are just my own personal thoughts) I don't think it's worth it.
hard to stop users inputing badly formatted stuff etc etc
Amen to that! But that's a completely different story. Anyone who would go through the trouble of validating your page would also be able to tell the difference between user input and deliberate development. As far as user input - that's a valid excuse. But if you do it yourself, and this on purpose, I don't think it's waterproof.
Then again, it also depends on how much freedom you give your users.
In a perfect world our dear Brett would validate each post to the forum before letting it go live, prompting us to make changes if it doesn't validate ;)
ust to counter those arguments, what exactly do you gain from not using &, or not closing list items, etc?
Nothing. My point is that depending on what you are using to build content, be that user input, datafeeds or web service generated xml. somtimes the time it would take and effort you'd have to expend in finding and regexing or worse, the kind of 3/4 pass functions to sort such data would be best spent doing other more productive things.
With me?
Nick
To answer your question about what we would gain... weeks or development work. Not every page is written from scratch or taken straight fro ma template ;)
SN
An example:
If you have an html form with hidden input fields <input type="hidden" name="somename" value="somevalue"> and you try and validate your page in html 4.01 strict, your page will not validate if the hidden form fields are not wrapped in a block level element.
document type does not allow element "INPUT" here; missing one of "P", "H1", "H2", "H3", "H4", "H5", "H6", "PRE", "DIV", "ADDRESS" start-tag
Maybe I dont understand the w3c's reasoning on this but it seems kind of dumb that an element that is never rendered on the page must be wrapped in a block level element. Am I missing something there?
That's a very difficult thing to do, and very hard to pitch to clients
Wow, you have clients who understand these issues and care about them? My clients would only recognize the W3C validator if you put it in a Gator pop-up page and force fed them every ten minutes for a month.
I'm building a store right now that extracts a LOT of data for each product from a database -- seven very maxed out memo fields, to be exact. There are five data input people, often using copy/paste, and there's no way I can eliminate & or " without a major campaign that would slow development to a crawl.
All I have been able to do is insist that Word documents be converted to plain text before the copy/paste so that the more bizarre extended characters, such as smart quotes, don't get into the data.
I never before allowed & or " on a final HTML page, but there are ofter pragmatic concerns in business that over-rule my purist tendencies.
Using a validator for your markup and styles is in my view essential when building pages. There are numerous benefits not least of which is that for cross-browser compatibility the task is made so much simpler if you follow the standards and then tweak pages as opposed to the reverse.
Definitely agree with this it's the single most useful tool to use before you go around complaining about browser bugs ;)
I do care because of the pride thing.. when I built my own user input area I was able to create a parse/replace script for all known(afaik that is) character issues into it, &, "e,etc.. (Tedster...I used chr(#) to replace codes, which is better at catching those smart quotes). So again agreed it's not impossible, just not always practical especially on larger sites.
However re:
# Unclosed list items
Still it's better that we are at least aware of it now because I wouldn't like for clients to catch up and I don't know about it ...
Suzy.
My previous background as an AS/400 programmer required lots of testing and validation and retesting before a program went live, but that was not HTML. I coded a few pages for my poetry and such back in those days. That wee bit of HTML experience managed to put me in the drivers seat for maintaining the sites I have today - 2 of them. I inherited them, if you will, from someone who apparently thought little of validation, or even regular maintenance.
Hence, the 60 or so pages I maintain today will not validate, period. My experience level with HTML almost forces me to continue to add new pages that won't validate, or that require Javascript to function properly.
Meanwhile I have a goal, without a definite timeline, to get every one of those pages to validate. The site is a good retail site, looks sharp - at least with MSIE. We're pretty small, not much of a budget, few tools, and I have no idea if Opera or Netscape users can even read my pages. It's a scary thought.
I have managed to pull off a few good things over the last month or so: improved our SE visibility, increased our sales thru targeted marketing. So with any luck we might actually be able to afford some decent tools to get those pages up to snuff and keep them that way.
- & instead of & in urls
- " instead of "
Interesting! Tidy compalins bitterly about & but is happy to accept " in 4.01 strict.
Well, I decided to go to W3C and try to see for myself. Closest I can get to it is in Section 5.3.2 [w3.org] which contains the following:
Authors should use "&" (ASCII decimal 38) instead of "&" to avoid confusion with the beginning of a character reference (entity reference open delimiter). Authors should also use "&" in attribute values since character references are allowed within CDATA attribute values.Some authors use the character entity reference """ to encode instances of the double quote mark (") since that character may be used to delimit attribute values.
Sure looks as if " is, in fact, legal.
Nick
Wow, you have clients who understand these issues and care about them?
It's a almost a USP in the marketing, and can add a barrier to others who may be pitching to the same client.
All I have been able to do is insist that Word documents be converted to plain text before the copy/paste so that the more bizarre extended characters, such as smart quotes, don't get into the data.
Tell me about it! We have the same problem. Most smart quotes and extended characters are easily converted to their plain-old equivalents. But you got to spot them all, and there always seem to be new ones.
It is something we have seen more and more from our larger Clients they want to validate.
DaveN
Now about that macintosh thing --
how do we move the mac IE user over
to Safari? It's worse than the old
NN4 issue these days.
...how do we move the mac IE user over to Safari?
Safari is slowly increasing for the site in my sig - passed Firebird, Konqueror, and Galeon this month.
Ho-hum, amen. I'm with you, and I'm tired. My personal pages validate to XHTML Strict. The site I did at work... No, it doesn't validate, but it works, and it works in Mac IE too, not that that matters because nobody looks at it from anything but IE 5 and 6.
So, pragmatism wins out, but if it's a site with my name on it that I'm using to present my personal or professional face to the world, and thus I have control over it, it's going to validate. At work, I don't have the kind of control over the project to go back and validate it. I can barely keep up with it as it is.
So, pride where possible, pragmatism where necessary.
Go Safari! I've opened IE on my iMac twice since I bought it in June, and just as quickly closed it again. Brr.
I have yet to encounter an example where I could find an excuse not to validate.
I use scripts from programmers that write data to the page 'on the fly'. Most of the time their code doesnt validate (not everyone is that deeply into validation). I can't change it because its not actually on the page, and Im not a good enough programmer to alter all those scripts. The pages look and work fine of course, even on picky macs.
--Kenn (looking for an excuse not to validate)
