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: Tue, 24 Aug 2010 14:02:29 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Onu57-0008W1-HM@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068





--- Comment #61 from Shelley Powers <shelleyp@burningbird.net>  2010-08-24 14:02:28 ---
(In reply to comment #60)
> (In reply to comment #59)
> > There are very distinct differences between deprecating something and making
> > something immediately obsolete.
> 
> It says, "suggest making noscript obsolete but conforming", I don't see how
> those are compatible then.
> 

Please read my note earlier about why the title says what it says. 

> > As such, it's
> > primitive, and used too frequently to provide annoying messages such as, "You
> > don't have JavaScript turned on. Go away."
> 
> This is annoying when the JS functionality can be easily implemented in HTML or
> on the server, but if this is not viable (e.g. arcade games).  Then the only
> option you have is to tell the user they'll need JavaScript if they'd like to
> use the feature.
>

Certainly shouldn't use noscript for this. There should be an intro page that
describes the game, the rules, and what you need to have to play. 

> If your issue is that the NOSCRIPT element is used too frequently to provide
> this message, whilst I agree this is probably the case, I don't see how not
> having NOSCRIPT would improve it.
> 
> You're treating a technique as a scapegoat.  If it was commonplace for sites to
> provide such annoying messages as a default and use progressive enhancement to
> enable everything, would such messages suck less?  No.  Would PE start to get a
> bad reputation and people advocate that it must not be used?  I hope not.  Is
> the overall user experience any better just because PE was used?  Of course
> not.
> 

We could say the same about font, or any other presentational attribute, can't
we? After all, when we deprecated these items, we were making the techniques
into a scapegoat. Weren't we?

> > Deprecating noscript is saying that every instance of its use has an
> > alternative, better approach. 
> > I bet, if we knew the underlying reasons -- the use cases, you mentioned
> > earlier-- for the use of noscript, in each and every case, we could find an
> > alternative that isn't dependent on noscript.
> 
> Just because it is possible to use PE to upgrade away from the annoying
> message, is no justification for doing so.  Let's face it, using PE from a
> non-functional starting point is just not the spirit of progressive
> enhancement, because there's nothing progressive about it at all.
>

No justification for doing so? In other words, we should defend crappy
techniques, and sloppy coding? Creating unusable web pages that perform poorly? 

Progressive enhancement is a starting point. It is a design principle. It is a
philosophy, a technique, and an approach to building web pages. You can't get
more "starting point" then this.


> Insisting that if something is possible to do using PE then it must be, is
> going to lead to same abuse of PE that NOSCRIPT receives, or lead people to
> realise that it wasn't NOSCRIPT that was bad after all, it was the web page
> developers.
>

Sorry, you really lost me here. 

> > Interestingly enough, the proposal to keep noscript should probably be
> > asked for, first, because the hypothesis behind its deprecation is that there
> > is an alternative approach for every use case provided. 
> 
> I don't understand this logic.  Why do we need a proposal to keep something?
>

Well, they don't have to provide any. Which means that the change proposal
probably is accepted by default. 

> There are probably alternatives to every use case for toasters or the
> ball-point pen, people should definitely not use them.

What?

-- 
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 Tuesday, 24 August 2010 14:02:32 UTC

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