W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Validation

From: Eduard Pascual <herenvardo@gmail.com>
Date: Mon, 20 Jul 2009 23:12:03 +0200
Message-ID: <6ea53250907201412h2f364399s3110f9656ab372bb@mail.gmail.com>
On Mon, Jul 20, 2009 at 10:27 PM, <Darxus at chaosreigns.com> wrote:
>
> On 07/20, Nils Dagsson Moskopp wrote:
> > Uh-okay. What could "various means" be ?
>
> Something like:
>
> <object src="image.svg">
> <img src="image.png">
> </object>
>
> > Why not use a HTML7 and a HTML9 validator in this case ? The HTML 7
> > validator could check all pages and report those that aren't valid HTML
> > 7. Those pages could then put onto a list that is checked by the HTML 9
> > validator.
>
> Because I don't want to have to tell the validator which pages are HTML7
> and which pages are HTML9, I want it to figure it out automatically.

You don't have to tell the validator which version is each page. All
the "previous knowledge" included in the setup Nils posted would be
"some pages are HTML7, and some are HTML9"; then you just
feed/send/pipe/whatever all pages to the HTML7 validator: since HTML9
would be a superset of 7, everything that passes this validation is
valid as both HTML7 and HTML9. Then, based on the result, failed pages
would be sent to the HTML9 validator: if they pass, they are HTML9
with features not included in 7; otherwise they are just invalid.
Although it may depend from the specifics of the validation software
used, automating this sequence would be easy on the general case, and
trivial on the best scenario.

Browsers are built incrementally. For example, IE10 is very likely to
render properly any page that IE9 had rendered properly (plus some
that IE9 couldn't handle). And IE9 will handle any page that IE8
handles (plus some that are too much for IE8), just like IE8 handles
any page that IE7 (in addition to those that use CSS2 features not
supported by IE7), and IE7 renders all the stuff that IE6 renders, and
so on... The same is true for any other browser sequence: Firefox3
handles all pages that Firefox2 did; and the later included all those
pages that rendered properly in FF1. More on the same with Opera,
Safari, Konkeror, and so on (Chrome isn't too relevant here because
it's quite young). The only problem could happen if, for example, I
(or someone else) built a new browser, only with HTML5 on mind, when
trying to open an HTML4 (or earlier) page; but the HTML5 spec already
addresses this: to be compliant a browser must treat any valid input
in a well-defined way; but it also must treat invalid input in a
well-defined way; which is actually defined to make HTML5-compliant
browsers render old and invalid content quite like current browsers
do.

Thus, if after HTML5 some features are deprecated (just like <font>
has been removed from the HTML specs), there will be pages using those
features that will not be valid HTML6, but HTML6 will still define
exactly what browsers are expected to do with them.

It seems that you worry about validation. Actually, there is some
reason to worry: many HTML4 Transitional pages (namely, those that use
<font> or other obsolete aberrations) will be reported as invalid when
processed by an HTML5 (or later) validator. So you should actually
worry about this; but not complain, because it is the best thing a
validator can do, warning you that you are using something (like
<font>) that you shouldn't be using.
Now, don't try to argue "using <font> (or some other obsolete tag)
should be Ok, because it's valid on HTML4": on HTML4 these things are
already *deprecated*. Every time you see that word on the HTML4 spec,
read it as an apologize from W3C, just like saying "we should have
never added this to HTML; now we regret it and it shouldn't be used".
Of course, a lot of legacy content will no longer validate with HTML5
validators; but where is the issue? It will still render. After all,
no one would expect Don Quixote or Hamlet to be "valid" according to
modern Spanish and English rules, respectivelly, but people who know
either language are still able to read them. This is an inherent part
of language evolution; and hence is a needed side-effect for evolving
HTML. And we need to evolve HTML, becuase the current standard is over
a decade old, and is falling short to the web's needs every now and
then.

Just my PoV anyway.

Regards,
Eduard Pascual
Received on Monday, 20 July 2009 14:12:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC