Closed
Bug 67899
Opened 24 years ago
Closed 22 years ago
NOSCRIPT element not rendered in XHTML
Categories
(Core :: XML, defect, P2)
Core
XML
Tracking
()
RESOLVED
FIXED
mozilla1.2alpha
People
(Reporter: chrispetersen, Assigned: john)
References
Details
(Keywords: xhtml, Whiteboard: [bae:20011129])
Attachments
(3 files)
Build: 2001020608
Platform: All
Expected result: With JS off in browser, the noscript element should be rendered.
What I got: The noscript content is missing
Steps to reproduce:
1) Turn off JS support in Advanced section of preferences.
2) Load the sample test case.
3) The page is empty.
4) Instead of a empty, the contents of the NOSCRIPT element should appear
(Scripting is disabled so you will see this text).
|
Reporter | |
Comment 1•24 years ago
|
||
|
|
Reporter | |
Comment 2•24 years ago
|
||
Adding xhtml keyword
Keywords: xhtml
Summary: NOSCRIPT element not rendered in XHTML → NOSCRIPT element not rendered in XHTML
|
||
Comment 3•24 years ago
|
||
for me this is the same case as bug 68193.
<noscript> is no block element.
the only error here is that mozilla renders transitional as strict where it
would be okay.
|
|
||
Comment 4•24 years ago
|
||
Harish, you know noscript better than I do so maybe you could take a look...
Really reassigning...
Assignee: heikki → harishd
Mark: You have the weapons to kill this one. So, handing over to you ;)
Assignee: harishd → attinasi
Status: ASSIGNED → NEW
|
||
Comment 9•24 years ago
|
||
the NOSCRIPT { display: whatever; } rule needs to be in the pref stylesheet, and
change from display:none to display:block when JS is disabled.
Another option would be to make a rule like NOSCRIPT {
display:-moz-noscript-pref;} and have that property value evaluate according to
the state of the JS pref. This option is a lot more work...
So, is this really required for mozilla 0.9?
Status: NEW → ASSIGNED
I would like to see it in 0.9 or 0.9.1, doesn't matter which. Or do you know of
an obvious or simple workaround?
|
|
||
Comment 11•24 years ago
|
||
Are there other cases besides when JS is disabled via a pref that we need to
handle? I spoke with Harish about this before but I cannot remember...
If it is just the pref, then this is pretty easy. If there are othere cases not
related to the pref, then it gets a bit more difficult.
Moving to 0.9.1 because I have too many 0.9 bugs right now.
Target Milestone: mozilla0.9 → mozilla0.9.1
|
|
||
Comment 12•24 years ago
|
||
hmm... the current behavior has nothing to do with <noscript> and by the way
mozilla should not handle <noscript> as a block element. for me <noscript> was
always a way to display html constructs if javascript was disabled.
when comparing both testcases you'll see in the second example
<noscript> is surrounded by <p>
in this case when javascript is disabled the text will be displayed.
the problem with both testcases is that doctype is:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
mozilla renders or parses (?) both testcases like
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
and here lies the problem:
when XHTML 1.0 Strict is used following html construct should not display
anything.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<body>
Should not be displayed
</body>
another example where it also should not be displayed(javascript disabled):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<body>
<noscript>Should not be displayed</noscript>
</body>
in XHTML 1.0 Strict it must be surrounded by a block element !! otherwise
it should not be displayed.
mozilla does not handle the doctype correct !!
it renders Transitional as Strict.
something like this construct should display the text:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<body>
Should be displayed
</body>
***
|
|
||
Comment 13•24 years ago
|
||
oops sorry, <noscript> is a block element, and it should be rendered in strict
and transitional when parent element is <body>.
|
|
||
Comment 14•24 years ago
|
||
Currently we do not create a NOSCRIPT frame at all, because it is display-none.
It looks like the content sink checks to see if JS is disabled, and if it is,
then it ignores the NOSCRIPT (eg. avoids opening a container for it) and just
processes the content of the NOSCRIPT normally. If JS is enabled, however, then
the container is opened and the CSS style rules for NOSCRIPT (display:none) kick
in to prevent the contents from being displayed.
The only problems I can see here are:
1) handling of the transitional XHTML doctype results in strict layout mode
2) NOSCRIPT is not being treated as a block when JS is off
I have been told that (1) is already represented by a bug, and I think (2)
should be opened. This bug can then be closed (or it could be updated to become
2). Incidentally, if NOSCRIPT is to be treated as a block when JS is OFF, then
the content sink will need to start creating the NOSCRIPT container, and the
frame construction code wil need to start processing it. Also, we will need to
toggle the display value for NOSCRIPT (I think).
Comments?
|
|
Reporter | |
Comment 15•24 years ago
|
||
Since I realize that N6 handles all xml document as strict, I have updated the
original test case to resolve this problem. A P element has been placed inside
the noscript element.
|
|
Reporter | |
Comment 16•24 years ago
|
||
Here's the bug related to XHTML Transitional being rendered as strict:
http://bugzilla.mozilla.org/show_bug.cgi?id=76912
|
|
||
Comment 17•24 years ago
|
||
Bug 77296 opened for the NOSCRIPT not treated as block problem. Closing this as
INVALID.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
|
|
||
Comment 18•24 years ago
|
||
|
|
||
Comment 19•24 years ago
|
||
OK, the testcase works when it has the (html) extension, but not the (xml)
extension, even though the doctype indicates XHTML...
Reopening...
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
|
|
||
Comment 20•24 years ago
|
||
Updating milestone, priority and severity (and re-accepting)
Severity: major → normal
Status: REOPENED → ASSIGNED
Priority: -- → P2
Target Milestone: mozilla0.9.1 → mozilla1.0
|
||
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla1.2
|
||
Updated•22 years ago
|
QA Contact: petersen → ian
|
Assignee | |
Comment 22•22 years ago
|
||
Will be fixed with bug 77296
|
|
Assignee | |
Comment 23•22 years ago
|
||
*** Bug 199921 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Comment 24•22 years ago
|
||
Fixed with bug 77296.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•