W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > January to March 2008

Re: Parsing of Refresh header/meta http-equiv in mobileOK

From: Sean Owen <srowen@google.com>
Date: Mon, 3 Mar 2008 11:48:16 -0500
Message-ID: <e920a71c0803030848j1e8927b5q32c47fe4cad54237@mail.gmail.com>
To: "Dominique Hazael-Massieux" <dom@w3.org>
Cc: "Jo Rabin" <jrabin@mtld.mobi>, public-bpwg-comments <public-bpwg-comments@w3.org>

Fair point, and I am also not sure there is any official specification
for what goes into "content". My understanding is that it is primarily
supposed to be a number, optionally followed by ";url=[url]" This
seems to be a strong de facto standard, enough that I think we should
specify this, yes. I'm not terribly concerned because I think everyone
reading this will probably reach the same conclusion about what was
meant, but it could and should have been specified.

If I'd written the test, I think I'd have looked for "url=" instead of
"=" alone. I could fix that; it would make the test more picky, and
I'm not sure whether it's good or bad. But it feels a bit more
correct, and maybe serves to clarify what mobileOK Basic meant, here
in the reference implementation, if we look for the longer string.


On Mon, Mar 3, 2008 at 11:38 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:
> Hi,
>  The current test for AutoRefresh is rather vague in how the parsing of
>  the Refresh header (or its markup version) should be done; it talks
>  about "the URI specified as part of the content attribute" which assume
>  there is well-known format for this specification.
>  I think we need to spell out what we assume is going to be parsed; a
>  typical refresh header looks like:
>  <META HTTP-EQUIV=Refresh CONTENT="10; URL=http://example.org/" />
>  but mobileOK doesn't say what to do when there is no number, when there
>  is only a URL, when there is space in this, etc.
>  I think a simple RegExp would fit the bill; the checker currently
>  assumes that anything that goes after the first "=" sign is going to be
>  interpreted as a URL, which might be a bit too encompassing... On the
>  contrary, it doesn't deal with the case where there is only a URL (and
>  no = sign) - which I confess I don't know how browsers react to.
>  Dom
Received on Monday, 3 March 2008 16:48:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:50 UTC