[whatwg] several messages about <noscript>

[Ian Hickson]

On Sun, 14 Nov 2004, Anne van Kesteren wrote:
>
> I was wondering if the WHATWG is going to redefine how NOSCRIPT[1] 
> works, since the current specification of it is quite difficult to 
> implement. Besides, I don't think it ever was implemented properly.
> 
> Also, brought to my attention by Bugzilla[2], how should content that 
> isn't rendered be treated?
> 
> [1]<http://www.w3.org/TR/1999/REC-html401-19991224/interact/scripts.html#h-18.3.1>
> [2]<https://bugzilla.mozilla.org/show_bug.cgi?id=242298>

As far as I can tell, this is now all pretty much covered. If there are 
any specifics that I've missed, let me know.


On Sun, 29 May 2005, Kornel Lesinski wrote:
> 
> I see there is placeholder for <noscript> in WD, so here is my idea:
> 
> Remove <noscript> element from specification.
> 
> Since browsers support DHTML there is no need for specialized fallback 
> element. Authors can use any element and hide/replace it using scripts.
> 
> This is 100% backwards-compatible, works with all kinds of script types 
> and allows partial fallback for partially working scripts.

On Mon, 30 May 2005, Christian Biesinger wrote:
> 
> That does not work if the user disabled javascript, or if the user agent 
> does not support javascript (lynx, for example).

On Sun, 29 May 2005, theharmonyguy wrote:
>
> And not just Lynx - there are plenty of handheld/phone browsers that are 
> text-only or don't support all the latest features, including script.

On Mon, 30 May 2005, Anne van Kesteren wrote:
> 
> He's correct for a bit though. If you have the following element:
> 
>  <div id="noscript">
>   <p>Foo bar, etc.</p>
>  </div>
> 
> You could easily remove that DIV from the flow using javascript. And 
> when javascript is disabled it would show up. Of course, compared to 
> NOSCRIPT this is suboptimal at best.

On Mon, 30 May 2005, Mikko Rantalainen wrote:
>
> I disagree. The <noscript> element is seldom used for anything else but 
> "this page requires javascript to work". The way I currently create web 
> applications is to first make it work without any scripting and finally 
> write scripts that tweak the final result. Often this tweaking requires 
> removing existing elements or adding a few new ones but it's all doable 
> in every browser I would script for anyway. The rest will get the 
> default noscript version of the page.
>
> If the script is going to add or remove at least one element in any case 
> there's very little extra work to remove the fallback behavior. If we 
> remove the noscript element, the DOM tree will be simpler and therefore 
> a little easier to script for the more complex cases.
> 
> I'd prefer suggesting that the noscript version is the default case (and 
> because it's the default there's no need for an extra element) and any 
> features or behavior added with scripting is optional extra that needs 
> to take care of everything required to "make it work".

On Mon, 30 May 2005, Henri Sivonen wrote:
> 
> I disagree. <noscript> does not tell which script features a script 
> needs. OTOH, the script itself can sniff for required DOM properties and 
> proceed to remove the fallback if all the required properties are 
> present.

On Mon, 30 May 2005, Kornel Lesinski wrote:
> 
> I don't see many real uses for <noscript>. Mostly because <noscript> is 
> very primitive:
> 
> * doesn't work when script-aware browser lacks neccessary DOM or 
> XMLHTTPRequest support.
>
> * doesn't let you reuse its contents, so that's always "wasted" 
> bandwidth (browsers don't put contents of <noscript> in DOM tree)
>
> * doesn't work with multiple script types
> 
> Today most scripting solutions use progressive enchacement and don't 
> need <noscript> at all.
> 
> Decent dynamic menus work by transforming nested lists of links. 
> Maintaince of <noscript> alternative would be wasted effort.
> 
> sFIR and flashObject degrade nicely without <noscript>.
> 
> Actually you don't have to look far - entire WebApps specification is 
> designed this way!

I've left <noscript> conforming in text/html, because while it's true that 
it isn't overly useful these days, it's not especially _harmful_ either, 
and we have to support it anyway, so removing it doesn't gain us much. 
Removing it _would_, however, introduce spurious and annoying conformance 
error messages in legacy content updated to use HTML5 features.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'