- From: Sean Owen <srowen@google.com>
- Date: Mon, 3 Mar 2008 11:48:16 -0500
- 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. Sean 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