I have a web site that, due to maintenance by several people, some of whom are
fairly clueless about HTML and CSS, etc. (notably me), has gotten to the point
where I'm pretty sure it's suffering from bit rot. Though the pages seem to
display okay under IE and FF, I really think it's time for an under-the-hood
cleaning. I recently received a copy of Molly Holzschlag's "Spring Into HTML
and CSS," and in the first chapter, she makes a big deal of producing pages
that validate cleanly. However, she doesn't explain why this is important,
e.g., doesn't say what the consequences of validation failure are.

I went to http://validator.w3.org/ and was unsurprised to see my home page
fail to validate. But then I got to playing around, and I found that the home
pages for none of the following validate, either: yahoo, ebay, google, artima,
and cnn. This makes me wonder whether validation is really something I need
to worry about. Morally, I'm all for standards, and given a choice between
pages that validate and those that do not, I'd choose validation, but I'm
going to have to find somebody else to do the work for me (somebody who DOES
know about HTML and CSS, etc.), and I'm worried that finding somebody who is
familiar with validation is going to be a lot harder and/or more expensive
than finding somebody who is not.

Can somebody please explain to me what the practical advantages of having
pages validate are? Also, I'm open to suggestions on who to consider hiring
to do the work at my site (which happens to be aristeia.com).

Thanks,

Scott

Gazing into my crystal ball I observed Scott Meyers <Usenet@aristeia.com>
writing in news:MPG.1d67e1728e7f9c8b9897f2@news.hevanet.com:
[color=blue]
> Can somebody please explain to me what the practical advantages of
> having pages validate are?[/color]

In the old days, before browsers did so much error correction, writing
valid code was important, because browsers would not render invalid
markup. For example, a missing </td> would make Netscape give a blank
page.

Now browsers do a lot of error correction, especially IE. Maybe one of
the reasons IE is so behind all the others is because there was so much
put in to do error correction. However, some browsers, if served
application text/xhtml+xml and the markup is not well formed, will
partially display with an error message.

For me it is a tool to discover why something is not rendering the way I
think it should. It is also a matter of pride, everything I produce is
valid. That might be because on new documents, I start with a strict
DOCType, and no presentational markup.

With that said, I have found that using valid, sematically correct,
presentationalless markup has made me and my clients get very good SERPs,
without resorting to any trickery.... <Mafia music>and now that I have
told you my secret, I'm going to have to kill you. ;-)</music>

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Scott Meyers wrote:[color=blue]
> I recently received a copy of Molly Holzschlag's "Spring Into HTML
> and CSS," and in the first chapter, she makes a big deal of producing
> pages that validate cleanly. However, she doesn't explain why this
> is important, e.g., doesn't say what the consequences of validation
> failure are.[/color]

Error correction. If your documents validate, the onus is on the browser
to do the right thing. If they don't, then they'll guess at what you
meant. How well they'll guess is, erm, anyone's guess. :-D (Apologies
for the corny joke.)
[color=blue]
> then I got to playing around, and I found that the home pages for
> none of the following validate, either: yahoo, ebay, google, artima,
> and cnn.[/color]

Most pages don't. In the case of Yahoo, CNN, et. al., they likely have
substantial budgets for coders and testing. Do you?
[color=blue]
> This makes me wonder whether validation is really something I need to
> worry about.[/color]

It is if you want durable www documents.
[color=blue]
> Morally, I'm all for standards,[/color]

Morals have nothing to do with it. Practically, validation is a useful tool.

http://www.cs.tut.fi/~jkorpela/html/validation.html
[color=blue]
> Can somebody please explain to me what the practical advantages of
> having pages validate are?[/color]

I already did. Perhaps I could encourage you to consider the advantages
of googling the group archives? ;-)

--
Brian

On Sat, 13 Aug 2005 11:59:44 -0700, Scott Meyers <Usenet@aristeia.com> wrote:
[color=blue]
> I recently received a copy of Molly Holzschlag's "Spring Into HTML
> and CSS," and in the first chapter, she makes a big deal of producing pages
> that validate cleanly. However, she doesn't explain why this is important,
> e.g., doesn't say what the consequences of validation failure are.
>
> I went to http://validator.w3.org/ and was unsurprised to see my home page
> fail to validate.
> <http://aristeia.com/>[/color]
[color=blue]
> Can somebody please explain to me what the practical advantages of having
> pages validate are?[/color]

Practical advantages of creating valid pages are, to me:
- all those who work on the pages work with the same standards and can take over
from each other with ease (assuming they are up to working with standards, that
is :-) );
- one knows for sure it is not an error in the code that is the cause of that
unwanted <*$+@@ &££@!!> rendering effect :-) ;
- years from now you as the author will still understand what you did when you
read back the code;
- I'm pretty sure valid code is a better garantee of getting your content across
the world wide web with its wide variaty of browsers (like text- and aural
browsers or screen readers, besides the more usual graphical ones), then is
invalid code, although to be really sure, one should also provide valid code
that is logical, has some semantics to it;
- I expect that valid code will not only work in the browsers of the present,
but will still work fine in browsers to come.



--
,-- --<--@ -- PretLetters: 'woest wyf', met vele interesses: ----------.
| weblog | http://home.wanadoo.nl/b.de.zoete/_private/weblog.html |
| webontwerp | http://home.wanadoo.nl/b.de.zoete/html/webontwerp.html |
|zweefvliegen | http://home.wanadoo.nl/b.de.zoete/html/vliegen.html |
`-------------------------------------------------- --<--@ ------------'

On Sat, 13 Aug 2005 20:02:22 GMT, Adrienne <arbpen2003@sbcglobal.net> wrote:
[color=blue]
> With that said, I have found that using valid, sematically correct,
> presentationalless markup has made me and my clients get very good SERPs,
> without resorting to any trickery....[/color]

Ah, yes. That too of course.
[color=blue]
> <Mafia music>and now that I have
> told you my secret, I'm going to have to kill you. ;-)</music>
>[/color]

lol

--
,-- --<--@ -- PretLetters: 'woest wyf', met vele interesses: ----------.
| weblog | http://home.wanadoo.nl/b.de.zoete/_private/weblog.html |
| webontwerp | http://home.wanadoo.nl/b.de.zoete/html/webontwerp.html |
|zweefvliegen | http://home.wanadoo.nl/b.de.zoete/html/vliegen.html |
`-------------------------------------------------- --<--@ ------------'

