W3C home > Mailing lists > Public > www-validator@w3.org > July 2003

RE: http-equiv="refresh" redirects ignored in markup validator

From: Lars Holst <lholst@robotics.lu.se>
Date: Tue, 29 Jul 2003 11:03:16 +0200
To: <www-validator@w3.org>
Cc: "Terje Bless" <link@pobox.com>, <kynn@idyllmtn.com>, <l.wood@eim.surrey.ac.uk>, <P.Taylor@Rhul.Ac.Uk>, <ot@w3.org>
Message-ID: <HAEBILFEMDCHAJHJBPAICEMDCIAA.lholst@robotics.lu.se>

Thanks a lot to everyone who responded. Great stuff. I'm replying to all of
you in one go, so as to shave a few bytes off this thread:

Lloyd, Philip and Terje: you provided exactly the kind of information I was
after. Thanks very much.

Ideally, Terje's post, being the most detailed, should be provided in its
entirety as a pointer in conjunction with the validator error message,
provided of course that the validator can recognize that a refresh has taken
place. In line with the contextual validator tips I suggested in another
<http://lists.w3.org/Archives/Public/www-validator/2003Jun/0095.html>, the
error message could also link to a helpful explanation of the proper use of
DOCTYPE, since both issues could be probable causes of the error here, and
then leave it to the developer to decide what the problem is in his or her
particular case.

In any case, there needs to be a basic understanding here that
meta-refreshes are commonly used. One of the web hosts I'm dealing with (one
of Sweden's largest) even advised me to do it this way. So if the aim is to
promote best practices to the masses rather than just to an elite group of
professional developers, something needs to be done.

Kynn wrote:
>I'm afraid I don't understand why your ignorance becomes my problem.
>It's a shame you don't know, but I would ascribe it to a deficiency in
>your experience of learning Web development.  You should really have
>been taught (by instructor, by book, by tutorial, etc.) that
>a meta-refresh is a poor way to send people from one address to another.

Kynn, don't be afraid. I never suggested it was "your problem". What I did
say was that an explanation or a link would be helpful. The rest is your own
interpretation. If I may offer you some constructive feedback, I think your
reply would have benefited from avoiding language such as "ignorance",
"shame", and "should". At least I would have appreciated it more that way.
FYI, I have been an "ignorant" but happy and self-taught amateur web
developer for four years now, without ever knowing how evil meta-refreshes
are when used as in this particular case. So it's not that big a deal,
really. But thanks for the Google link!

This does (implicitly) bring up an interesting question though:

Should the validator service assume a certain level of knowledge on behalf
of the developer? Certainly so. Should it exclude those who don't have that
knowledge rather than trying to help them become better developers?
Certainly not. And the same should go for posts to this forum.

>There are many good reasons why it is a good idea to do this using a HTTP
>Redirect, but I'm afraid that discussion would be somewhat out of scope for
>this forum. There are however several excellent forums where it could be
>brought up (check the comp.infosystems.www.authoring.* hierarchy on USENET
>one example).

Thanks Terje. I'm all for respecting mailing list policies, and I understand
that this is not the right place to discuss the pros and cons of the various
methods. I would just like to note that if the link Olivier provided had
explained what is so bad about meta-refreshes in the first place, I would
have been more motivated to find out about the better method for myself.

>Kynn is very much right that you need to read up a little on the
>involved. A casual web author does not usaully need to know such things, as
>you say, but I'm afraid the effect you are after falls somewhat outside the
>"casual" bracket and moves into sufficiently advanced territory that some
>reading is required.

I agree. I consider myself well beyond the casual author, but I'm not a
professional developer either. I do this in my spare time, and there's
simply no time to learn all the necessary skills involved. And I'm not
alone. This is something the W3C (and Kynn) would need to be a bit more
understanding about.

I have previously posted here suggesting that the validator provide links
related to the type of error message. This would keep people from having to
turn elsewhere in search of this information.

>If the page Olivier pointed you at is not sufficient then that is a
>shortcoming that we acknowledge, and we should seek to remedy that by
>improving the resource (if you have suggestions then please do let us

It is not sufficient. But I am aware of the manpower situation at W3C, and
with that in mind I think you are all doing a great job.

I am suggesting one thing though: a short write-up or a link to a page
explaining *why* refreshes are bad, and *how* to do it the proper way. To
many less-skilled developers (like myself) it seems to work fine, is
cross-browser compatible, easily implemented and doesn't break the back
button. So the key here is to give a good motivation and a brief note
explaining that the solution will be server dependant (as opposed to the
refresh). As Lloyd argued, the W3C cannot be expected to provide detailed
information on this, but most developers (even ignorant ones such as myself
:) are probably smart enough to figure out the rest by themselves.


I just noticed Olivier's latest message and update of the "reback" page
The page now features a good motivation for using http redirects instead of
meta-refreshes, while at the same time informing the reader that the actual
setup will depend on the server. All of a sudden the links make more sense,
particularly with the updated Apache link. Excellent! This is a great
improvement, and more or less what I was after.

Now, if this information could just be made contextual in regard to the
validator output it would go a long way in educating other developers like

Thanks for listening and sorry for the lengthy post,
Received on Tuesday, 29 July 2003 05:20:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:38 UTC