[Bug 10068] Suggest making noscript obsolete but conforming

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





--- Comment #17 from Shelley Powers <shelleyp@burningbird.net>  2010-07-07 15:24:45 ---
(In reply to comment #11)
> (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 don't need JS for this -- if you're creating a game, you're most likely
going to be opening the game in a separate page or space anyway. Before you
provide the link to the game, you're going to tell people what they need.
That's just good commonsense design. 

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

Then they can provide a block of text as default in the page to print the page
using the print facility, and overlay the block with JS or enable it with JS if
JS is detected. 

This is the basis of progressive enhancement.

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

See above -- block of text, close the window, hide or overlay with script. In
fact, just provide the block of text, period. "Close this window when you're
done". 

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

See above.

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

What Gez is saying, and I agree with, is that the use of noscript is inherently
bad by default. It encourages bad behavior, it simplifies bad behavior, it is
used by developers as a way of routing around good development practices.

-- 
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:24:47 UTC