petit at petitpub.com
Tue Sep 26 16:50:40 GMT 2006
Andy Skelton wrote:
> On 9/25/06, Andy Staines <andy at yellowswordfish.com> wrote:
>> > What do you mean by "on startup"?
>> bad phrase choice. Initialisation perhaps? I realise this is with
>> every page load but I still don't know everything that's going on in
> This is still pretty vague. This is a WordPress list so I'll assume
> you mean that you want this information available at the "init"
> There is no such information available in core. As I said before,
> browsers never expose this info in the request headers. You have to
> either make the browser do this, or just send both versions of the
> page and write it so that the js code upgrades the non-js HTML.
> If you insist on "knowing" whether the browser can do js, possibly the
> leanest way to accomplish it would be with a plugin that did the
> 1. Check for a cookie named "my_plugin_js_test" or similar.
> 2. If the cookie is set to 'on', the browser probably has js on.
> 3. Else If the cookie is set to 'off', add some js to the page that will:
> a. Set the cookie to 'on' and
> b. Reload the page, returning you to step 1.
> 4. Else the cookie is missing, invalid or expired, so do the following:
> a. Set the cookie to 'off' and
> b. Add the js from step 3 (set 'on', reload)
> If JS is enabled and the cookie is not set to 'on', this program will
> set the cookie 'on' and reload. Otherwise it'll set the cookie to
> 'off' and continue loading.
> See how convoluted that is? I advise against it. :-)
Convoluted indeed, but is points 3 - 3a possible?
That would mean that a user who in good faith did set his/her browser
not to accept cookies,
would be forced to accept them anyway. I would prefere to think not.
More information about the wp-hackers