Scott Meyers <Usenet@aristeia.com> wrote:
[color=blue]
>Can somebody please explain to me what the practical advantages of having
>pages validate are?[/color]

How long is a bit of string?
[color=blue]
>aristeia.com[/color]

It's funny that you are a C++ specialist, normally programmers are
sticklers for correct syntax.

There are more pressing issues than validation that should be solved
first, such as:

1) If you specify one colour you need to specify them all. Currently my
default link colour is used, but legibility is very poor against the
green of the navigation section of your site.
2) Your frames cause problems, users cannot bookmark specific views,
search engine indexing is poor, orphaned pages (pages without a nav
section) to name a few.
3) Your documents contain very little if any structure, you should use
headings.
4) Some of your links attempt to open a new window/tab, this is really
bad form since it forces your preferences onto people who do *not* want
new windows/tabs to be opened.

--
Spartanicus

On Sat, 13 Aug 2005 20:02:22 GMT, Adrienne <arbpen2003@sbcglobal.net>
wrote:

[...]
[color=blue]
>In the old days, before browsers did so much error correction, writing
>valid code was important, because browsers would not render invalid
>markup. For example, a missing </td> would make Netscape give a blank
>page.
>[/color]

Validation wouldn't have helped in that case anyway, since the closing
</td> is optional ;-)

Nick

--
Nick Theodorakis
nick_theodorakis@hotmail.com
contact form:
http://theodorakis.net/contact.html

On Sat, 13 Aug 2005 11:59:44 -0700, Scott Meyers <Usenet@aristeia.com>
wrote:
[color=blue]
>Can somebody please explain to me what the practical advantages of having
>pages validate are?[/color]

Simplicity. "Valid" is a simple and objective status. "Invalid" may or
may not work - there is (very much so!) invalidity and invalidity. An
empty <div> will cause Tidy to whine, the _presence_ (yes, presence!) of
a title attribute will cause Dreamweaver to complain. You can have HTML
documents that have minor invalidities no browser will really fall over,
or they might be major things (like an unclosed <table>) that really do
blow things out of the water. Unless you're obsessive about keeping up
to date on browser foibles, it's impossible to really know how bad an
invalidity's effects will be.

But if you're valid, you're valid. No arguments about it (except of
course on Usenet)

On Sat, 13 Aug 2005 20:15:37 GMT, Brian wrote:[color=blue][color=green]
> > then I got to playing around, and I found that the home pages for
> > none of the following validate, either: yahoo, ebay, google, artima,
> > and cnn.[/color]
>
> Most pages don't. In the case of Yahoo, CNN, et. al., they likely have
> substantial budgets for coders and testing. Do you?[/color]

I'm not sure I understand this comment. Given their budget for coders and
testers, I'd expect that they'd produce valid pages if validity were something
they found to be useful. This suggests that they do not find validity to be
something that carries its weight. However, I don't think you meant that.
Can you please clarify?

Scott

On Sat, 13 Aug 2005 22:18:50 +0200, Barbara de Zoete wrote:[color=blue]
> Practical advantages of creating valid pages are, to me:
> - all those who work on the pages work with the same standards and can take over
> from each other with ease (assuming they are up to working with standards, that
> is :-) );[/color]

Do you have any sense for how common such knowledge is? My original
motivation for asking this question was that in my initial contact with a
prospective web site maintainer, I mentioned that one of the things I wanted
to do was upgrade my pages to the point where they validate, and her reply was
"I have reviewed your site and the source code. I see nothing wrong with your
source code at the moment, other than the frames." Given the context of the
exchange between us, I think this comment reflects her lack of familiarity
with validation rather than a judgement about whether validation is useful.
Hence my interest in whether validation is important enough for me to insist
on finding somebody who is familiar with it.

Scott

On Sat, 13 Aug 2005 20:22:00 GMT, Spartanicus wrote:[color=blue]
> It's funny that you are a C++ specialist, normally programmers are
> sticklers for correct syntax.[/color]

Hence my moral support for standards :-) However, there is a lot of C++ code
that is written that deliberately does not obey standards;
standards-compliance is but one of a number of criteria that people take into
account when deciding how to approach a project. FWIW (nothing in this
newsgroup), I'd venture to guess that the vast majority of commerical C++
programs contain at least some technically invalid constructs. Virtually all
compilers accept them, so there's little incentive to fix them (or even to
avoid including them in future code). Given that so many big sites produce
pages that don't validate, it looks like there is a similar situation in
webpageville.
[color=blue]
> 1) If you specify one colour you need to specify them all. Currently my
> default link colour is used, but legibility is very poor against the
> green of the navigation section of your site.
> 2) Your frames cause problems, users cannot bookmark specific views,
> search engine indexing is poor, orphaned pages (pages without a nav
> section) to name a few.
> 3) Your documents contain very little if any structure, you should use
> headings.
> 4) Some of your links attempt to open a new window/tab, this is really
> bad form since it forces your preferences onto people who do *not* want
> new windows/tabs to be opened.[/color]

Thanks for your feedback. I appreciate it.

Some of the issues above are deliberate design decisions (e.g., relatively
little structure, opening new windows), some are not (e.g., color
specification, link legibility). Some of the deliberate decisions should
probably be reconsidered (e.g., opening new windows). As I said, the site has
just kind of evolved over the years, and it's time for somebody who knows what
they are doing to give it a tune-up.

