Re: trying to achieve Level Triple-A conformance

On 2009-08-24, William Gill <nospam@xxxxxxxxxxxxxx> wrote:
Ben C wrote:
But, browsers will arbitrarily and unpredictably patch up some but not
all invalid HTML. Some things (links and forms mainly) don't only affect
rendering but also behaviour.
Ben,

I'm not sure if you are supporting or contradicting what I said, but the

Contradicting because I think you said something like an invalid site
will almost certainly render incorrectly.

That's not true. Browsers don't care about an awful lot of the things
that the HTML DTD requires.

But I still think it's worth validating, because it catches other errors
(accidentally unclosed tags mostly) upstream, so that you can have a
slightly warm feeling about uses for the document other than displaying
it in a browser, and because invalid HTML will cause a few surprises in
the way browsers occasionally do decide to repair it for you.

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.

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.

Yes but note that none of the main browsers (Firefox, Opera, Konqueror)
base their rendering engines on the HTML DTD. They base it on CSS specs
instead, which do not have any validity requirements on what you can
nest inside what. Anything goes: you can put a something that's display:
table-cell directly inside something that's display: inline, and it's
well-defined what happens (you get a few anonymous boxes basically).

All they use the doctype for is quirks-mode switching and as some basis
for the arbitrary way they patch up some but not all invalid HTML (put a
TD inside a SPAN and browsers will re-arrange it in unpredictable ways).

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"

No, I meant that was a bad thing. The errors the browser leaves alone
are less of a problem. Nobody likes arbitrary and unspecified behaviour,
so this a reason to validate.

Another can of worms is HTML presentational attributes-- there are many
more in common use that work in most browsers than are in the HTML 4
spec, and which are therefore best avoided. The validator catches those.

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?

Quite so.

[...]
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?

Of course the former.

Documents are supposed to be valid not just for rendering but also for
search engines and for audio rendering/other processing of the abstract
document. But the former has a whole industry built around it which
decoys the concerns of commercial operations and the latter is mostly a
pipe dream.

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."

When I say rendering I mean visual rendering.
.

Relevant Pages

  • Re: Ebay - what a heap of crap
    ... IE has a different way of rendering ... the html page than other browsers, ... how about using an alternative auction website... ...
    (uk.rec.motorcycles)
  • Re: safari rendering bug: site display not correct
    ... > The problem there is not Safari, it's your HTML. ... > and you cannot reasonably expect a specific rendering. ... invalid elements and failure to close inline elements (and either ...
    (comp.sys.mac.apps)
  • Re: How can I prevent spaces between tags being rendered?
    ... By not embedding whitespace (spaces or linebreaks, ... Whatever the rules for rendering HTML & CSS say, ... Remember that you can place whitespace _inside_ tags quite easily, ...
    (comp.infosystems.www.authoring.stylesheets)
  • Re: shopping for an HTML editor
    ... what pages will look like in browsers that use the exact same rendering ... engine as the compose tool. ... If you understand that html is only a *suggestion* to the browser on how ...
    (Debian-User)
  • Re: for those that think jpgs are "safe"
    ... HTML, and simply use Javascript instead of VBScript, then it would ... >> really HTML will render the page as HTML in Internet Explorer, ... >> but this in itself is not a security vulnerability. ... Internet Explorer rendering what's named as an JPEG as something ...
    (alt.computer.security)
Loading