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

[Bug 10068] Suggest making noscript obsolete but conforming

From: <bugzilla@jessica.w3.org>
Date: Thu, 08 Jul 2010 09:18:28 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1OWnFU-0002x1-JJ@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068





--- Comment #24 from Lee Kowalkowski <lee.kowalkowski@googlemail.com>  2010-07-08 09:18:26 ---
(In reply to comment #21)
> Could you provide an example of where noscript is beneficial, couldn't have
> been achieved using any other technique, and is robust? 

Did you find anything wrong with my two?  

Beneficial: Users without JavaScript receive guidance about closing windows or
printing.

Couldn't be achieved using any other technique: This is assuming any other way
would be preferable, at any cost.  Just because other ways are possible,
doesn't mean they're automatically better.  I'm not going to write JS to
replace fallback content, there's no point.  Noscript already provides what I
want to acheive.

Robust: Poor-proxy-proof? That might be your requirement, but I don't see why
one should be bending-over-backwards for poor proxies to be frank.  It #1 sets
a precedent and #2 is fixing a problem in the wrong place.  In the sense that
the user can still print or close a window, it's robust, because it's just
fallback content, not functionality.

> The noscript element was well-intended, but in practice,
> hasn't worked very well. 

The noscript element works very well, too well.  It's just not being used very
well.  This is not the same thing.  I don't like it when people use a flathead
screwdriver on a cross-drive screw.  Confiscating their flat-head screwdrivers
isn't the solution, education is, because despite the growing pouplarity of
cross-head screws, a flat-head screwdriver is sometimes required.

> Keeping it isn't going to make web pages more robust
> and work when scripting isn't available. 

Neither will removing it.  You need education for that, I love education,
having the examples in the spec of appropriate noscript use, and not for
functional graceful degredation would be a good thing.

> Deprecating it (or whatever the HTML5
> equivalent is) will at least make those that care look at other techniques to
> ensure their pages do work when scripting isn't available, which is what we
> ultimately want to happen. 

I want that too, but sometimes there is no functional fallback.  As a user who
is still stuck with IE6 at work, I'm afraid this is just not happening, fewer
and fewer sites are staying functional over time.  Some are actively excluding
IE6, yes, they wave the progressive enhancement banner when it suits, but even
they have their limits.  I suppose it just sucks to be me.

> The same cannot be said for keeping noscript, as it
> encourages people to think in terms of graceful degradation (except not very
> gracefully).

It's the encouragement that you should challenge then, isn't it?  I don't view
noscript in terms of graceful degradation, but absolute degradation, a last
resort.  

Most real-world uses of the alt attribute are abysmal, nobody is suggesting we
deprecate the alt attribute.  Everybody is advocating providing guidance and
enducation.

> If you have use-cases for noscript that are robust and couldn't be achieved by
> any other method, then I might understand your argument to keep it.

Well, if you insist on the "couldn't be achieved by any other method" clause,
you're onto a winner there.  I personally see no benefit on insisting on such
clauses.  Especially when the "any other method" might be just a waste of
effort because we already have noscript which does what the author wants.

-- 
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 Thursday, 8 July 2010 09:18:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:51 UTC