alanstew wrote:
Thanks for the link, I'll check that out, when I have time. But I
really am curious why Ivo's suggestions are "infinitely better".
Ivo was presented with code that is structurally nonsense, filled with
bogus attributes and deprecated mark-up (and perverse formulations of
that deprecated mark-up); more a sequence of HTML-like mystical
incantations than a hypertext document, and he proposed formally valid
HTML 4 as an alternative.
He also pointed out (as we all do on a regular basis) that javascript:
HREFs cause problems and are completely unnecessary anyway (given that
the oldest browsers in use are version 4 era browsers that support
cancellable onclick attributes on links).
The argument for formally valid HTML is quite simple: A browser
presented with valid HTML can follow a clearly specified series of rules
when creating a corresponding scriptable DOM from that mark-up, so they
produce consistent results. Presented with nonsense HTML the browsers
will make an attempt to error-correct that HTML and build a DOM with the
results. But there are no public standards or specifications for error
correcting, so each browser does it to the best of its abilities, but
inevitably differently. The resulting DOMs are not necessarily
consistent (indeed presented with particular formulations of common
invalid HTML they have been demonstrated to diverge considerably in
structure), and doing anything to provoke browsers into being any more
inconsistent than they already are is asking for trouble.
The javascript HREFs are another known troublemaker. Apart form their
obvious non-functionality when scripting is not supported on the client,
from the point of view of a web browser they represent navigation. And
navigation implies that the current page is finished with and about to
be replaced. Browsers (including IE) take the fact that the current page
is about to be replace as an opportunity to stop maintaining activity on
the current page that is considered costly. Again there are no formal
rules so different browsers behave differently, but following the
activation of a javascript HREF the consequences of the browser getting
the impression that it has been navigated mean that all bets ore off as
to what scriptable activity the browser will still be supporting.
Javascript HREFs were introduced as a kludge that allowed browsers that
had no link onclick event handlers to do things when a link was clicked
that they could not otherwise do. Unfortunately scripting books,
Internet tutorials and the like hang around suggesting particular
practices long after those practices have become outdated and
superfluous. They are now unnecessary, and they have harmful side
effects. Two factors that, in combination, suggest that they should
never be used.
If two ways work, WHY does it MATTER which is used?
Define "work". If one practice is known to provoke problems, while an
alternative avoids them, but an application of the first does not
manifest problems (under the conditions in which it is tested) that does
not render the two equivalent, it just means you got lucky (or are not
testing adequately).
Is this aesthetics, or is there a practical reason why I should
stop doing things the way I've been doing them and spend the
time to learn a different way?
From one point of view the history of the development of programming
practices can be looked upon as the development of techniques for the
management of complexity. Humans are limited in their ability to
perceive complex systems and once complexity gets out of hand chaos
ensues.
Many of the tools used to manage complexity consist of nothing more than
formal disciplines applied to the process of code design and authoring.
They aren't hard and fast rules, or absolute truths, they are tools that
contribute to making it easier to do a difficult task well. And
conscientious programmers don't need much experience to appreciate the
contribution of the application of appropriate formal disciplines to
their work. So they will tent to seek out the disciplines that should be
applied to particular tasks.
In the authoring of HTML one of the obvious disciplines that can be
applied is the creation of documents that conform to the specifications
for HTML. And the results can be directly tested by exposing the
documents to an HTML validator.
As a stage in the development of HTML, validation does not tell you that
the results are good HTML, optimum, ideal or anything beyond that it is
valid, but that does rule out, at a stroke, any and all problems
resulting from invalid HTML. Meaning that if any problems remain you
know to look elsewhere for their cause (and ruling out causes is
normally a huge aid in the solving of problems, because that means that
the problems are less complex than they would be otherwise).
Not trying to start a war, but really,
in my life, I need results not manners,
if you get the way I'm driftin'
Did you get results? Results don't usually prompt questions on
newsgroups. But the application of appropriate formal disciplines to the
process of creation is not about "manners" as such, it is about getting
better quality results, quicker. These concepts don't arise from some
sadistic desire to burden the world with pointless extra tasks, they are
tools, they make life easier, and they are promoted for the benefit of
the people involved.
Richard.
assHelp()" title="Click to get help with