Assignee: attinasi → harishd
Status: UNCONFIRMED → NEW
Component: Layout → Parser
Ever confirmed: true
OS: Windows ME → All
QA Contact: petersen → moied
Hardware: PC → All
You have a SCRIPT within a NOSCRIPT!. What are you trying to do here? Is there a real web site to this problem? And why should this be considered for mozilla 1.0?
There are several apparent issues here. HTML 4.01 S18.3.1 says "The NOSCRIPT element allows authors to provide alternate content when a script is not executed. The content of a NOSCRIPT element should only be rendered by a script-aware user agent in the following cases: * The user agent is configured not to evaluate scripts. * The user agent doesn't support a scripting language invoked by a SCRIPT element earlier in the document." The second case is an issue here. Just because Mozilla supports SCRIPT doesn't automatically mean that NOSCRIPT should not be displayed. Specification says that it should be displayed if "the user agent doesn't support a scripting language invoked by a SCRIPT element earlier in the document." So it should be displayed since Mozilla doesn't support text/vbscript. There is a problem, though. The specification is quite general and doesn't exactly account for the fact that different scripts might be used in different places. Logically, a NOSCRIPT should be displayed only after the last unsupported SCRIPT, but not after another successful SCRIPT. And finally, the third issue is that people might want to have alternate scripts embedded in the case that other script types are not supported. Suppose one script gets the job done better than the other (in certain browsers), but we want as much compatibility as possible. This would logically mean allowing and parsing SCRIPTs inside NOSCRIPTs. (It would also mean NOSCRIPTs inside SCRIPTs inside NOSCRIPTs.. etc.) Perhaps we need three bugs for this one. XHTML didn't change this aspect of HTML4.01 It should be noted that the testcase is valid XHTML (and would be valid HTML). While such cases may not be widely deployed, it is because previous browser support of such things does not exist (to my knowledge) but such things would be very useful to be able to do.
"(It would also mean NOSCRIPTs inside SCRIPTs inside NOSCRIPTs.. etc.)" should read: (It would also mean NOSCRIPTs inside NOSCRIPTs inside NOSCRIPTs.. etc.)
>The second case is an issue here. Just because Mozilla supports SCRIPT doesn't >automatically mean that NOSCRIPT should not be displayed. Specification says >that it should be displayed if "the user agent doesn't support a scripting >language invoked by a SCRIPT element earlier in the document." So it should be >displayed since Mozilla doesn't support text/vbscript. This sounds like a valid argument. Let me think about this a bit more.
May be we should be supporting this but it ain't going to happen in the 1.0 time frame.
Target Milestone: --- → Future
I may be repeating what someone already said, but the (ideal) accessible document would contain a <noscript> immediately following each <script> element. So the right thing to do is display the content of <noscript> if and only if the <script> element which immediately proceeds it cannot be interpreted.
To reaffirm something I meant to say earlier on: I doubt anyone is ever going to support a nested NOSCRIPT situation like in the example. There should neither be a SCRIPT nor another NOSCRIPT inside there. That would be a nice solution to cross-browser compatibility, but it's too difficult to implement, and it's simple enough to write browser-dependency into your scripts.
Even without nesting <script> tags the behaviour is buggy, e.g. <script language="VBScript" type="text/vbscript"> ' <![CDATA[ document.write "Browser: " document.write clientInformation.appName document.write "<br />" document.write "Version: " document.write clientInformation.appVersion ' ]]> </script> <noscript> clientInformation is only available in Internet Explorer (although you could of course use the navigator property :-)) </noscript> should display the <noscript> content (and does on Opera but not on Mozilla 1.5)
*** Bug 241871 has been marked as a duplicate of this bug. ***
Assignee: harishd → parser
QA Contact: moied
Regarding comment 11. Opera will keep the "default scripting language" that way given that it is now more or less mendated by HTML5. Regarding what Opera does, here are some testcases (they have been written so that Opera's implementation passes each of them): <http://annevankesteren.nl/test/html/noscript/>
Not blocking, but would consider a patch...
As far as I can tell, HTML5 back browser behavior here. Hence, this bug is INVALID.
Can you please link to the text where HTML5 backs the current behavior? (I'm not complaining, I'm just interested)
HTML5 has a concept "Scripting is enabled". It isn't tied to support for particular scripting languages. http://www.whatwg.org/specs/web-apps/current-work/#concept-bc-script The parser copies the scripting enabled/disabled from the Document upon parser creation. http://www.whatwg.org/specs/web-apps/current-work/#scripting-flag The parsing of <noscript> then depends on this flag in the parser. http://www.whatwg.org/specs/web-apps/current-work/#parsing-main-inhead Marking WONTFIX, since one might argue this is valid per HTML4 but we're now tracking HTML5 instead.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.