Forum Moderators: open
To support my point… Would you buy or live in a house in which the foundation did not meet building codes? Of course not… it puts the contents of that residence at risk.
If the foundation of a website is weak, content is at risk. Accessibility and usability are limited and that could result in a loss of memberships, sales, and users.
I love it when people say: “Mac users only make up 5% of our customers, why should we design for them?” Can you imagine a 5 percent increase in users and or sales just by providing them access to a website!
This is almost not worthy of a discussion as validation should speak for itself. Someone (I think it was a gal named Chio? Here at WebmasterWorld) said: “It is a sign of a good programmer.” Those words echo in my mind with everything I do now… I am also working on some research regarding validation. I am sold on validation for months and is the core of my work ethic. I cringe at my old work – non-validated code! Blegh! Everything I do from here on out has been more productive and enjoyable for my clients, their site users, and my reduction of headaches.
So why is Validation shelved? It should play a big part in what we do… Not to mention saving our clients money in the long run.
While it is true that 20% of 97% is quite a lot, 20% of 100% is even more. Also, the fact that you *don't* validate your code might affect statistics - People surf in with [insert browser here], see that the page doesn't work with that browser and leave never to return again, or return with IE since your site only works with that. Ever thought of that?
Besides, validation is like documentation; It takes two weeks to make an entire site valid, but it takes five minutes extra (at most) to validate a single HTML document. Two weeks spent on validation and then five mins for each page after that will save you a bundle of redesign issues.
There are no excuses for not writing valid HTML docs.
But who is deciding on what is valid HTML. Netscape simply do not support many of the basics, especially in older versions (NS 7 isn't too bad).
Both NN4 and NN6 were full of problems.....you want us to bloat the code to overcome these "bugs".....not a chance....if NS want a market share they should make their product work, otherwise they will die...and we will take great pleasure in killing them!
It is not for webmasters to "work around" bugs in minority browsers, it is for the browser suppliers to make their products work.
I have no idea how much load that would put on the servers or how hard that would be to include in the algo. It was just a thought.
Check www.w3.org - They set the "standards" on the web.
>Netscape simply do not support many of the basics, especially in older versions (NS 7 isn't too bad).
>Both NN4 and NN6 were full of problems.....you want us to bloat the code to overcome these "bugs".....not a chance....if NS want a market share they should make their product work, otherwise the will die...and we will take great pleasure in killing them!
You know, we are in agreement here. The purpose of writing valid code is to *avoid* browser specific hacks and code bloat as much as possible. In a perfect world, we could've just written valid code and it works in any version of any browser. Unfortunately, this is not possible due to bad implementation in browsers *cough IE6 cough NN4 cough cough*. I fully agree some browsers need to die a painful death, but until they do we're stuck.
>It is not for webmasters to "work around" bugs in minority browsers, it is for the browser suppliers to make their products work.
Well said, and I agree wholeheartedly. But "Works in the most popular browser" is not the same thing as valid code.
If only the search engines had the spider's check the validation of the code and then proceeded to give the sites that have valid code a better ranking than others.
I agree. Would make websites much more homogeneous, Webbrowsers would have to follow the trend, etc. Could someone please contact Google?
Reality starts here:
Netscape tried to say "our browser complies with the WC3" as a -feature-. In the users eye, sites didn't look right. Niche techie browsers, micro browsers, etc, all have a problem with the majority of the web because of this.
But they look great in IE.
What is the average user going to choose? IE!
The entire internet is not going to go back and validate their code. It is just NOT going to happen. I consider it a -feature- that IE can take a site that may have a few html errors and still render it correctly.
Example:
I consider it a feature that although my car isn't always on a perfectly paved road, it still manages to handle the imperfect road and get me where I want to go. I don't care that the road is bumpy if my car works on it. I even get a smooth ride, and never know I went over a rock.
So -YOU- can go buy a car that only rides on perfect roads, but the reality is that roads aren't perfect... YOUR driving experience is going to suck.
So suck it up obscure browser users, its going to be a bumpy ride, because the WC3 "all roads should be smooth" campaign isn't going to pave the entire internet.
[edited by: deft_spyder at 10:52 pm (utc) on May 14, 2003]
It would be nice if you got a 1 point increase in Google PR if your pages validated to a standard.
However, one post I disagree with is the valid HTML reduces code bloat. While this is true in some cases it's not in others. I've done it myself, added unneeded code by accident and the page validates only to come along later and say, "WTF!" Code optimization and validation are two different things but one helps the other.
Oaf357
It would be nice if you got a 1 point increase in Google PR if your pages validated to a standard.
I agree? I think in some aspects validated sites are sooner or later are going to position better. If you make your content easy to crawl only good things can come from it. Another thought? If Google values qualified content then why would it not place a value on Validation?
On the flipside I don't think search engines would place as much value on Validation. There are A LOT of things Google (or any engine) would have to consider before giving some sort of priority to sites that validate. Would be nice to hear what GoogleGuy thinks about this?
I think asking or even hoping for a bump up on PR just for validation is a long shot!
I think asking or even hoping for a bump up on PR just for validation is a long shot!
I sure hope not. It would truly improve the web and force browser developers to make browsers that adhere to standards. Eventually, it would have to go because every web site and its brother would validate.
Also, the thing that kills me about validation is &. That just sucks.
However there are a lot of content rich sites published by Doctors, Lawyers and such... which content is valuable. These folks just don't get any of this Validation / Optimization... so should they be valued any less?
I'm curious though it there are ANY valid HTML only search engines or web directories.
Putting on flame-proof suite now
Reasons not to validate:
========================
1. Its not a substitute for testing
-----------------------------------
I'm all for code which is free of syntax or symantic errors, and validating removes syntax errors in html and css. But that doesn't mean your site will work properly cross-browser. Sometimes perfectly valid html and css produces poor results in some browsers; even relatively modern browsers which claim to comply with standards, such as Opera V6. Also, there are many sites out there with perfectly valid html and css, but with javascript errors all over the place.
2. Valid code does not imply accessibility
------------------------------------------
The extreme example of this is sites which have prefectly valid html with embedded flash. If you think that is cheating, and this thread is only about html, then other examples are tables, frames, iframes, images used for navigation buttons with unhelpful alt tags, etc. Validation is about syntax only; accesibility is about symantics, content, layout, etc. Quit arguing that validation implies accessibility; they are orthogonal issues. (And yet my arguments below address both because previous posts interelated the two issues.)
3. Web development is a 'marketing' discipline
----------------------------------------------
Website development is a wonderful mix of Technology, Graphic Design, and Business Strategy/Marketing (among other disciplines). Now the basics of Marketing is:
4. Technology evolves
---------------------
Browser developers have traditionally led the development of the standards by pushing the envelope. Standard bodies are less nimble, and have taken longer to ratify new standards. That is how it should be.. Deciding on whether some feature is good or not, and should or should not be included in the standard, is not a purely intellectual exercise. So experimentation with proprietary features is like a 'testing ground' to allow the standard bodies to decide whether to include or exclude new tags into the standard. I'm not talking about syntax errors or unclean code; I am thinking of things like IE's coloured scroll bars or the marquee tag. As an example, see [webmasterworld.com...] .
5. We're not talking Model-T Ford
---------------------------------
As technology advances in different platforms such as PDAs, we will reach a point where it won't be possible to design 'one-size-fits-all'. There will always be sites which are applicable to all people, but there will also be those specifically targeted to different platforms. Sites which cater for the blind will be optimised for the blind. Other sites might be optimised for PDAs. We'll find html tags or css attributes which are specific to one platform or one medium as apposed to another. We already have such css attribs for print vs aural vs visual vs... So the argument that valid code should work properly on any browser will become meaningless.
Shawn
flame-proof suite now off
1. Its not a substitute for testing
-----------------------------------
I'm all for code which is free of syntax or symantic errors, and validating removes syntax errors in html and css. But that doesn't mean your site will work properly cross-browser. Sometimes perfectly valid html and css produces poor results in some browsers; even relatively modern browsers which claim to comply with standards, such as Opera V6. Also, there are many sites out there with perfectly valid html and css, but with javascript errors all over the place.
Yes. Validation isn't all that it's cracked up to be right now; But this depends, more than anything else, on the fact that the standards have only been there for a few years. As the web evolves, following the standards will probably be more and more important.
2. Valid code does not imply accessibility
------------------------------------------
The extreme example of this is sites which have prefectly valid html with embedded flash. If you think that is cheating, and this thread is only about html, then other examples are tables, frames, iframes, images used for navigation buttons with unhelpful alt tags, etc. Validation is about syntax only; accesibility is about symantics, content, layout, etc. Quit arguing that validation implies accessibility; they are orthogonal issues. (And yet my arguments below address both because previous posts interelated the two issues.)
Validation is not equal to Accessibility, but validation *is* a part of making an accessible website. Validation is not enough, sure. But it is enough *for now*.
3. Web development is a 'marketing' discipline
Yes, that is true; But in that case it's the *CSS* that's supposed to be the tool to achieve specification - not the HTML.
4. Technology evolves
---------------------
Browser developers have traditionally led the development of the standards by pushing the envelope. Standard bodies are less nimble, and have taken longer to ratify new standards. That is how it should be.. Deciding on whether some feature is good or not, and should or should not be included in the standard, is not a purely intellectual exercise. So experimentation with proprietary features is like a 'testing ground' to allow the standard bodies to decide whether to include or exclude new tags into the standard. I'm not talking about syntax errors or unclean code; I am thinking of things like IE's coloured scroll bars or the marquee tag. As an example, see [webmasterworld.com...] .
Agreed, that is how it should be. But (again), you're missing something; HTML is a dead language. XHTML (it's successor) is extensible and allows you to define your own tags in your own DTD, like any other XML application. So "Browser specific tags" will in fact be valid markup, as long as you have defined it in the DTD (I might be wrong on this, but that's the way I have gotten it explained to me).
5. We're not talking Model-T Ford
---------------------------------
As technology advances in different platforms such as PDAs, we will reach a point where it won't be possible to design 'one-size-fits-all'. There will always be sites which are applicable to all people, but there will also be those specifically targeted to different platforms. Sites which cater for the blind will be optimised for the blind. Other sites might be optimised for PDAs. We'll find html tags or css attributes which are specific to one platform or one medium as apposed to another. We already have such css attribs for print vs aural vs visual vs... So the argument that valid code should work properly on any browser will become meaningless.
Not quite, since HTML is supposed to cover the content (and only the content). So that you can link in different stylesheets to the same HTML document. So that you can serve platform-specific code.
Validation is an important and necessary component of any serious testing.
2. Valid code does not imply accessibility
But accessability implies valid code.
3. Web development is a 'marketing' discipline
Web development is a 'presentation' discipline. Whether that presentation serves marketing purposes or not is up to whoever uses it.
4. Technology evolves
And valid code will make that evolution as painless as possible for everybody, for the reasons outlined below.
5. We're not talking Model-T Ford
As technology advances in different platforms such as PDAs, we will reach a point where it won't be possible to design 'one-size-fits-all'.
This is the reason why you can validate against the standard of your choice.
If you prefer the Model-T, validate against HTML 3.2 or even 2.0.
If you prefer some fancy concept car, the drafts of XHTML 2 are already out there for you to play with.
Most people here already know my views, so I'm not going to type some long diatribe just repeating stuff that I have said many times before.
I am on the ayes side.
OK, I just spent 10 hours tweaking all the html on my site to make W3C Validation happy. Now, since someone else doesn’t pay me, the 10 hours came out of my pocket. And believe me there were other things I should have been doing like adding real content or building links, etc. Here is what it found. This code has never been validated and has been online for 3 years. At one time I was on the 1st page of every SE for my KW’s. (long story why it is not on every one now) There is some validity to ShawnR’s devil's advocate argument. As a matter of fact, based on the responce I know I will get from this post, I should have spent this time adding real content or building links, etc. and I’m almost afraid to post my opinion. :-)
Every page with Javascript, didn’t have a type. But I haven’t seen any browser come to my site that would be purchasing my Windows software have a problem with it. I changed it any way. So that added to the size of the pages and I’m not sure for what since all the WEB sites that I have seen that have Javascript examples on them never use the type attribute anyway.
It said that I was missing a </p> on one page, but the </p> was there. Don’t laugh, but FP had put the WEBBot crap in between the <p> and the </p> and W3C didn’t see it. I removed the WEBBot crap and the error went away.
All the rest was IE tags that I put in after I designed the pages and they look OK. I put in BORDERCOLOR, BORDERCOLORDARK, BORDERCOLORLIGHT and <hr color="#9A3218"> so that it would look better for the literally 97% of the visitors that use IE and since these ppl run Windows, they may actually purchase my software.
As far as PR with validation, how can a SE give you better or worse anything based on using attributes of any specific browser that don’t validate, and how would they gauge it? It would cost more in programming, maintenance, etc. for them than it is worth. Especially since there are a lot bigger problems for them to deal with. If your html is so bad they can’t read it, you need a lot more than validation.
So I now had a little larger html files and use a little more bandwidth and spent hours doing it for probably zero dollar return on the investment. Or at least not the return I could have gotten doing the things I should have been doing. One could not stay in business very long if everything one did had zero dollar return on the investment.
Should I validate all new html? No doubt, but to go back and validate code that has been on line for years is a waste of $$$. Not to mention, I can tell after that length of time if something doesn’t work. If all NN users only went to 1 page, that would be a red flag.
Do the 97% of the visitors running IE care or even look to see if I validated my html, I doubt it. So they wouldn’t know or care how professional it is or isn’t anyway. I haven’t had to validate html for years, not because I’m good, but because I’ve done it for 10 years and I keep it simple, so the probability of an error is reduced. But I have been trained by a Fortune 25 company to keep it simple just for that reason. I also don’t double-check the number of scoops of coffee I put into my Mr. Coffee for the same reason.
As far as testing, you can’t test quality into anything. I can provide a 100 references to that. It is based on concepts developed by Motorola and adopted by GE, Honeywell, Dupont, and the list goes on. Quality must be designed into anything you build. A simple design that works means better quality, it’s a numbers game. Fewer lines of html means less chance of an error. So like a lot of things in life, perhaps it depends most on ones philosophy.
Now, I’ll runaway as fast asI can!
Here's you suite back ShawnR
The best thing would be if the browsers simply would refuse to render a page if it isn't standards compliant... Like they do with XML pages.
Nice thought, but not practical unless you want your market share to disappear to the browser that isn't so fussy.
Most of the web doesn't validate*, so it is in the browsers' interests to be as forgiving as possible.
Remember Joe public has never heard of HTML, and if a page doesn't display he would blame it on the browser, not the page author.
*sweeping generalisation
>>>"...This is the reason why you can validate against the standard of your choice..."
hehehe. That's what I love about standards... So many to choose from! hehehe ;)
>>>"...XHTML ... allows you to define your own tags in your own DTD ... So "Browser specific tags" will in fact be valid markup..."
Hehehe ... So many standards to choose from, and if you don't find one you like, you (or your browser vendor) can write your own. hehehe ;)
Validation is not equal to Accessibility, but validation *is* a part of making an accessible website. Validation is not enough, sure. But it is enough *for now*.
But accessability implies valid code.
I'm all for structured markup and pages working for everyone. But the two statements above are misleading IMHO.
Validation tells you *nothing* about accessibility. Take the extreme case where image links have alt tags with the filenames. This would validate but not be accessible.
Conversely, as most visually impaired people use Jaws with IE, as long as a page renders then it will be read by IE - whether it's valid or not.
By all means validate your code. But then go through and check the accessibility. Un-valid code can be just as accessible/inaccessible as valid code.
Accessibility is not a syntax issue.
Accessibility is not a syntax issue.
While I agree with you completely, I still think that valid code is the first step towards making an accessible Web site.
If you want a visually impaired to be able to read a note, there's no excuse for using sloppy handwriting. Sure, that's not the only thing that matters, but sloppy handwriting can make the message illegible, even if you do everything else possible (monstrous size, etc.)
If the code is valid, then it is more likely to be rendered correctly. Sure, you must then add other things to make it accessible. One cannot exist without the other. Sloppy coding, and sloppy planning both make inaccessible Web pages.
However, I think I need to add something else. Accessiblity does not mean "make sure visually impaired people can use your page". That's what most posts lean towards. But that's not what W3C says.
Accessibility means that everyone can use your page. They don't have to have disabilities to have special needs. Take PDA users, for example. Your page should be accessible to them as well. (Most likely they have very good eye sight.)
What about those that use cell phones to surf the net? What about those that user certain funky browsers?
Once you start to include all the ifs and buts, valid code becomes more and more important. Valid code is a must if you want to ensure that everyone has the same chance of getting a properly rendered page.
Once your code is valid, you can start tweaking it to make sure it is otherwise usable... and that list is long.
Valid code is a must if you want to ensure that everyone has the same chance of getting a properly rendered page.
Testing and quirks knowledge are a must if you want to ensure everyone can see the page. NN4 can crash or render divs on top of each other using valid code.
Similiarly, a site that hides advanced css style using @import will validate the same as a site that doesn't hide advanced css. You can't tell from validation whether it will work in older browsers or not.
You're right to mention accessibility is more than just people with visual impairments - could be folks with motor skill impairments, learning difficulties etc. But none of the techniques used to address accessiblity issues require valid code.
Other platfoms like PDAs is another issue. But remember new devices like the Danger Hiptop do not support w3c standards.
Validation does not mean a page is browser compatible, accessible or useable. It means the page uses w3c-valid html. Nothing more.
Testing and quirks knowledge are a must if you want to ensure everyone can see the page.
Sure, but I'm not going to buy several more computers just so I can install every dumb browser there is! I write valid code, test in the most commonly used browsers... the rest is up to the people who create the software. If a page doesn't render correctly because of a software bug, you can hardly blame it on me. But if I use various tricks and hacks in an attempt to compensate for a certain browser (and thereby possibly causing the code to become invalid) I am most likely creating a new problem in a different browser.
Plus, it is important to make a difference between valid code and working CSS.
Valid code implies no CSS whatsoever! And, I don't know of a browser that can't handle rendering valid code in a way that at least makes the page usable. I do, however, know several browsers (in fact, most of them) that will have issues with rendering certain elements if the code does not conform to current standards.
There is no excuse whatsoever for writing invalid HTML code. It's like trying to find an excuse to use sloppy grammar as an author.
There is no excuse whatsoever for writing invalid HTML code.
How about time spent with no return on it? When time, and time is money, comes out of you pocket, perhaps you views shift slightly?
It's like trying to find an excuse to use sloppy grammar as an author.
I’m not convinced that is a good comparison. There are a lot more people and words in the world than browser and html attributes. :-)
I agree that the code should be valid. It's a question for me of how valid or what is valid and by who’s standard.
Don't PDA's need some kind of an extension installed on the server?
How about time spent with no return on it?
Well, how about doing it right from the beginning? ;) I understand the point... but that's only true till you learn how to write valid code. Then you realize it actually takes less time, a lot less, to write valid code.
It's a question for me of how valid or what is valid and by who’s standard.
Either it's valid, or it's not ;)
And, it should be W3C's standard. After all, they have the right to set the standard...
I assume this includes CSS? Well, without wishing to labour the point, a wise man wrote this:
[webmasterworld.com...]
hehehe. I love it when the cognitive dissonance sets in. ;)
Basically HTML is like any other programming language except browsers are veeery tolerant with incorrect code. Voluntarily meeting the w3c standards will lead websites into a cleaner HTML future.
How about time spent with no return on it? When time, and time is money, comes out of you pocket, perhaps you views shift slightly?
From my expierence, programming any code in any language is easier, less time-intensive and cheaper when meeting standards.
Imagine there was only one specification for vehicles. Doesn't matter if your customers want to buy a push-bike, motorcycle, soft-top, bus, truck or train. You have to make a car, and it must meet the specs for a car. The issue is not one of solid and correct error-free coding.