As for frames, I hate them, too, but I don't know of any other way to make it
possible for the content area to scroll while the navigation area remains in
view. Then again, I'm a C++ weenie, not an HTML/CSS weenie. If there's
another way to achieve this effect, please tell me about it. I'm sure this is
well-trod ground in this newsgroup, so a link or likely set of search terms
would be fine.

Thanks,

Scott

Scott Meyers <Usenet@aristeia.com> wrote:
[color=blue]
> On Sat, 13 Aug 2005 20:15:37 GMT, Brian wrote:[color=green]
> >
> > In the case of Yahoo, CNN, et. al., they likely have
> > substantial budgets for coders and testing. Do you?[/color]
>
> I'm not sure I understand this comment. Given their budget for coders and
> testers, I'd expect that they'd produce valid pages if validity were something
> they found to be useful.[/color]

Right.
[color=blue]
> This suggests that they do not find validity to be
> something that carries its weight.[/color]

Well, more likely, that the net present value of paying a developer to
generate huge volumes of valid code isn't very high. Writing valid code
takes more skill and/or time than writing tag soup that generally works
alright. I imagine for most of these companies, "generally works
alright" is good enough, and they'd rather focus their efforts and
resources on compelling content, eye candy, and so on. After all, most
of their readers don't know or care if their pages are valid or not.

_But_, that doesn't change the fact that writing valid HTML and CSS is
future-proofing your pages. A large company may have the luxury -- if
and when they decide it's worth their while -- to devote a lot of
resources to an intense effort to clean up their HTML. A one- or
two-person operation generally does not have that luxury. So it makes
sense for a small operation to devote a bit of time upfront towards
writing good markup, because they odds of them having time and resources
to go back later to clean it up aren't good.

--
Joel.

On Sat, 13 Aug 2005, Scott Meyers wrote:
[color=blue]
> But then I got to playing around, and I found that the home pages
> for none of the following validate, either: yahoo, ebay, google,
> artima, and cnn. This makes me wonder whether validation is really
> something I need to worry about.[/color]

There are also plenty of commercial pages that don't work with
www-compatible browsers, but only with MSIE. Some of us have higher
standards.
[color=blue]
> Morally, I'm all for standards, and given a choice between pages
> that validate and those that do not, I'd choose validation, but I'm
> going to have to find somebody else to do the work for me (somebody
> who DOES know about HTML and CSS, etc.),[/color]

As I happens, I know how to do that by hand, but, if I didn't, I have
a computer to help me to generate output that would be guaranteed
valid. Of course, there's far more to producing a good web page than
merely valid syntax, but a web page with invalid syntax is no better
than literature with lots of wrongly-spelled words, AFAICS.

Quite why those popular sites consider it advantageous to extrude
syntactically invalid stuff, I can't tell you - but I see no advantage
it in myself.

You can also be assured that when you have a problem and ask for
advice here, the only advice you're likely to get (aside from being
advised to fix your syntax errors and try again) will be from the kind
of sloppy and coudn't-care-less commentator who is prepared to spend
their time fiddling with someone else's invalid syntax. That kind of
advice tends to be worth even less than you paid for it, to be frank.
[color=blue]
> to do the work at my site (which happens to be aristeia.com).[/color]
___
/
FRAME: buttons
FRAME: main_body

This web page uses frames, but your browser doesn't support them.

\___

That site uses frames, but your author doesn't support them.

Scott Meyers wrote:
[color=blue]
> As for frames, I hate them, too, but I don't know of any other way to make
> it possible for the content area to scroll while the navigation area
> remains in view.[/color]

So what if the navigation doesn't remain in view? Scrolling navigation works
for the vast majority of sites out here.


--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

On Sat, 13 Aug 2005 20:15:37 GMT, Brian
<usenet3@julietremblay.com.invalid> wrote:
[color=blue]
>Most pages don't. In the case of Yahoo, CNN, et. al., they likely have
>substantial budgets for coders and testing. Do you?[/color]

Why would you think that ? 8-) I'm dealing commercially with two of
these "blue chips" right this week and their technical knowledge
borders on the negligible. I dealt with them both a year ago (very
similar project) and they were no better then. Although there are people
with a clue somewhere inside the organisation, they're such big
organisations that this is thoroughly diluted by pointy hair.

I'd add that neither of these are Google or Amazon (although of similar
scale). I've always found every technical contact at either of those two
to be spot-on.

On Sun, 14 Aug 2005 00:55:08 +0100, David Dorward wrote:[color=blue]
> So what if the navigation doesn't remain in view? Scrolling navigation works
> for the vast majority of sites out here.[/color]

Yes, well, my experience has been that broken links work for the vast
majority of site out there, too, but I don't like them, either.

I happen to have a strong preference for navigational links that remain in
view, because the alternative doesn't make any sense to me. Scrolling
content doesn't change my navigational choices, so why should it change the
easy accessiblity of them? It seems to me that tying the scrolling of
navigational links to the scrolling of content -- two independent things --
is a usability concession made in the name of implementation
considerations. Not that this is necessarily an unjustifiable choice. I'm
frankly not knowledgable enough about the trade-offs to have a firm opinion
on the matter. What I do know is that I, myself, prefer navigational links
that remain in view when content scrolls, so I'm naturally inclined towards
implementation approaches that give me the behavior that I prefer. If
there are other implementation approaches to the same end, I'd love to know
about them. If there are drawbacks to frames that I am not aware of, I'd
like to know about those, too.

Spartanicus wrote:

Your frames cause problems, users cannot bookmark specific views, search
engine indexing is poor, orphaned pages (pages without a nav section) to
name a few.

