[whatwg] several messages about <noscript>
Ian Hickson
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[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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list