[Bug 10068] Suggest making noscript obsolete but conforming

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





--- Comment #67 from Lee Kowalkowski <lee.kowalkowski@googlemail.com>  2010-08-25 20:49:34 ---
(In reply to comment #66)
> I turned off JS and tested about 20 or so games. None of them used noscript.

Gosh, the first one I looked at did use noscript: http://www.travians.com/, and
the third one http://www.rebelideas.co.uk/games/invamars/ is using noscript to
redirect to the system requirements (which unfortunately resulted in a 404!),
this can't be done using PE.

> JavaScript games are an edge case. 

Games were not the case, they were the example, the case is when an author, for
whatever reason, chooses to do anything that is dependant on JS, not just
games, without fallback.  Some people develop for specific platforms only, in
many areas of computing, it's not a crime, we cannot force them provide a
non-JS alternative, but if they did want to, I'd insist they use PE.

> Even for these edge cases, I provided a
> solution that is more elegant--you provide a intro page that has rules,
> requirements, etc and then include a link to the game. If people link directly
> to the game, so what?

So what?  It would be confusing, social bookmarking will inevitably bypass this
good intention, users will have not a clue what JavaScript is anyway, so
they'll just try it all the same, such users just need a little message to
assure them the page isn't going to spring to life any time soon, so not to
bother waiting.

> And yes, you could be
> using an old Windows 98 machine that actually shows the change taking place,
> but you know, I imagine the people using the Windows 98 machine have worst
> problems.

The cause is not usually that the client is under-performing, but usually that
PE has been implemented imperfectly.  E.g. when such scripts are triggered on
the body onload event which won't fire until all the page's artefacts have
finished downloading, or general domready bottlenecks.  

There are ways around this, such as inline script immediately after the
fallback content, or script in the head to add a class name to the HTML element
so it can be hidden in CSS upfront (CSS support permitting) but even that is
unnecessary, just use noscript!  

I'm not really all that bothered about the rearrangement of pages whilst they
load, that has become quite usual these days, especially with page contents
coming from multiple sources.  I'm just not in agreement that we should use PE
merely for the sake of it.  PE only provides a benefit when the fallback is
also functional, allowing the user to carry out their task despite incomplete
capabilities.  If there is no such benefit, there's no advantage to be gained
by using PE.

> We could take this to an email list
> and try to compromise, but this really isn't a compromise situation: either we
> deprecate noscript, or we don't. There really isn't a lot of give. 

There isn't?  My ideal situation would be that the noscript section give
guidance as to how to use it appropriately, it already does, but if it
explicitly advised that these days it's only really suitable for fallback
content and not to duplicate functionality, I think that's reasonable. 
Although it's not really the job of a specification to describe the process of
writing maintainable code.

-- 
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, 25 August 2010 20:49:37 UTC