W
William Gill
Ben,Ben said:
I'm not sure if you are supporting or contradicting what I said, but the
general impression I get is that you state a lot of facts that don't
address the underlying logic of what validation is or isn't, and what's
its purpose. So I will try again.
Given
1: A DTD is a set of rules that a document structure agrees to follow.
2: Validation is the process of comparing a document that DTD.
3: Validation errors are specific infractions of the document not
conforming to the rules.
Therefore:
For purposes here (the HTML document creation world) for validation to
be of much use we all must agree to adopt a common ruleset (DTD), i.e.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Strict//EN">
You could create and publish your own document definition, <!DOCTYPE
HTML PUBLIC "-//W3C//DTD BEN 1.0 NotSoStrict//EN">, but it is unlikely
Microsoft, Google, Mozilla or anyone would use it as the basis for their
rendering engine. After all look at how resistant they already are to
correcting non-compliance to the DTD's subscribed to (at least in
theory) by a vast majority of the HTML community.
Though all of your points may have factual basis, they don't address the
purpose of validation. Just because one can get away with errors
because "browsers will arbitrarily and unpredictably patch [them] up"
doesn't eliminate the value of identifying them at inception. Otherwise
what happens when browsers "arbitrarily and unpredictably" change their
error tolerance and compliance at some future date?
I could get away with not spell checking because most of my errors would
be easily mentally "patched up" by the (visual) end user, but what about
the mechanical renderer that creates phonetic phrases based on an
accepted set of rules (i.e. U.S. English spelling and grammar)?
We can debate the logic of the rules, and lobby to change them, but we
should not "arbitrarily and unpredictably" disregard the ones we
disagree with or the results will be even more "arbitrary and
unpredictable." To put it another way if my document is valid I can
reasonably anticipate how most renderers will interpret it, even if they
are wrong, but if my document is non-compliant the only insurance I have
is to check it against all known renderers.
We could easily get ourselves into a "Which came first the chicken or
the egg?" situation. i.e. Many of the common rendering engines
interpret the rules differently, so I don't need to be diligent in my
HTML./ Many HTML coders are not diligent, so I have little reason to
make my rendering engine fully compliant.
Back to the original point. Is it better to create documents that are
compliant, and then compensate for known UI errors, or better to adopt
their errors, and hope they never correct them?
Per dictionary.reference.com, the verb render means "to cause to be or
become" or "to translate into another language" Therefore Firefox will
render a document as a window for display on a computer, just like an
aural "browser" will render a document by translating an inherently
visual document into an audio "presentation" and search engines render a
document as indexable data.
therefore your statement "Documents are supposed to be valid not just
for rendering..." can become "Documents are supposed to be valid for
predictable rendering."