I'm interpreting "your frames" as "frames in general" here. If there are
problems specific to my frames, again, I'd love to know about them. It's
my understanding that bookmarking pages at my site should work as users
expect, i.e., it should yield a bookmark that will reload the same frameset
with the same content inside. If it doesn't, something's broken, and I
need to have it fixed. I don't care about search engine indexing, and if I
interpret the comment about orphaned pages correctly, that's a site
management problem, not a usability problem. My understanding is that
using frames makes life more complicated for site designers, but if they
are careful, the usability experience of users (with browsers that support
frames) should not be degraded. If I'm mistaken here, please set me
straight.

One of the difficulties of this kind of thing is that I don't plan to do
the work myself, but as the guy writing the check for the work, I'll be
ultimately making the big decisions that will be implemented by whomever
does the actual coding. Which means that I have to educate myself on the
pros and cons of various approaches, especially because my first task is to
identify somebody who can do a good job for me. That, in turn, is
difficult, because I'll be interviewing people to determine their technical
skills in areas I don't myself understand.

Once I am working with somebody whose skills and judgement I respect, I can
lean on them for advice on the big decisions, but until then, I'm on my
own. Which is why I was originally trying to figure out how much weight I
should give to validation.

Scott

On Sun, 14 Aug 2005, Andy Dingley wrote:
[color=blue]
> Why would you think that ? 8-) I'm dealing commercially with two
> of these "blue chips" right this week and their technical knowledge
> borders on the negligible.[/color]

Point taken ...
[color=blue]
> I'd add that neither of these are Google or Amazon (although of
> similar scale). I've always found every technical contact at either
> of those two to be spot-on.[/color]

So can *you* explain why they put pages onto the web that don't seem
to pass even syntax validation? This is, after all, a frequently
asked question by those who would prefer not to bother themselves with
syntax validation of their own pages, and it would be good to have
some kind of definite explanation for it. As I said in an earlier
f'up, I really have no idea: your remark that "Although there are
people with a clue somewhere inside the organisation, they're such big
organisations that this is thoroughly diluted by pointy hair" is well
taken, but I don't find it a particularly convincing explanation of
why they do it.

For myself, I treat syntax checking (formal validation of HTML, and
checking of CSS) in the same way as spell-checking of textual content:
a quality assurance step that should not be omitted from anything
serious that I'm putting my name to in public. I think you're close
to the same in that respect, no?

best regards

On Sun, 14 Aug 2005 08:58:48 +0100, "Alan J. Flavell"
<flavell@ph.gla.ac.uk> wrote:
[color=blue]
>So can *you* explain why they put pages onto the web that don't seem
>to pass even syntax validation?[/color]

Cluelessness. In every large tech organisation I've ever worked in
(including I'm ashamed to say, HP) there have been some people who
understood things, some who didn't, and an entire layer of people on the
middle who devoted their working lives to having the wrong people make
the decisions. I'm a contractor - an expensive resource who is brought
in at great cost to advise on one specific area of expertise, then whose
recommendations are ignoredin favour of some BMW-driver suit, On _every_
site this happens, not just the odd one.

Until recently, validation was also very much the exception rather than
the rule. It's not that important an issue for HTML - compare it to any
programming language, where a syntax error stops things dead. Invalid
HTML still works, it just may not work as well as it should,

Cluelessness. To quote Scott the OP, 'her reply was
"I have reviewed your site and the source code. I see nothing wrong with
your source code at the moment, other than the frames."
Incidentally, that was a rare valid use for nested <blockquote>s 8-)

Web "designers" are largely untaught, or worse they've been through CIW.
Recruitment policies takes no account of technical skills, they just
play "match the buzzword" with application names like Dreamweaver.
Someone skilled with a code editor will be rejected in favour of a
trained monkey with FP or DW knowledge, because the recruitment agent
knows no more than to ask "Have you used DW?"

C00lness. An invalid dancing penguin always trumps a valid readable
site. How may "web design how-tos" have you seen called "Build the
C00lest website ever" ? What sort of coding style are these teaching?

[color=blue]
>I think you're close to the same in that respect, no?[/color]

Largely. I'll break validation sometimes if I know what I've broken and
I don't care. <a target="_zoomimageviewer" ... > has a useful
side-effect if I'm opening repeated pop-up windows for the same purpose
and I want to re-use the same window for it.

Brian wrote:[color=blue]
>
>Scott Meyers wrote:
>[color=green]
>> I recently received a copy of Molly Holzschlag's "Spring Into HTML
>> and CSS," and in the first chapter, she makes a big deal of producing
>> pages that validate cleanly. However, she doesn't explain why this
>> is important, e.g., doesn't say what the consequences of validation
>> failure are.[/color]
>
>Error correction. If your documents validate, the onus is on the browser
>to do the right thing. If they don't, then they'll guess at what you
>meant. How well they'll guess is, erm, anyone's guess. :-D (Apologies
>for the corny joke.)[/color]

....and you have to guess about how future browsers will guess... :)

On Sun, 14 Aug 2005 12:23:25 +0100, Andy Dingley sent:
[color=blue]
> Until recently, validation was also very much the exception rather than
> the rule. It's not that important an issue for HTML - compare it to any
> programming language, where a syntax error stops things dead. Invalid
> HTML still works, it just may not work as well as it should,[/color]

Though the *BIG* problem with that is that one person's testing of invalid
HTML only shows how well their browser handles it. I've encountered
numerous seriously broken pages that presumably worked for the original
author, but are utterly useless to other people.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

Scott Meyers wrote:
[color=blue]
> As for frames, I hate them, too, but I don't know of any other way to make it
> possible for the content area to scroll while the navigation area remains in
> view.[/color]

I'm constantly amazed (and dismayed) at the number of people who think
that having a (usually rather large) "navigation area" permanently
on-screen is a feature rather than a bug! Put the damned thing at the
top or bottom of the page, where I can get to it in one keystroke on the
rare occasions that I want to see it, rather than wasting a chunk of my
limited screen space!

