Re: Best Practices in HTML Re: The use of W3C standards in Denmark Part II

Karl,

I guess the gist of what I would be looking for as an author, and as someone
seeking greater W3C standards compliance, would be a "checker" that is not so
compartmentalized (eg only does links) and simply reports all possible errors.

I understand this is a difficult request, but I do think it confuses people
that they run a validator and yet still undetected and common errors remain.
Running separately a validator, and a link checker, and an embedded css
checker, suggests that after a lot of checking, other categories of errors
still exist and it seems to dilute the value of the effort.

The solution could be as simple as define a common program interface that
allows people to integrate checking tools and have one command that verifies a
page using an extensible list of tools, or perhaps verifies an entire web site.
Others could then write additional checkers that share the interface (eg i18n,
wai, or other checkers).
It would also be easier to integrate checking with authoring tools. (A menu
item could launch a thorough check.)

As for your question-
a) list all requirements- my understanding is many of the needed checks are on
todo lists...
I think if a start was made on the list of additional checks people would like
to have, plenty of input would be offered. ;-)

b) example of what a validator should work with- I am not sure I understand the
question.
Perhaps the description above captures the sense of what I would like.
My goal is really not much more than than to identify common errors in pages
with a single tool and not be in the business of collecting multiple tools to
perform different aspects of what might be considered a single task.

c) a list for discussion would be good.
I would like to see 2 types of discussion. Perhaps it should be separate lists.
1) list for more thorough and integrated checking tool, as discussed.

2) a place for people to discuss obstacles to upgrading to more recent
standards or to being fully compliant, and potential workarounds or solutions.
This might help us understand how to eliminate the (perhaps perceived)
obstacles.
For example, I have heard the arguments for why authors shouldn't specify a new
window vs reusing an existing window.
Nevertheless, I prefer to make the choice in my pages and therefore it is an
obstacle to moving from transitional to strict dtd. I'd like to discuss
solutions so I can be strict without giving up something I see as important.

Note, I am not trying to argue this particular point now, on this list. I am
giving an example of issues that a discussion list might be useful to develop
ideas to move people forward more quickly.

hth
tex


Karl Dubost wrote:
> 
> Le 08 mars 2004, à 14:59, Tex Texin a écrit :
> > It could be the philosophy behind the validator has changed, but in
> > Nov. 2002,
> > I reported that the validator did not check for problems such as links
> > to
> > fragments that do not exist. (e.g. <a href="#tex"> with no
> > corresponding id=tex
> > or name=tex in the document).
> > At the time it was stated that it wasn't a priority for the validator
> > to find
> > problems such as this, unless it was covered by the DTD. i.e. strictly
> > speaking
> > it wasn't a validation problem.
> 
> I think "link checker" verifies this type of mistakes: internal links
> of a document
>         http://validator.w3.org/checklink
> 
> Would you be interested to
>         1. make the list of all requirements MUST, MAY, SHOULD, etc included
> in the HTML Spec. (MUST are already done, see my previous message.)
>         2. give an example on what do you think a validator should work with
> such a list. Implementation requirements for the validator to be able
> to detect or warn users.
> 
> It can be a collective  effort of the mailing list. Though I'm not sure
> of the right forum for that? public-qa-dev? www-qa? or here?
> 
> Olivier, what do you think about it?
> 
> --
> Karl Dubost - http://www.w3.org/People/karl/
> W3C Conformance Manager
> *** Be Strict To Be Cool ***
> 
>   -------------------------------------------------------------------------------
>                  Name: PGP.sig
>    PGP.sig       Type: application/pgp-signature
>              Encoding: 7bit
>           Description: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898  mailto:Tex at XenCraft.com
Xen Master         XenCraft           http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

Received on Tuesday, 9 March 2004 12:24:10 UTC