- From: <bugzilla@jessica.w3.org>
- Date: Mon, 23 Aug 2010 21:16:19 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068 --- 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 disabled. > <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: So? > 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