Maybe all website designers have giant monitors on which they run a
browser full-screen, so they've got space to waste. I always have
multiple windows open, and never have enough screen real-estate
available -- so I get really pissed-off at the idiots who decide that
something which is rarely used is so important that I should be forced
to see it all the time.

If someone ever comes up with a tool which reliably and conveniently
recognizes and hides these abortions, I will be *so* glad...

Dave

Dave Anderson wrote:[color=blue]
>
>I'm constantly amazed (and dismayed) at the number of people who think
>that having a (usually rather large) "navigation area" permanently
>on-screen is a feature rather than a bug! Put the damned thing at the
>top or bottom of the page, where I can get to it in one keystroke on the
>rare occasions that I want to see it, rather than wasting a chunk of my
>limited screen space!
>
>Maybe all website designers have giant monitors on which they run a
>browser full-screen, so they've got space to waste. I always have
>multiple windows open, and never have enough screen real-estate
>available -- so I get really pissed-off at the idiots who decide that
>something which is rarely used is so important that I should be forced
>to see it all the time.
>
>If someone ever comes up with a tool which reliably and conveniently
>recognizes and hides these abortions, I will be *so* glad...[/color]

The Adblock third-part extension for Mozilla FireFox does a pretty
good job.

Scott Meyers wrote:[color=blue]
>
> I have a web site that, due to maintenance by several people, some of whom are
> fairly clueless about HTML and CSS, etc. (notably me), has gotten to the point
> where I'm pretty sure it's suffering from bit rot. Though the pages seem to
> display okay under IE and FF, I really think it's time for an under-the-hood
> cleaning. I recently received a copy of Molly Holzschlag's "Spring Into HTML
> and CSS," and in the first chapter, she makes a big deal of producing pages
> that validate cleanly. However, she doesn't explain why this is important,
> e.g., doesn't say what the consequences of validation failure are.
>
> I went to http://validator.w3.org/ and was unsurprised to see my home page
> fail to validate. But then I got to playing around, and I found that the home
> pages for none of the following validate, either: yahoo, ebay, google, artima,
> and cnn. This makes me wonder whether validation is really something I need
> to worry about. Morally, I'm all for standards, and given a choice between
> pages that validate and those that do not, I'd choose validation, but I'm
> going to have to find somebody else to do the work for me (somebody who DOES
> know about HTML and CSS, etc.), and I'm worried that finding somebody who is
> familiar with validation is going to be a lot harder and/or more expensive
> than finding somebody who is not.
>
> Can somebody please explain to me what the practical advantages of having
> pages validate are? Also, I'm open to suggestions on who to consider hiring
> to do the work at my site (which happens to be aristeia.com).[/color]

According to one estimate, Internet Explorer (IE) reached a peak
market share of 88.0% of all browsers in March 2003. Since then,
it has declined to 73.5%. Other estimates might show IE still well
above 80% or even 90% of the market, but they all seem to agree
that IE's share is declining. My own sampling in April of this
year showed IE was the browser in 81% of the hits on 13 of my
eclectic Web pages. That means almost 20% of those who visited my
Web site were NOT using IE.

The point of all this is that you should design your Web pages for
viewing by ANY browser. To do that, you should design to the HTML
and CSS specifications and not to any specific browser at all. If
"It looks okay with IE" is your criterion, however, you have tied
yourself to a fading star.

Please see my
<URL:http://www.rossde.com/internet/Webdevelopers.html>. See also
<URL:http://www.anybrowser.org/campaign/index.html>.

If you are indeed a software professional, have a professional
attitude about this. Take pride in your work. Can you really be
proud of a home Web page that has 13 HTML errors? What does that
say about your professionalism and your computer expertise?

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

On Sun, 14 Aug 2005 23:29:55 +0900, Tim <tim@mail.localhost.invalid>
wrote:
[color=blue]
>Though the *BIG* problem with that is that one person's testing of invalid
>HTML only shows how well their browser handles it.[/color]

And this is why validation is so important.

It's impossible to "test" invalid HTML- you can only test "This HTML on
that browser". Although you can test invalid HTML, this inevitably has
to be a subjective test under one set of conditions "My computer, today,
with IE 7.0" The results of such a test are almost worthless for anyone
using a different combination.

Validation is objective, not subjective. The results won't always be
correct (IE box model), but at least there's a clearly pointing finger
at which is the culprit for getting it wrong. Making your valid layout
readable across all browsers still isn't easy, but it's a lot easier
than doing it for invalid code. IE's broken-ness for valid HTML is at
least reasonably described by previous developers -- its behaviour for
invalid code is an obscure minefield.

Dave Anderson wrote:
[color=blue]
> If someone ever comes up with a tool which reliably and conveniently
> recognizes and hides these abortions, I will be *so* glad...[/color]

FWIW, mod_accessibility offers a range of options for dealing with frames.

HTML has done better than that for more than a decade:
<link rel="foo" ...>. Ask your browser vendor why they
don't have a sensible implementation of this basic form
of non-intrusive navigation.

IMO the ideal implementation in a graphical browser would be
a popup menu of links built from the HTML. Of course it could
be presented in other ways, e.g. shown on-screen or activated
by a keystroke, but that should be a user preferences option.

--
Nick Kew

On Sun, 14 Aug 2005 11:06:45 -0400, Dave Anderson wrote:[color=blue]
> I'm constantly amazed (and dismayed) at the number of people who think
> that having a (usually rather large) "navigation area" permanently
> on-screen is a feature rather than a bug! Put the damned thing at the
> top or bottom of the page, where I can get to it in one keystroke on the
> rare occasions that I want to see it, rather than wasting a chunk of my
> limited screen space![/color]

Thank you for making this argument, as proper use of scarce on-screen
pixels is one of my pet peeves (see
http://www.aristeia.com/TKP/webpages.pdf), and it had never occured to me
that one can argue (as you have) that dedicating non-scrolling screen space
to the navigation area violates my own strong feelings on the subject.
I'll have to think about this further. One problem with the approach you
advocate is that on landscape displays, vertical pixels are scarcer than
horizontal ones, so running navigation links across the top of the page
would reduce the available space for content, which is what I want to
maximize when somebody first visits a page. Still, your argument is a good
one.

Scott

On Sun, 14 Aug 2005 12:32:14 -0700, David Ross wrote:[color=blue]
> The point of all this is that you should design your Web pages for
> viewing by ANY browser. To do that, you should design to the HTML
> and CSS specifications and not to any specific browser at all. If
> "It looks okay with IE" is your criterion, however, you have tied
> yourself to a fading star.[/color]

FWIW, I noted in my post that I currently check page output under IE and FF
(which just means I play around with modified pages with looking for
obvious display problems), and at the time I had the site orignally set up
in its current format (2000), one of the things I told the people doing the
work was that I expected it to view correctly on Windows, Mac, and Unix and
under at least IE, Netscape, and Opera. I plan to impose similar
constraints for this makeover.
[color=blue]
> Please see my
> <URL:http://www.rossde.com/internet/Webdevelopers.html>.[/color]

Nifty research, thanks. I see that designing/testing only for IE is a sore
point of yours :-) BTW, how did you arrive at your candidate list of site
developers?
[color=blue]
> If you are indeed a software professional, have a professional
> attitude about this. Take pride in your work. Can you really be
> proud of a home Web page that has 13 HTML errors? What does that
> say about your professionalism and your computer expertise?[/color]

If I claimed to be a web developer or to know a lot about web technologies,
it would say a lot. But I don't claim to be a web developer or to know
about such things. Perhaps it says that the people I hired to do my site
in 2000 were inept, though, to be honest, I don't know whether a site
designed to validate in 2000 would still validate today.

As I've mentioned elsewhere in this thread, my fundamental goal is to try
to educate myself enough about current web site design and implementation
issues to choose somebody to work on my site. The original question was
whether familiarity with or a commitment to validation was something I
should insist on when screening prospective web site maintainers. To be
honest, I'm still undecided on that. Your argument above is the moral one
and, as I've noted elsewhere, I'm fully behind the moral argument. But my
experience in 2000 was that it was very difficult to find *anybody* who was
willing to do a makeover on a small web site that would work across
browsers for a reasonable amount of money (which I'll arbitrarily define
as, say, under $5000), and your data don't make it look like adding a
validation requirement is going to make the job any easier. Add to that
the observation that most web sites don't seem to care enough above
validation to actually do anything about it, and morality begins to crumble
in the face of practicality.

If you know of a good way for me to identify candidate persons or firms for
the work I'm looking to have done on my site who are committed to
validation, I very much welcome your comments.

Scott

Scott Meyers wrote [in part]:[color=blue]
> FWIW, I noted in my post that I currently check page output under IE and FF
> (which just means I play around with modified pages with looking for
> obvious display problems), and at the time I had the site orignally set up
> in its current format (2000), one of the things I told the people doing the
> work was that I expected it to view correctly on Windows, Mac, and Unix and
> under at least IE, Netscape, and Opera. I plan to impose similar
> constraints for this makeover.[/color]

As a software developer, you know that the task is not completed
until the testing is satisfactory. Instead of viewing the pages in
a variety of browsers on a variety of platforms (you omitted
Safari, which Apple now installs on all Macs), testing should
involve validation against <URL:http://validator.w3.org/> for HTML
and against <URL:http://jigsaw.w3.org/css-validator/> for CSS.
Then, you only have to view the page with one browser on one
platform, to see that the content and layout are correct.

I previously wrote [also in part]:[color=blue][color=green]
> > Please see my
> > <URL:http://www.rossde.com/internet/Webdevelopers.html>.[/color]
>
> Nifty research, thanks. I see that designing/testing only for IE is a sore
> point of yours :-) BTW, how did you arrive at your candidate list of site
> developers?[/color]

