By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,838 Members | 1,623 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,838 IT Pros & Developers. It's quick & easy.

Looking for arguments in favor of valid markup

P: n/a
As well all know, valid markup is important... but when trying to find
a convincing modern argument in favor of this, I found pages like
http://www.htmlhelp.com/tools/validator/reasons.html
which was very nice when Netscape ruled the World Wide Web, and
http://valet.htmlhelp.com/page/why.html
which is very suggestive but does not really give any factual example.

Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?

All the tests that I souped up - say, wrapping a table and other stuff
inside <font>, using naked text inside <ul>, etc. - get similar
treatment on IE, Mozilla, and Opera. Different behavior on browsers
less common than these is important to me, but probably not to most
authors.

Most of the markup errors that would have an essential impact on
rendering on browsers probably have an essentially similar effect on
most popular browsers.

So does this really boil down to the conclusion that validation is
important for catching errors caused by _changes_? Suppose you write a
long page, later edit it a little. You might not check what it looks
like now if you only added a line. But you may have introduced a markup
error that turns the rest of the page bold, or something. If you
routinely validate your pages, your visitors would avoid some mess.

(Note: We know that in XHTML valid markup is a must, since it's XML and
in XML markup errors mean that the error is reported and nothing is
shown. But while waiting for XHTML to actually incarnate, does valid
markup really matter?)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #1
Share this Question
Share on Google+
38 Replies


