[Bug 10068] Suggest making noscript obsolete but conforming

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068





--- Comment #51 from Shelley Powers <shelleyp@burningbird.net>  2010-08-23 22:57:09 ---
(In reply to comment #47)
> >> <noscript> limits the meta refresh to only those situations when script is
> >> disabled.
> > 
> > Obviously. But what actual problem does this solve?
> 
> Redirecting folks who don't have JavaScript turned on to a version of the site
> that works for them.
> 

Neither here nor there in the discussion, but it actually doesn't. I tried it
with JS turned off (the Facebook login page uses the two noscript elements),
and the redirected page is little different than the original page, and the
content isn't displayed. 

> > The Microsoft blog post I cited says: "Send the content as an HTTP Header – the
> > directive is ignored if specified in a META tag". *If* that's accurate (I
> > haven't tested), then Facebook's directive does not work. (I wouldn't be
> > surprised by error in either direction.)
> 
> I think you'll get more accurate results by testing what actually happens then
> by reading a blog post.
> 
> > But - assuming for the sake of discussion it *does* work - is the purpose of
> > attempting to limit "X-Frame-Options" to script-less scenarios to enable the
> > content to be iframed when JS *is* enabled?
> 
> They have some other solution for clickjacking when JS is enabled.  For
> whatever reason, they'd rather use that than X-Frame-Options.  However, they
> still want to use X-Frame-Options in the case when there's no script.
>

Not knowing the Facebook developer's mind, or the purposes, but isn't the whole
point of X-Frame-Options to prevent the clickjacking that scripting wasn't
preventing? In other words, why integrate X-Frame-Options for non-scripting
when it's purpose is for all pages? 

We don't know, and we can't know just from looking at usage.

> > Are they trying to balance integrations options with security concerns or what?
> 
> I don't think you or I should sit in judgement of these decisions.  The point
> is only that <noscript> is a useful, widely used element that does things that
> no other element can do.  Declaring it obsolete when it's not is silly and
> counter productive.
>

Circular argument: the usage demonstrates a use case, and the use case is the
fact that it's being used. 

And I am not asking it to be declared obsolete--I'm asking for it to be
deprecated. 

> > a usage example is not the same as a use case.
> 
> Usage, however, is evidence that the feature solves a problem in a useful way.
> 
> I'm tired of arguing.  Bottom line: we shouldn't declare something obsolete
> that's used by a very large number of important web sites.

Important sites make mistakes, the same as other sites. When Google rolled out
its use of X-Frame-Options, it actually broke some of its functionality, to the
company's embarrassment. 

And who is to say that Facebook will continue its use of noscript. Five months
from now, it may stop using noscript.

-- 
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 22:57:13 UTC