I chose those Web developers who tried to sell their services on
this or other newsgroups. I also chose developers whose clients
complained that some browser was broken because their pages didn't
look right with that browser (the pages being at fault, not the
browser). Another is a former employer of mine (I'm now retired),
and one is the place where I buy my computers.
[color=blue]
> If I claimed to be a web developer or to know a lot about web technologies,
> it would say a lot. But I don't claim to be a web developer or to know
> about such things. Perhaps it says that the people I hired to do my site
> in 2000 were inept, though, to be honest, I don't know whether a site
> designed to validate in 2000 would still validate today.[/color]

A page that validated in 2000 and has had NO changes since then
should validate today for its version of HTML. It might not
validate for HTML 4.01, but newer browsers should remain backwards
compatible. (Some are not.) A page whose content is updated
should be upgraded to HTML 4.01 or XML 1.1 and validated again. A
page that is already HTML 4.01 or XML 1.1 should nevertheless be
revalidated each time it is updated, at least when the update is
more than merely changing existing text.
[color=blue]
> If you know of a good way for me to identify candidate persons or firms for
> the work I'm looking to have done on my site who are committed to
> validation, I very much welcome your comments.[/color]

Reject any individual or firm that uses FrontPage. This is a
Microsoft product that generates erroneous HTML that looks okay
with Internet Explorer because IE has compensating bugs.

Ask them what W3C is. If they don't know, be very careful. Ask
for the URLs to pages they have already developed; validate those
pages, both the HTML and CSS. For firms, also validate two pages
from their own Web sites, again both the HTML and CSS.

In either case, if there is no CSS in their pages, ask them to
explain why. If they don't know what CSS is, reject the
candidate.

If there are HTML or CSS errors, don't necessarily reject the
candidate. Instead, ask them to explain the errors. Judge the
candidate by their explanations. Ask them if they can develop a
Web site that not only has the content and layout you want but also
can be validated without any reported errors.

If your target audience might include handicapped or disabled
individuals, find out if the candidate knows what WAI or WCAG
mean. Look again at their prior products. Is there sufficient
contrast between text and background? Can text be resized? Can
the font be changed by the user? Are the pages designed to be
viewed with only a single screen size or color resolution? Is
right-left scrolling required? Is there excessive mouse action
needed to make use of the site? (Actually, these are good
questions even if your audience is not handicapped or disabled.)

Finally, remember that many who access the Internet from home do so
through dial-up modems. If your intended audience includes
individuals at home, look once more at a candidate's product, this
time using a dial-up connection. Does it take an excessive amount
of time to navigate through a site relative to the amount of
content? Ask the candidate whether the same layout and content
could be developed to use bandwidth more efficiently. (I know of
two Web sites that used to take an excessive amount of time to
display. One (now defunct) used many graphic images, each from a
different Web server; the images were gratuitous, adding nothing to
the content. The other (now redesigned to be more efficient)
contained several bulleted lists; the bullets were images that
loaded one at a time even though they were all identical.)

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

David Ross <nobody@nowhere.not> wrote:
[color=blue]
>As a software developer, you know that the task is not completed
>until the testing is satisfactory. Instead of viewing the pages in
>a variety of browsers on a variety of platforms (you omitted
>Safari, which Apple now installs on all Macs), testing should
>involve validation against <URL:http://validator.w3.org/> for HTML
>and against <URL:http://jigsaw.w3.org/css-validator/> for CSS.
>Then, you only have to view the page with one browser on one
>platform, to see that the content and layout are correct.[/color]

As much as I support validating, to claim that validation ensures cross
browser compatibility and/or can replace testing in various browsers is
nonsense.
[color=blue]
>A page whose content is updated
>should be upgraded to HTML 4.01 or XML 1.1[/color]

I presume that you are referring to XHTML1.1, note that to have that
rendered by IE it needs to be served as text/html, and serving XHTML1.1
as text/html violates w3c guidelines. If XHTML is going to be used at
all (it rarely makes sense to do so), then XHTML 1.0 Strict should be
used.
[color=blue]
>If there are HTML or CSS errors, don't necessarily reject the
>candidate. Instead, ask them to explain the errors. Judge the
>candidate by their explanations.[/color]

Now this is a much more sensible approach.
[color=blue]
>Ask them if they can develop a
>Web site that not only has the content and layout you want but also
>can be validated without any reported errors.[/color]

But then you blow it again :-) Validation is merely a tool, a skillful
developer can have a good reason to produce HTML that does not validate
against the public DTDs, and particularly "invalid" CSS (not that there
really is such a thing to begin with).

[other sound advice snipped]

--
Spartanicus

On Mon, 15 Aug 2005, Spartanicus wrote:
[color=blue]
> As much as I support validating, to claim that validation ensures
> cross browser compatibility and/or can replace testing in various
> browsers is nonsense.[/color]

While the word "ensures" there is clearly a hopeless exaggeration,
validation can nevertheless reveal errors which would be fixed-up in
different ways by different browsers. Correcting those errors is no
less optional than correcting spelling mistakes in a decently-produced
web page.

One could also say that the HTML specification represents a documented
ideal which all browsers should be aiming to implement. In that
sense, markup which conforms to that ideal - as opposed to relying on
browsers' ability to fixup errors and to guess what the author
intended in the absence of any documented norm - *ought* to promote
cross browser compatibility, even if exceptions can be found in
practice.

all the best

In our last episode,
<11fuvm21dcolc1d@corp.supernews.com>,
the lovely and talented Guy Macon
broadcast on comp.infosystems.www.authoring.html:
[color=blue][color=green]
>>Maybe all website designers have giant monitors on which they run a
>>browser full-screen, so they've got space to waste. I always have
>>multiple windows open, and never have enough screen real-estate
>>available[/color][/color]

So why don't you increase the size of your desktop? I find a
3x3 is more than adequate: that's two full screen browsers, a
word processor, a text edior, a couple of screens for graphic
work, a terminal, a screen full of control-panel type junk, and
one left over. It is also convenient to jump around with a mod
key and the key pad, which conveniently has an intuitive
relationship to a 3x3 layout.



--
Lars Eighner eighner@io.com http://www.larseighner.com/
I don't see posts from or threads started from googlegroups.
"We have no opinion on your Arab - Arab conflicts, such as your dispute with
Kuwait." -- Bush's Ambassador April Glaspie, giving Saddam Hussein
the greenlight to invade Kuwait.

"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote:
[color=blue][color=green]
>> As much as I support validating, to claim that validation ensures
>> cross browser compatibility and/or can replace testing in various
>> browsers is nonsense.[/color]
>
>While the word "ensures" there is clearly a hopeless exaggeration,[/color]

I hope you are attributing the exaggeration to David Ross.
[color=blue]
>validation can nevertheless reveal errors which would be fixed-up in
>different ways by different browsers. Correcting those errors is no
>less optional than correcting spelling mistakes in a decently-produced
>web page.[/color]

Spelling errors are revealed to all users 100% of the time, validation
errors are often both invisible and of no consequence to most visitors.

Comparing natural language syntax with markup and/or styling language
syntax makes no sense and can only muddy an already poorly understood
aspect of web authoring.

--
Spartanicus

On Mon, 15 Aug 2005, Lars Eighner wrote:
[color=blue]
> So why don't you increase the size of your desktop? I find a
> 3x3 is more than adequate:[/color]

I typically want to see two or more windows that I'm currently working
on alongside each other - not to merely have the option to switch
between them.

The remaining windows can indeed be hidden from view for the time
being - either behind the several currently active windows, or
minimised, or on another logical screen - but that's a different
matter.

Anyway, this isn't really the point. As an author, it's our job to
produce web pages that are useful and convenient for our *readers*.

Hassling each other here (most of us are presumably here because we
regard ourselves as web *authors*) to use our own displays in
different ways doesn't really address that important principle of
authoring for our users.

best regards.

On Mon, 15 Aug 2005, Spartanicus wrote:
[color=blue]
> "Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote:
>[color=green][color=darkred]
> >> As much as I support validating, to claim that validation ensures
> >> cross browser compatibility and/or can replace testing in various
> >> browsers is nonsense.[/color]
> >
> >While the word "ensures" there is clearly a hopeless exaggeration,[/color]
>
> I hope you are attributing the exaggeration to David Ross.[/color]

I'm sorry - I thought my meaning was evident from the context.
[color=blue][color=green]
> >validation can nevertheless reveal errors which would be fixed-up
> >in different ways by different browsers. Correcting those errors
> >is no less optional than correcting spelling mistakes in a
> >decently-produced web page.[/color][/color]

[...][color=blue]
> Comparing natural language syntax with markup and/or styling
> language syntax makes no sense[/color]

Was I comparing them? I was trying to say that both can contribute to
a quality web page.
[color=blue]
> and can only muddy an already poorly understood aspect of web
> authoring.[/color]

I say that both are aspects of quality control in publishing a web
page. I did not mean to imply that the two things are equivalent in
principle. I stand by my original assertion that both can and should
be non-optional quality control features of a web publishing process.

I'm not, of course, suggesting that correctness of either, or even
both, of them is a complete QA programme! Markup can be syntactically
correct while being semantically nonsense; spell checking can pass the
wrong word if the wrong word is spelled correctly. But both
procedures stand a chance of picking up inadvertent errors which would
be better corrected. And potentially much more effective as a QA
procedure than merely reviewing the completed page on one or a few
browsers. Sadly, the browser review is also a necessary chore
(particularly with MSIE, which rules itself out in various ways as a
web-compatible browser), but I still say that the formal syntax check
is a valuable and IMHO non-optional part of QA in the web publishing
process.

all the best

"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote:
[color=blue][color=green][color=darkred]
>> >validation can nevertheless reveal errors which would be fixed-up
>> >in different ways by different browsers. Correcting those errors
>> >is no less optional than correcting spelling mistakes in a
>> >decently-produced web page.[/color][/color]
>
>[...][color=green]
>> Comparing natural language syntax with markup and/or styling
>> language syntax makes no sense[/color]
>
>Was I comparing them?[/color]

"Correcting those [validation] errors is no less optional than
correcting spelling mistakes [...]" suggests a comparison of some sorts.
[color=blue]
>I was trying to say that both can contribute to
>a quality web page.[/color]

No argument there.
[color=blue]
>I'm not, of course, suggesting that correctness of either, or even
>both, of them is a complete QA programme![/color]

I know.

I'm concerned that albeit with good intentions people are using
incorrect arguments to justify validation. Imo the case for validation
cannot be summed up in a few simple "here's why you should" type rules.
Providing a case depends on many other variables.

Notwithstanding considerations such as voiced by the OP (requiring it
narrowing down the list of people able to do the work), perhaps
reversing the logic is the better approach: there are no good reasons
not to produce valid code [1].

[1] for the sticklers amongst us who think they've detected me
contradicting myself with an earlier post in the thread, note the
"public DTD" qualifier of that earlier post.

--
Spartanicus

On Mon, 15 Aug 2005, Spartanicus wrote:
[color=blue][color=green]
> >Was I comparing them?[/color]
>
> "Correcting those [validation] errors is no less optional than
> correcting spelling mistakes [...]" suggests a comparison of some sorts.[/color]

So, if I were to remark that in book publishing, checking of spelling
and of punctuation were both important, would you accuse me of
muddying the vital distinction between spelling and punctuation?
[color=blue]
> I'm concerned that albeit with good intentions people are using
> incorrect arguments to justify validation. Imo the case for
> validation cannot be summed up in a few simple "here's why you
> should" type rules.[/color]

Well, I'm sorry, but from my point of view, markup syntax validation
is a natural part of the QA process for web publishing; I don't feel I
need to justify it, any more than I'd need to justify checking the
spelling of the content, or making a reasonable effort to verify the
facts which I'm going to report on the page.

As I see it, it's the responsibility of anyone who claims that any of
these QA checks are unnecessary, to produce a convincing argument as
to why it's unnecessary, and I haven't yet seen an argument that I
found convincing. Some claimed that they were assembling the web page
automatically from parts that were stored in a database or content
manglement system, but that's no excuse for not having an assembly
process that either guarantees to produce correct markup syntax, or
one that checks the result of the assembly, IMNSHO.
[color=blue]
> Notwithstanding considerations such as voiced by the OP (requiring
> it narrowing down the list of people able to do the work), perhaps
> reversing the logic is the better approach: there are no good
> reasons not to produce valid code [1].[/color]

It looks as if we might be converging on some kind of agreement, in
our different ways ;-)

best regards

"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote:
[color=blue][color=green][color=darkred]
>> >Was I comparing them?[/color]
>>
>> "Correcting those [validation] errors is no less optional than
>> correcting spelling mistakes [...]" suggests a comparison of some sorts.[/color]
>
>So, if I were to remark that in book publishing, checking of spelling
>and of punctuation were both important, would you accuse me of
>muddying the vital distinction between spelling and punctuation?[/color]

The flaw in your (original) statement lies in the suggestion that both
have a similar effect on the user experience. This, as I pointed out
earlier, is not the case. I see no point in twisting an already
fundamentally flawed comparison between natural and markup/style
languages.

The OP is looking for