[whatwg] several messages about <noscript>
ian at hixie.ch
Sat Apr 12 00:25:48 PDT 2008
On Sun, 14 Nov 2004, Anne van Kesteren wrote:
> I was wondering if the WHATWG is going to redefine how NOSCRIPT
> 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, how should content that
> isn't rendered be treated?
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:
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>
> 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
> 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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg