[Bug 10068] Suggest making noscript obsolete but conforming


--- Comment #44 from Adam Barth <w3c@adambarth.com>  2010-08-23 21:16:18 ---
> There may well be good examples of "noscript" use; I'm not sure about Adam's
> examples.

I wasn't making a value judgement.  Those are real-world examples (from
Facebook) of authors using <noscript> to solve problems that they have no other
way of solving.  Claiming something is obsolete or deprecated without giving
authors better tools for solving their problems is waste of time.

> > <noscript><meta http-equiv=refresh content="0; URL=/home.php?_fb_noscript=1"
> > /></noscript>
> Adam, would you mind joining the dots for this one? I can see what this does,
> but what is it for and how is "noscript" helping here?

<noscript> limits the meta refresh to only those situations when script is

>  <noscript><meta http-equiv="X-Frame-Options" content="deny"/></noscript>
>  "X-Frame-Options" is an invalid "http-equiv" value in the current editor's
> draft:


> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv
> But even if it were valid, how does "noscript" help here? Shouldn't
> "X-Frame-Options" always be sent as a real HTTP header?
> http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

That would apply the directive unconditionally.  The problem Facebook is
solving here is that they have a script-based clickjacking defense that seems
to work for them, but they want to be protected even if script is disabled. 
Consequently, they wish to apply the X-Frame-Options directive only when script
is disabled, hence the use of <noscript>.

All this talk of "progressive enhancement using JavaScript" ignore the actual
problems folks use <noscript> to solve.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 23 August 2010 21:16:21 UTC