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: Wed, 07 Jul 2010 15:05:39 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1OWWBv-0006nc-BC@jessica.w3.org>

--- Comment #11 from Lee Kowalkowski <lee.kowalkowski@googlemail.com>  2010-07-07 15:05:38 ---
(In reply to comment #6)
> Using noscript to say, "Your browser does not support JavaScript" is actually
> counter to progressive enhancement. 

Absolutely, but if an author is not interested in providing non-JavaScript
support (suppose it's a game and a client-server non-JS fallback is just not
viable), but the author is considerate and thinks it important to offer an
explanation to visitors that they require JavaScript in order to play.  That is
all the fallback is going to say, via noscript, or crude progressive
enhancement, nothing is going to change that, there are always going to be some
instances where the non-JavaScript fallback is zero functionality.  We should
be grateful of any fallback at all. 

> You mentioned about saying something like "you can use the print facility..."
> That a person can use the browser print facility is a given, whether the page
> has JS enabled print or not. They don't need to have text providing this info.

I agree, but I have non-minimalist clients that request "print this page" icons
in their pages, they like them, they consider them to be user-friendly.  They
consider the possibility that their users do not know about pressing CTRL+P or
where to find their print operation in their browser's menu.  As most browser
users these days have no reason to interact with their browser menus, some
never do, some are too afraid to, petrified.  But they're comfortable picking
up their phones and increasing demand on call centres.  For some clients, this
is a real problem, they don't want to spend time educating users when most
users can be given a nice icon that will work.

> And if JS is disabled, I doubt we'll have popup windows that need to display a
> close button. 

There's the target attribute, of course, but the close window link I had in
mind appears on the logout page of a secure application.  Again the browser
provides its own close button, but some clients insist they need to instruct
their employees to close the window, and the javascript link is added as a
user-friendly measure.  When JavaScript is not available, there is no link,
(because of progressive enhancement) but my client wants instructional text in
its place.  

I'm not going to put the instructional text in an inappropriate place then
progressively enhance it away (anywhere outside of a noscript element would be
inappropriate, because that content is also available to JavaScript enabled
browsers).  What a waste of code - I can't think of a reason to use any other
technique when noscript fits the bill.

> I just can't for the life of me think of any good reason for noscript, but I
> can think of a whole lot of reasons why it needs to go.

Well I've given two, so don't exhaust yourself!  There are many instances when
noscript is inappropriate, for sure, but it's not noscript's fault.  Saying
something should be removed because it can (and normally is) inappropriately
used doesn't address the real issue.  Poor craftsmanship and design is the
issue, I see it often, absolutely there's a lot of abuse, they drive me insane
too, but why should the tool get the blame?  For making it too easy?  I don't
like that logic.

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 Wednesday, 7 July 2010 15:05:41 UTC

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