W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2010

[Bug 10068] Suggest making noscript obsolete but conforming

From: <bugzilla@jessica.w3.org>
Date: Mon, 23 Aug 2010 23:13:08 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1OngCS-0001x9-1o@jessica.w3.org>

--- Comment #53 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-08-23 23:13:05 ---
(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.

So precisely the problem that progressive enhancement solves so much better.

> > 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.

Obviously, hence the caveats. Have you tested it?

> > 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.
> > 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.

I don't see how you can judge use-cases without making these sorts of

HTML5 could avoid making such judgements except for feature additions by simply
treating all existing features as conforming; but it doesn't.

> The point is only that <noscript> is a useful, widely used element that does things that
> no other element can do.

"useful" seems to be what HTML5 requires for a feature to be conforming. I
think usefulness can be demonstrated in this case, and have attempted to do so.

"widely used" merely means we need to define how user agents should treat it.

> Declaring it obsolete when it's not is silly and counter productive.

Nobody in this thread would disagree with that, but then Gez's claim is that
"noscript" /is/ obsolete.

> > 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.

It's suggestive, sure. :)

> Bottom line: we shouldn't declare something obsolete that's used by a very large number of important web sites.

Are you saying it should be conforming (as well as specified) even if it's
useless or causes active harm? And if you're not saying that, then why do you
say this the bottom line?

"If browsers don't widely implement a feature, or if authors don't use a
feature, or *if the uses of the feature are inconsequential or fundamentally
wrong or damaging*, then, after due consideration, features will be removed."
(my emphasis)


(Not that anyone's proposing to /remove/ "noscript", just to change its
conformance status.)

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 23:13:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:21 UTC