P: n/a
Jukka K. Korpela wrote:
(Note: We know that in XHTML valid markup is a must, since it's XML and
in XML markup errors mean that the error is reported and nothing is
shown.


It doesn't have to validate. It just needs to be well-formed. If you
want to produce a document with XHTML elements, the namespace is most
important.
--
Anne van Kesteren
<http://www.annevankesteren.nl/>
Jul 20 '05 #2

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
news:Xn*****************************@193.229.0.31:
Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?

All the tests that I souped up - say, wrapping a table and other stuff
inside <font>, using naked text inside <ul>, etc. - get similar
treatment on IE, Mozilla, and Opera. Different behavior on browsers
less common than these is important to me, but probably not to most
authors.

Most of the markup errors that would have an essential impact on
rendering on browsers probably have an essentially similar effect on
most popular browsers.


Things get stickier once you start trying to script (DHTML) or style
invalid HTML. Of course, examples of this sort of failure would have to be
more substantial than the sort of simple examples that used to be able to
show incompatibility.
Jul 20 '05 #3

P: n/a
Jukka K. Korpela wrote:

Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or
Opera, just because it has an HTML syntax error that gets processed
in essentially different ways?


Perhaps this?

http://ln.hixie.ch/?start=1037910467&count=1

Any differences appear to be fairly trivial, though. If I understand
it correctly, it's limited to applying css and accessing elements via
the dom that's affected.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #4

P: n/a
Jukka K. Korpela <jk******@cs.tut.fi> wrote:
Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?


I recently encountered a page (which has since been fixed by the author)
that included markup like

<h3>Lorem Ipsum</h4>

Opera displayed the rest of the page as though it were part of the H3.
Apparently, the author's browser(s) didn't, but I didn't check any other
browsers.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Advice is what you ask for when you know the answer but wish you didn't."
Jul 20 '05 #5

P: n/a
Jukka K. Korpela wrote:
All the tests that I souped up - say, wrapping a table and other stuff
inside <font>, using naked text inside <ul>, etc. - get similar
treatment on IE, Mozilla, and Opera.


I'm not surprised, both Moz and Opera have fallen over themselves trying
to implement error behaviour similar to IE. Differences were greater
with earlier versions of Moz and Opera, but it's less easy to construct
convincing examples of rendering differences as a reason why folk should
validate with recent versions of these 2 browsers.

--
Spartanicus
Jul 20 '05 #6

P: n/a
Jukka K. Korpela wrote:
(Note: We know that in XHTML valid markup is a must, since it's XML and
in XML markup errors mean that the error is reported and nothing is
shown.


A compliant X(HT)ML parser is only required to throw a parsing error,
Opera for example does this but it also renders.

Moz doesn't, this is a major problem because it can't render until the
entire document has been loaded.

--
Spartanicus
Jul 20 '05 #7

P: n/a
On Mon, 12 Jan 2004 18:50:09 +0000, Jukka K. Korpela wrote:
As well all know, valid markup is important...


This might not answer you but it's just a thought. Valid mark-up does not
matter one iota to the end user. As long as the application (web page,
Perl script, C program, it doesn't matter) does The Expected Thing to the
end user, then that's all that matters. Valid mark-up only matters to the
developer, and it is important that he follows the standards set down by
the appropriate authority to ensure futureproofing of his work. Once a
standard has been set, it is not going to change. The application is
always going to work correctly as long as the interface adheres to that
standard. What is going to change is the interface - new versions of web
browsers, for example. Interface makers must do their best to support the
standards to make their product as attractive as possible to the user. The
problem is when interfaces do not adhere to standards or, even worse, make
up their own proprietary standards *cough*MSIE*cough*. This only serves to
fuck up development of the applications such that instead of writing valid
mark-up which should work in all so-called 'compliant' interfaces, various
'quirky' mark-up has to be written for each interface that differs.
Explain that to your boss, who thinks "as long as it works" and "it looks
alright to me". Tell him that next year, when the next release of x
browser comes out, all the apps may have to be rewritten.

And so, it is best if everybody stuck to standards, and that includes
browser makers.

And now I shall prepare for a shitload of corrections from everyone who
knows better than me :-)

--

..

Jul 20 '05 #8

P: n/a
Anne van Kesteren wrote:
Jukka K. Korpela wrote:
(Note: We know that in XHTML valid markup is a must, since it's XML
and in XML markup errors mean that the error is reported and nothing
is shown.


It doesn't have to validate. It just needs to be well-formed. If you
want to produce a document with XHTML elements, the namespace is most
important.


But then validation is much more important to SGML documents which
may include elements with only start tags and prohibited end tags
like in HTML... there's no way an UA could know if this is the case
if there's no DTD and the document doesn't validate according to it.

--
Stanimir
Jul 20 '05 #9

P: n/a
On Mon, 12 Jan 2004, Vigil wrote:
This might not answer you but it's just a thought. Valid mark-up does not
matter one iota to the end user.
Not in itself, no; but its indirect consequences may very well be of
critical importance, and in ways that the user themself is not really
aware of.
As long as the application (web page, Perl script, C program, it
doesn't matter) does The Expected Thing to the end user, then that's
all that matters.
For a rather diverse definition of "the application", yes.
And so, it is best if everybody stuck to standards, and that includes
browser makers.

And now I shall prepare for a shitload of corrections from everyone who
knows better than me :-)


Looks like you've got the Right Idea, which is the main thing ;-)

Jul 20 '05 #10

P: n/a
On Mon, 12 Jan 2004 18:50:09 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tut.fi> wrote:
does valid
markup really matter?


I see validation as a tool, a means to an end.

If I notice the problem where the end result is unexpected, one of the
first things I do is check the validation. More often than not, the error
is due to a missed tag, a typo, or an incorrectly handled attribute.
Validation catches these errors.

If the document validates but there is still an error, I have ruled out my
typing and form. The error is in the execution. So I've narrowed it down.

It's not essential that a web page validates. It is essential that the
author eliminates as many possible causes of a problem as possible when
trying to solve it.

Plus, there is the fact that some errors can result in correction by some
browsers and not in others, or inconsistent correction between browsers.
And that future user agents will be more conforming to the recommendations
than previous ones.

But none of this is of importance to the user. The user wants a web page
that satisfies their needs. Well-formed, valid code accomplishes only a
part of this - but it helps to eliminate possible, unforseen causes of
problems.

It's sort of like brushing your teeth. Sure, you can get away with no
brushing, but in time no one will want to kiss you and your aspirations to
be the next Maynard Ferguson are dashed to the rocks. Or, as I posted
elsewhere tonight, it's like the architect who neglects attention to the
structural needs of a building in favor of an aesthetic ideal, resulting
in the house toppling unceremoniously to the ground. That problem in the
structure can lead to major problems in the presentation down the road -
including the possible failure of the construction in ALL existing
environments.

Jul 20 '05 #11

P: n/a
On Mon, 12 Jan 2004 18:50:09 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:
Is there something to be _shown_ to people who ask "why validate?"?


No.
If there was, life would be simpler.

Similarly, there is no good commercial argument as to why
accessibility is good, or why Flash isn't. You either grok this or you
don't, and there's no concrete external reason (such as an effective
implementation of ADA) that can bludgeon it into the clueless.

--
Do whales have krillfiles ?
Jul 20 '05 #12

P: n/a
Neal wrote:
If I notice the problem where the end result is unexpected, one of the
first things I do is check the validation. More often than not, the error
is due to a missed tag, a typo, or an incorrectly handled attribute.
Validation catches these errors.


.... and if one doesn't try to write valid code in the first place, then
spotting the error causing the perceived problem amongst all the other
errors can be very difficult.

--
David Dorward <http://dorward.me.uk/>
Jul 20 '05 #13

P: n/a
Tim
On Mon, 12 Jan 2004 18:50:09 +0000 (UTC),
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
As well all know, valid markup is important... but when trying to find
a convincing modern argument in favor of this, I found pages like
http://www.htmlhelp.com/tools/validator/reasons.html
which was very nice when Netscape ruled the World Wide Web, and
http://valet.htmlhelp.com/page/why.html
which is very suggestive but does not really give any factual example.

Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?


I suppose it's hard to "demonstrate" a need to do it right, unless you
find some common browsers and current example bad pages; though I think
we all know (or should know) that we can't predict how future browsers
will behave, but we'd have a much greater chance of getting what we
expect, and something coherent, if we author pages correctly.

The same thing applies to HTML without any syntax errors, and HTML with
all the elements and attributes used for their proper purposes. For
instance - at some stage, the abuse of blockquote to indent text is
going to fail (it already does on one of my browsers), but for many
people using the currently available tools, they don't see anything
wrong.

If you want a really simple answer to "why," I suppose it's because you
know better than some other people. There's an awful lot of authors who
don't understand what they're doing, and they're the one that make the
really awful mistakes, with no clue as to why, nor how to rectify it.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.
Jul 20 '05 #14

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> writes:
Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?


<head><script></head><body>Stuff</body>

Displays 'Stuff' in Mozilla/Opera, hides the page completely in IE.

--
Chris
Jul 20 '05 #15

P: n/a
Chris Morris wrote:
"Jukka K. Korpela" <jk******@cs.tut.fi> writes:
Is there something to be shown to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?


<head><script></head><body>Stuff</body>

Displays 'Stuff' in Mozilla/Opera, hides the page completely in IE.


OK... but I'm sure I can find a dozen or more _valid_ HTML samples that
will do the same (work in one browser, completely break in another). So
invalid markup might break just as valid markup.
Jul 20 '05 #16

P: n/a
Jukka K. Korpela wrote:
[snip]
Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?

[snip]

One argument, possibly not very convincing, is that if your page validates,
and you ask a question in a NG or forum, you are more likely to get a straight
answer!

But the question "why validate?" is different from your subject, which is
"sort of" "why attempt to write valid mark-up?" I work on the principle that,
of the universe of possible combinations I could use, I *have* to draw the
line somewhere. Do I include proprietary mark-up? Deprecated mark-up? It is
safer to pick a pre-defined combination (I now use 4.01 Strict) than to
attempt to define my own combination. And having picked a pre-defined
combination, and attempted to write to it, if the code doesn't validate I have
broken *my own* rules. So validation is a cheap test of my own workflow.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #17

P: n/a
It seems "Philipp Lenssen" wrote in
comp.infosystems.www.authoring.html in article <bu0h2v$c90be$1@ID-
203055.news.uni-berlin.de>:
OK... but I'm sure I can find a dozen or more _valid_ HTML samples that
will do the same (work in one browser, completely break in another). So
invalid markup might break just as valid markup.


Yes of course. But invalid markup is _more_ likely to break, which
seems to me a justification for valid markup.

When I spent a lot of time writing programs in C and C++, and Algol
and Fortran and Cobol before that, not to mention flavors of
assembler -- where was I? oh yes, at well-run shops it was a
standard that code must compile cleanly, without even a warning. The
reason was that if we get in the habit of ignoring particular
warnings because they "don't really matter in this case" we will
also ignore warnings that do matter.

Getting a clean compile (or a cleanly validating document) doesn't
guarantee that the program or document does what you want. But it at
least catches the boneheaded errors that no author will notice from
_any_ amount of proofreading.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #18

P: n/a
In article <1K***************@newsfep3-gui.server.ntli.net>, one of infinite monkeys
at the keyboard of "Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:
But the question "why validate?" is different from your subject, which is
"sort of" "why attempt to write valid mark-up?" (chop nice explanation)


Have you contemplated a "why validate" page that might complement those
already cited?

I'm thinking: it's clear from your posting record that you've given it
a lot of thought, and that you've approached it from a thoroughly
pragmatic point of view as a practicing web developer. So I'm thinking
you might be well-placed to make a valuable contribution over and
above your participation in the newsgroups.

--
Nick Kew
Jul 20 '05 #19

P: n/a
Nick Kew wrote:
In article <1K***************@newsfep3-gui.server.ntli.net>, one of
infinite monkeys at the keyboard of "Barry Pearson"
<ne**@childsupportanalysis.co.uk> wrote:
But the question "why validate?" is different from your subject,
which is "sort of" "why attempt to write valid mark-up?"

(chop nice explanation)


Have you contemplated a "why validate" page that might complement
those already cited?

I'm thinking: it's clear from your posting record that you've given it
a lot of thought, and that you've approached it from a thoroughly
pragmatic point of view as a practicing web developer. So I'm
thinking
you might be well-placed to make a valuable contribution over and
above your participation in the newsgroups.


Lots of what I write in NGs ends up being converted into web pages. (The first
200 pages or so of my Child Support Analysis web site had a basis in NGs!)

But in this case I responded to Jukka, giving him first call. I don't have a
hang-up about whose name is attached.

I am steadily building up pages about the web. I have several more under
development. They take massive effort to become reasonable web pages!
http://www.barry.pearson.name/articles_papers.htm

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #20

P: n/a
Andy Dingley <di*****@codesmiths.com> wrote:
On Mon, 12 Jan 2004 18:50:09 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:
Is there something to be _shown_ to people who ask "why validate?"?
No.
If there was, life would be simpler.


Well I think this discussion has indicated that there's _something_ to
be shown. Nothing very impressive, but still.
Similarly, there is no good commercial argument as to why
accessibility is good, or why Flash isn't.


I'd say there are. Actually, I have often managed to convince people of
the importance of accessibility by demonstrations. To take a typical
example, very small fonts imply that older people can't read the text
conveniently, and this means a lot of lost customers. Regarding Flash,
it's usually easy to demonstrate how it reduces useability.

Validity isn't really comparable.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #21

P: n/a
In article <Xn*****************************@193.229.0.31>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?
I suppose the canonical example these days is Ian Hickson's "Tag Soup:
How UAs handle <x> <y> </x> </y>"
(http://ln.hixie.ch/?start=1037910467&count=1), which was already
mentioned. I have a page about the treatment of Hixie's example in
Safari and Mac IE 5 (http://iki.fi/hsivonen/soup-dom.html).
(Note: We know that in XHTML valid markup is a must, since it's XML and
in XML markup errors mean that the error is reported and nothing is
shown. But while waiting for XHTML to actually incarnate, does valid
markup really matter?)


Since you have the previously been strict about the use of the word
"valid", I'm going to split hairs, too. :-)

Only well-formedness errors are fatal errors in XML. From the
performance point of view, it doesn't make sense to use a validating XML
processor in an interactive applications such as a Web browser. This
isn't just theory. Mozilla, Safari and Opera all use expat which is a
non-validating XML processor. Hence, markup errors which do not violate
well-formedness constraints but only violate validity constraints go
unreported in browsers even when XHTML is served as
application/xhtml+xml.

I think if the question about the usefulness of validity has to facets
which need to be addressed separately. The first facet is whether it's
useful to adhere to a particular set of rules concerning the form of the
document tree. The second facet is whether it's useful to include an
additional incantation that fulfills the formal requirements of being
valid either in the SGML sense or in the XML sense.

When sending markup as text/html, it is useful to adhere to the rules
concerning element nesting, because the tag soup parsers assumes some
rules about the nesting of elements (for example, inline elements can't
have block children) and deviating from the rules may cause different
parsers to do different fix-ups. As for attributes, superfluous
attributes are usually gracefully ignored, but including home-grown
attributes only for them to be ignored is rather pointless. Anyway, it
makes sense to adhere to the rules set about the form of the document
tree.

text/html is subject to doctype sniffing. In order to get proper layout
(Standards mode) one has to include a doctype declaration that triggers
the Standards mode. Since adhering to the rules placed on the document
tree is useful and a doctype declaration is needed for reason other than
validation, you might as well fulfill the requirements of the SGML
formalism while you're at it. If nothing else, doing so is considered a
sign of cluefulness, which is beneficial when trying to get help with an
authoring problem.

When sending markup using an XML content type, XML parsing makes sure
the document tree is unambiguous as far as element nesting goes. (In
theory, DTD processing could cause differences with whitespace and
attributes, but in practice the DTD is in processed.) When considering
only document rendering in browsers whose layout engine is about as
close to pure CSS render as you can usefully get, deviating from the
element nesting rules isn't fatal if the rendering of the elements in
question depends only on generic CSS formating (that excludes, for
example, forms). However, in other user agents failure to adhere to the
nesting rules might lead to problems. For example, the embedded browser
of Sony Ericsson T68i doesn't tolerate inline content directly in the
<body> without a block wrapper. Even in browsers that are closer to a
generic XML + CSS render, adhering to the rules minimizes problems (eg.
with the user agent style sheet).

However, when XML is processed in non-bogotic way, all that should
matter are the elements (including their attributes), character data and
processing instructions--not the exact doctype incantation. Therefore,
if you can make sure the document parses into a sensible document tree
using some other means such as procedural checking, Relax NG validation
or DTD validation without a doctype (the override mode in the W3C
validator), including the doctype declaration doesn't really improve
your document in terms of what an application sees. On the other hand,
including a well-known doctype decoration without declaring the document
standalone causes Mozilla to burn extra cycles for parsing a pseudo-DTD.
A user agent parsing the real DTD would burn a whole lot more of cycles
for no gain.

The downside with omitting the doctype declaration on a page served as
application/xhtml+xml is that your page wont be "strictly conforming"
(What's the benefit of being "strictly conforming"?) and people who
haven't figured out how real XML parsers work and focus pleasing the W3C
validator think you've made a mistake and say so.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jul 20 '05 #22

P: n/a
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:
Lots of what I write in NGs ends up being converted into web pages.
Good.
But in this case I responded to Jukka, giving him first call. I
don't have a hang-up about whose name is attached.


I'm afraid I currently lack the resources for putting this stuff
together and making it a Web page, so I hope someone else does that.
And I'm probably too biased, after considering mainly the _problems_ of
validation (which are very real too - people don't understand what it
is, waste their time trying to understand validator messages instead of
learning HTML and fixing markup, etc.).

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #23

P: n/a
In article <1K***************@newsfep3-gui.server.ntli.net>,
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:
Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?

[snip]

One argument, possibly not very convincing, is that if your page validates,
and you ask a question in a NG or forum, you are more likely to get a straight
answer!

But the question "why validate?" is different from your subject, which is
"sort of" "why attempt to write valid mark-up?" I work on the principle that,
of the universe of possible combinations I could use, I *have* to draw the
line somewhere. Do I include proprietary mark-up? Deprecated mark-up? It is
safer to pick a pre-defined combination (I now use 4.01 Strict) than to
attempt to define my own combination. And having picked a pre-defined
combination, and attempted to write to it, if the code doesn't validate I have
broken *my own* rules. So validation is a cheap test of my own workflow.


Another reason, that IMO follows from this, is that once you start
writing 'by the rules', instead of your _own_ personal rules, peole who
have to work together with you, or later have to add to or change the
documents will have a better chance doing so because of a set collection
of rules.

My colleague and I don't have 'language problems' anymore since we both
started using the same standard, instead of each his own.

--
Kris
kr*******@xs4all.netherlands (nl)
Jul 20 '05 #24

P: n/a
Jukka K. Korpela wrote:
As well all know, valid markup is important... but when trying to find
a convincing modern argument in favor of this, I found pages like
http://www.htmlhelp.com/tools/validator/reasons.html
which was very nice when Netscape ruled the World Wide Web, and
http://valet.htmlhelp.com/page/why.html
which is very suggestive but does not really give any factual example.
In the same vein:

<URL:http://www.evolt.org/article/Forward_compatibility_and_web_standards/17/60115/index.html#comment60184>

<URL:http://weblogs.mozillazine.org/hyatt/archives/2003_03.html#002904>
(I believe Safari's behaviour has changed since this was written.)

<URL:http://ln.hixie.ch/?start=1037910467&count=1>

Is there something to be _shown_ to people who ask "why validate?"?
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?
The way I look at it is that "bugs" that can be demonstrated *today* aren't
the real problem. Given a decent testing environment, you can find and fix
the problems like this that will affect the majority of your visitors.

The problems I think about when using invalid code are the problems that you
*can't* adequately check for up-front. The one-off scripts. The
bookmarklets. The future browsers. These problems shift the cost of
fixing the problems to some unknown time in the future, when you may not be
as well-prepared to deal with them.

Which is better - making sure your website uses valid code before the site
launches, or finding out that the newly-released Internet Explorer can't
render your pages the day after your lead developer quits/gets hit by a
bus/etc?

All the tests that I souped up - say, wrapping a table and other stuff
inside <font>, using naked text inside <ul>, etc. - get similar
treatment on IE, Mozilla, and Opera. Different behavior on browsers
less common than these is important to me, but probably not to most
authors.
Perhaps trawling through the bug databases for various browsers would be
useful. I know I've spotted many bugs in the Mozilla and Konqueror bug
databases that are essentially "This page doesn't work right. I know it's
not valid, but we need to render it in the way the author
expects." [loosely translated as "the way Internet Explorer on Windows does
it."]

For example, these kinds of bug reports:

<URL:http://bugs.kde.org/show_bug.cgi?id=22509>
<URL:http://bugs.kde.org/show_bug.cgi?id=26189>

I know it's not strictly a _validation_ issue, but the text/css vs
text/plain content-type is a very striking example of deviating from spec.
and unexpectedly paying the price. Also a:hover vs :link:hover catching out
<a name="..." id="...">...</a> constructs.

To be honest, it's hard to think of bugs like these off the top of my head
because it's been a while since I've had to deal with invalid HTML on a
regular basis.

Most of the markup errors that would have an essential impact on
rendering on browsers probably have an essentially similar effect on
most popular browsers.

[snip]

I'd modify that slightly to "Most of the _common_ markup errors...".
Browser vendors aren't going to include workarounds to problems they've
never heard of or only exist on a couple of obscure websites. If you are
going to write invalid code, you'll have to make sure you write the "same
sort" of invalid code as everyone else - a concept that's inherently
undefined, unreliable, and prone to change (as demonstrated by the "4
reasons..." page).
--
Jim Dabell

Jul 20 '05 #25

P: n/a
Henri Sivonen <hs******@iki.fi> writes:
Only well-formedness errors are fatal errors in XML.
For an archaic medium like the web, that's bad enough (client side
software can break anything you wrote correctly -- you are an optimist
if you think your source code has to be delivered *as is* to the
application at the end of the alley).
text/html is subject to doctype sniffing. In order to get proper layout
(Standards mode) one has to include a doctype declaration that triggers
the Standards mode.
In order to avoid a couple of exclusively new bugs of IE6' "standards
compliance" and since authors are not in the position to *guarantee*
anything else (see above), triggering 'Quirks Mode' should be considered
a smart move, IMNSHO.
Since adhering to the rules placed on the document
tree is useful and a doctype declaration is needed for reason other than
validation,
Ah; like what?
you might as well fulfill the requirements of the SGML
formalism while you're at it.
Like Annex K?
If nothing else, doing so is considered a
sign of cluefulness,


Doctype declarations are redundant, especially for HTML; if there was
ever any doubt, doctype sniffing at least has proven it. What's more,
there's absolutely no reason at all why the syntax of an HTML document
instance should conform to the declared syntax anymore; after all,
that's the point of doctype sniffing, using something that's effectively
unused as a processing instruction surrogate.
--
| ) 111010111011 | http://bednarz.nl/
-(
| ) Distribute me: http://binaries.bednarz.nl/mp3/aisha
Jul 20 '05 #26

P: n/a
Kris wrote:
In article <1K***************@newsfep3-gui.server.ntli.net>,
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

[snip]
But the question "why validate?" is different from your subject,
which is "sort of" "why attempt to write valid mark-up?" I work on
the principle that, of the universe of possible combinations I could
use, I *have* to draw the line somewhere. Do I include proprietary
mark-up? Deprecated mark-up? It is safer to pick a pre-defined
combination (I now use 4.01 Strict) than to attempt to define my own
combination. And having picked a pre-defined combination, and
attempted to write to it, if the code doesn't validate I have broken
*my own* rules. So validation is a cheap test of my own workflow.


Another reason, that IMO follows from this, is that once you start
writing 'by the rules', instead of your _own_ personal rules, peole
who have to work together with you, or later have to add to or change
the documents will have a better chance doing so because of a set
collection of rules.

My colleague and I don't have 'language problems' anymore since we
both started using the same standard, instead of each his own.


Excellent point. I have often worked in large teams, not working with HTML/CSS
but with various design & programming languages, and what you say it vitally
important. It also applies when doing non-code things like writing
specifications & other documentation. Every single aspect of the project is
improved - you re-use templates and word processor styles which are developed
just once (possibly on an earlier project!), you can exchange material, take
over from someone else, easily read what someone else has written, etc. You
can "hit the ground running", or at least walking.

In the case of the web, I often copy ideas from others, and I expect others do
the same. In effect, we are all part of a very large team, using each-other's
templates, CSS-ideas, etc. (Hm! Some copyright implications here!) The web
develops faster this way. This is more of an advantage to others of your own
use of standards, so it may not convince your client.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #27

P: n/a
Jukka K. Korpela wrote:
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

[snip]
But in this case I responded to Jukka, giving him first call. I
don't have a hang-up about whose name is attached.


I'm afraid I currently lack the resources for putting this stuff
together and making it a Web page, so I hope someone else does that.
And I'm probably too biased, after considering mainly the _problems_
of validation (which are very real too - people don't understand what
it is, waste their time trying to understand validator messages
instead of learning HTML and fixing markup, etc.).


I'll add it to my list of things to do! But don't hold your breath.

What I wrote was my personal reasons. I think for a web page more than that is
needed. It needs some research - I don't want to repeat what someone has
already said. (And I knew you have written on the subject of validation, but
from a different perspective). I suspect that someone has done real relevant
research - to some extent, this is concerned with "re-use", and there is quite
a bit about that around. (It is long-standing interest of mine, along with
"knowledge sharing").

It might be interesting to reflect on why I do what I do. Can I explain it to
myself in a way that convinces *me*? All business processes (and that is
really what this is part of) should have a "process improvement process". I
may come to the conclusion that I'm wasting my time and should just publish
tag-soup! I suspect not.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #28

P: n/a
Tim
On Wed, 14 Jan 2004 19:08:14 +0000 (UTC),
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:
...[snip]... after considering mainly the _problems_ of
validation (which are very real too - people don't understand what it
is, waste their time trying to understand validator messages instead of
learning HTML and fixing markup, etc.).


So are you saying that one of the *big* problem is less than helpful
messages from the validator?

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.
Jul 20 '05 #29

P: n/a
Tim <Ti*@mail.localhost> wrote:
So are you saying that one of the *big* problem is less than helpful
messages from the validator?


Not really. Although there are things that could be improved in those
messages (as you can see by comparing the messages from the W3C
validator and the WDG validator), it's a bit risky. I once submitted
some proposal to make the WDG validator messages more helpful, and
although they may have improved them a little bit on the average, I've
noticed that at times they make things _worse_. That's a problem in
heuristics, i.e. when one tries to guess what the _actual_ mistake by
the user was. If you guess wrong, he'll get even more confused.

Besides, in principle, validation has little degrees of freedom,
and you _cannot_ understand validator messages properly without
understanding some basics (which people usually don't understand).
It's all about syntax checking, so the messages _need_ to relate to
pure syntax ultimately - although the validator _could_ conceivably
make guesses and suggestions.

On the other hand, this would mean special coding to deal with HTML
specifically, and quite a lot of coding. If someone wants to do that,
he might as well design a decent general HTML checker, if you ask me.
(There are many things that could be checked automatically, even things
that relate to objective compliance. For example, bgcolor attributes
have well-defined syntax, which cannot be checked by a validator but
would be very easy to check.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #30

P: n/a
In article <m3************@email.bednarz.nl>,
Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote:
Henri Sivonen <hs******@iki.fi> writes:
Only well-formedness errors are fatal errors in XML.


For an archaic medium like the web, that's bad enough (client side
software can break anything you wrote correctly -- you are an optimist
if you think your source code has to be delivered *as is* to the
application at the end of the alley).


If a proxy turns an XML document labeled using an XML content type into
something that isn't well-formed while keeping the XML content type
label, the proxy is doing a very bad thing and should be removed from
the network.
text/html is subject to doctype sniffing. In order to get proper layout
(Standards mode) one has to include a doctype declaration that triggers
the Standards mode.


In order to avoid a couple of exclusively new bugs of IE6' "standards
compliance"


Can you give examples? (Is the bug that causes text to move slightly on
hover exclusive to the Standards mode?)
Since adhering to the rules placed on the document
tree is useful and a doctype declaration is needed for reason other than
validation,


Ah; like what?


Activating the Standards [layout] mode in browsers that have one.
you might as well fulfill the requirements of the SGML
formalism while you're at it.


Like Annex K?


I meant being free of "reportable markup errors" as defined in ISO 8879.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jul 20 '05 #31

P: n/a
On Thu, 15 Jan 2004 10:36:08 -0000, "Barry Pearson"
<ne**@childsupportanalysis.co.uk> declared in
comp.infosystems.www.authoring.html:
Kris wrote:

Another reason, that IMO follows from this, is that once you start
writing 'by the rules', instead of your _own_ personal rules, peole
who have to work together with you, or later have to add to or change
the documents will have a better chance doing so because of a set
collection of rules.

<snip>
This is more of an advantage to others of your own
use of standards, so it may not convince your client.


Looking at it from another perspective, if you get hit by a bus, it is
much easier for your replacement to pick up where you left off if you
are both using the same standards. That may carry more weight with your
client.

<aside>When you first started posting to this group, I assumed that you
were yet another clueless designer who refused to have anything to do
with CSS because "that's not the way we do it". Your posts in recent
times have led me to rethink that assumption, as you are evidently
highly intelligent and have obviously put a lot of time and thought into
your decisions and opinions. In the short time you have been here, you
have become a valuable asset to this group. My apologies for my hasty
(and wrong) conclusions.</aside>

--
Mark Parnell
http://www.clarkecomputers.com.au
Jul 20 '05 #32

P: n/a
Henri Sivonen <hs******@iki.fi> writes:
Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote: If a proxy turns an XML document labeled using an XML content type into
something that isn't well-formed while keeping the XML content type
label, the proxy is doing a very bad thing and should be removed from
the network.
No argument here, IRL the proxy is rather an adwasher or desktop
'security' feature. Most home machines should be removed from *the*
network indeed. :)

As far as doctype sniffing is concerned, when IE 6 came out I was
getting all pages in quirks mode due to 3rd party software, quite a
source of confusion and not the fault of the software. Comments in the
prologue are perfectly legal, unlike mystery meat heuristics to detect
'standards compliance'.
In order to avoid a couple of exclusively new bugs of IE6' "standards
compliance"


Can you give examples?


Sure.

<http://sandbox.bednarz.nl/css/msie/bungy01.html>

Oh well...

<http://groups.google.com/groups?selm=Xns9208C156F3EE7rantbox%4024.132.65.13 >
a doctype declaration is needed for reason other than
validation,


Ah; like what?


Activating the Standards [layout] mode in browsers that have one.


My bad, I was thinking about SGML defined purposes.
I meant being free of "reportable markup errors" as defined in ISO 8879.


It's not practical either to want an HTML UA to be a validating SGML
parser, fully-tagged document instances are perfectly fine without a
doctype declaration. Trivial stuff like syntactical conformance can be
handled on the authoring level and shouldn't be a required artefact for
productive resources. Hence the web TC.

Furthermore, what's valid or not may just depend from system to system;
for example, if I'd locally validate a document that references the
external subset of HTML 4.0 in its declaration by formal public - and
system identifier, the result might differ from e.g. the W3C validation
service because my catalogue file doesn't resolve the FPI and the system
identifier actually resolves to the external subset of HTML 4.01.

Popcorn?
--
| ) 111010111011 | http://bednarz.nl/
-(
| ) Distribute me: http://binaries.bednarz.nl/mp3/aisha
Jul 20 '05 #33

P: n/a
On Thu, 15 Jan 2004 18:22:16 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:
Tim <Ti*@mail.localhost> wrote:
So are you saying that one of the *big* problem is less than helpful
messages from the validator?


Not really. Although there are things that could be improved in those
messages (as you can see by comparing the messages from the W3C
validator and the WDG validator), it's a bit risky. I once submitted
some proposal to make the WDG validator messages more helpful, and
although they may have improved them a little bit on the average, I've
noticed that at times they make things _worse_. That's a problem in
heuristics, i.e. when one tries to guess what the _actual_ mistake by
the user was. If you guess wrong, he'll get even more confused.

Besides, in principle, validation has little degrees of freedom,
and you _cannot_ understand validator messages properly without
understanding some basics (which people usually don't understand).
It's all about syntax checking, so the messages _need_ to relate to
pure syntax ultimately - although the validator _could_ conceivably
make guesses and suggestions.


Yes, I think the main message has to relate to the syntax. One can then
add (in brackets afterwards, or via a link) some suggestions as to the
sort of mistake that results in that syntax error.

However I've just bumped into something else - the W3C validator seems
to have disabled the 'referrer' syntax. I can't think why. I always
found that useful when I modified a page and wanted to do a quick check
that I hadn't introduced any syntax errors. Can anyone shed any light?

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Jul 20 '05 #34

P: n/a
DU
Jukka K. Korpela wrote:
As well all know, valid markup is important... but when trying to find
a convincing modern argument in favor of this, I found pages like
http://www.htmlhelp.com/tools/validator/reasons.html
which was very nice when Netscape ruled the World Wide Web, and
http://valet.htmlhelp.com/page/why.html
which is very suggestive but does not really give any factual example.

The http://www.htmlhelp.com/tools/validator/reasons.html page is not
very good IMO. I'm sure you'll recall hearing me repeat that in alt.html.
Is there something to be _shown_ to people who ask "why validate?"?
The "why validate?" question has to be closely related to the objective
concrete quantifiable benefits of using valid markup. AFAIK, showing
examples (live examples, demo examples) of such benefits have not been
done anywhere on the web.
A page that works one way on IE and another way on Mozilla or Opera,
just because it has an HTML syntax error that gets processed in
essentially different ways?

Here's one example that I see very often. Use of marginwidth,
marginleft, margintop and marginheight all equal to 0. Only NS4+
browsers can render such values; MSIE 5+ will just ignore these and
render a default
body {margin:15px 10px;}
declaration. So, on one hand, NS browsers will have 0 margin on the body
while MSIE browsers will render such margin. By just validating and
using valid markup, the page would have been rendered much more closely
by both browser families. (NS 6+ have a default margin:8px on the body
element; best would be to edit an unique declaration which would be
followed by all browsers regarding margin on the body element).
An live example of this is
AffordableHost.com
http://www.affordablehost.com/
Just examine the page rendering with an NS 6+ or Mozilla-based browser
and a MSIE 5+ browser.
All the tests that I souped up - say, wrapping a table and other stuff
inside <font>, using naked text inside <ul>, etc. - get similar
treatment on IE, Mozilla, and Opera. Different behavior on browsers
less common than these is important to me, but probably not to most
authors.

Most of the markup errors that would have an essential impact on
rendering on browsers probably have an essentially similar effect on
most popular browsers.

So does this really boil down to the conclusion that validation is
important for catching errors caused by _changes_?
Not in my opinion. Validation is still much more important for newbies
doing new content edition. Validation should be part of any HTML editing
softwares like FrontPage, DreamWeaver, etc.

DU

Suppose you write a long page, later edit it a little. You might not check what it looks
like now if you only added a line. But you may have introduced a markup
error that turns the rest of the page bold, or something. If you
routinely validate your pages, your visitors would avoid some mess.

(Note: We know that in XHTML valid markup is a must, since it's XML and
in XML markup errors mean that the error is reported and nothing is
shown. But while waiting for XHTML to actually incarnate, does valid
markup really matter?)


Jul 20 '05 #35

P: n/a
Mark Parnell wrote:
On Thu, 15 Jan 2004 10:36:08 -0000, "Barry Pearson"
<ne**@childsupportanalysis.co.uk> declared in
[snip] Looking at it from another perspective, if you get hit by a bus, it is
much easier for your replacement to pick up where you left off if you
are both using the same standards. That may carry more weight with
your client.
Yes.
<aside>
When you first started posting to this group, I assumed that
you were yet another clueless designer who refused to have anything
to do with CSS because "that's not the way we do it". Your posts in
recent times have led me to rethink that assumption, as you are
evidently highly intelligent and have obviously put a lot of time and
thought into your decisions and opinions. In the short time you have
been here, you have become a valuable asset to this group. My
apologies for my hasty (and wrong) conclusions.
</aside>


Wow! I rarely see anything like that. You are clearly the sort of person I can
talk to constructively. We may not agree on all things, but we appear to have
an understanding, even if only to agree to disagree! Thank you for that.

Why shouldn't you have thought that I was a clueless designer? Although I have
decades of experience of helping to design large-scale computer systems, and
developed web sites in an Intranet in 1995/6, I only started to use CSS about
15 months ago, and only started to use doctypes (hence HTML standards) about a
year ago. I'm really a newbie in both of those areas. 80% of the people here
can run rings round me as far as knowledge of (X)HTML and CSS is concerned.
That is why I'm here - to learn.

My skills are not in knowledge in depth in any particular area. There are only
one or two areas where I will ever achieve that. (There is only one area where
I could be considered to be a world expert, and it is nothing to do with the
web). As a consultant, I go into organisations where everyone I meet knows
more than me about the organisation and its business. I don't treat this as an
ego problem. It is a fact of life that the people I work with know more than
me! If this was a problem, I would probably have to shoot myself.

My skills are, instead, to objectively disentangle the complex confusions that
people build up during their lives. Two people who appear to disagree
fundamentally may actually agree 60% of the time, but cannot possibly come
that realisation by themselves. Sometimes I facilitate workgroups where
participants gradually find common understanding - and I need know nothing
(well, something!) about what they are discussing! I always try to exit from
an organisation without anyone thinking that I own the answer, but realising
instead that they do.

Where layout-tables versus CSS positioning is concerned, I intend to be good
at both, and not prejudiced against either. And therefore be able to beat the
heck out of anyone who is fixed on one position or the other and could never
mix the two! Here are my views on the matter, in 5 separate articles:

"Layout tables considered valuable"
http://www.barry.pearson.name/articles/layout_tables/

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #36

P: n/a
In article <m3************@email.bednarz.nl>,
Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote:
Henri Sivonen <hs******@iki.fi> writes:
Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote:
In order to avoid a couple of exclusively new bugs of IE6' "standards
compliance"
Can you give examples?


Sure.

<http://sandbox.bednarz.nl/css/msie/bungy01.html>

Oh well...

<http://groups.google.com/groups?selm=Xns9208C156F3EE7rantbox%4024.132.65.13 >


I don't think that is bad enough to justify the avoidance of the
Standards mode.
I meant being free of "reportable markup errors" as defined in ISO 8879.


It's not practical either to want an HTML UA to be a validating SGML
parser,


I didn't suggest that.
fully-tagged document instances are perfectly fine without a
doctype declaration.
Except that they aren't perfectly fine considering the reality of
doctype sniffing.

Neither broken proxies nor doctype sniffing up pretty things in
principle. I think it is practical use a doctype that wins me standards
layout, but I refuse to accommodate broken proxies. I guess we disagree
on what ugliness we choose to accommodate.
Trivial stuff like syntactical conformance can be
handled on the authoring level and shouldn't be a required artefact for
productive resources.


I agree in principle, which is why I think it is harmful to require the
cargo cultish inclusion of the doctype incantation in the document that
gets sent over the network when a real XML processor is being used.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jul 20 '05 #37

P: n/a
Henri Sivonen <hs******@iki.fi> writes:
I don't think that is bad enough to justify the avoidance of the
Standards mode.
I dont't think anything is good enough to justify the presence of
doctype sniffing in the first place.
Neither broken proxies nor doctype sniffing up pretty things in
principle. I think it is practical use a doctype that wins me standards
layout,
Oh, I get the general idea all right, it's just totally unreliable (and
redundant if you need to cater for IE<6 anyway) in *practical* use and
braindead in theory. The remains are fine with me.
but I refuse to accommodate broken proxies.
<!-- saved from foobar --><!DocHype to be inserted here>

Nothing broken to be spotted. Bye bye, 'standards compliance' in
MSIE/win (at least).
I guess we disagree
on what ugliness we choose to accommodate.
It can't get much uglier -- well, let's just say clueless -- as doctype
sniffing. If that's the result of web designers fighting for standards,
I'd much prefer if they didn't, in favour of -- let's say -- playing
cricket.
I think it is harmful to require the
cargo cultish inclusion of the doctype incantation in the document that
gets sent over the network when a real XML processor is being used.


Hey! I wanted to say that! (It's my only line :)
--
| ) 111010111011 | http://bednarz.nl/
-(
| ) Distribute me: http://binaries.bednarz.nl/mp3/aisha
Jul 20 '05 #38

P: n/a
In article <m3************@email.bednarz.nl>,
Eric B. Bednarz <be*****@fahr-zur-hoelle.org> wrote:
Henri Sivonen <hs******@iki.fi> writes: Oh, I get the general idea all right, it's just totally unreliable (and
redundant if you need to cater for IE<6 anyway)
I care more about Mozilla, Safari and Opera than I care about IE 5 (or
IE 6, for that matter).
but I refuse to accommodate broken proxies.


<!-- saved from foobar --><!DocHype to be inserted here>

Nothing broken to be spotted.


Point taken.
Bye bye, 'standards compliance' in MSIE/win (at least).


But not in Mozilla or Safari.

--
Henri Sivonen
hs******@iki.fi
http://iki.fi/hsivonen/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html
Jul 20 '05 #39

This discussion thread is closed

Replies have been disabled for this discussion.