Closed Bug 408702 Opened 17 years ago Closed 17 years ago

Unable to see content on this website (<script src="..." /> in XHTML served as text/html)

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: marcia, Unassigned)

References

()

Details

Seen while testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2. Reported via reporter.mozilla.org.

STR:
1. Visit URL above.

Expected: See some content like I do in Safari
Actual: Only see blank page
Wierd!

This isn't Mac-only (I also see it with the 2007-12-13-05-trunk
Minefield nightly on Windows).

But it does seem to be trunk-only (I don't see it on the branch).

And it's not a new problem -- I see it with the 2007-08-05-04-trunk
Minefield nightly (on OS X).

I've no idea what could be the cause.
OS: Mac OS X → All
Hardware: PC → All
Looking at the page in DOMi I see all of the source after the script tag ends up inside the script.
<script type="text/javascript" src="/js/focus-432.js" defer="defer" />

I'd say Bug 305873.  So this could be a wontfix like Bug 393281.
Blocks: 305873
Wontfix per bug 327796 and bug 162653.  It's blank in IE too, right?
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
The site works in IE7 on XP.  But the source sent is different:
<script type="text/javascript" src="/js/focus-432.js" defer="defer"> </script>

And the site works in the latest minefield nightly when using the IE6 UAstring.  
This is something that used to work, so tech evangelism might be more appropriate.
Sounds like they misinterpreted the "You can send XHTML to Firefox but not to IE" memo.
Mostly wrong.  According to the W3C validator, <script ... /> tags are legal and treated as closed.

It would be nice to see this parsed properly.  <script> .... is not the same as <script />.....
Just note:  This is NOT the same issue as Bug 305873.

That bug dealt with unclosed script tags.  This bug deals with self-closing script tags which should be seen by the browser as being closed.

It is too bad that content which passes the W3C validator is seen as wrong by the FF team.  So much for standards-compliance :-(
1. The shorthand form <script /> is not valid HTML. 
2. Script is not an empty element so the shorthand form is not even valid in XHTML. 
http://www.w3.org/TR/xhtml1/#h-4.3

The validator isn't perfect.  
I have added notes to another bug with a full XHTML document which passes validation and still fails to render on FF3.

The tag in question is:

<script type="text/javascript" language="JavaScript" src="UI/login.js" />

I would expect a <script /> tag with a src attribute to be empty.  Perhaps you can point me to the entry on the DTD which shows that this is not the case?

At any rate it is a shame that we can't rely on the W3C validator to ensure that code works on FF3 :-(  I suppose it is time to write a more public complaint....
Search http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Transitional for "EMPTY".  But I think it's bizarre and un-XML-like of the XHTML spec to allow <script></script> and not <script/> -- my impression was that XML considers the two to be exactly equivalent.  http://mail.python.org/pipermail/python-list/2005-March/312768.html agrees and points out that the section in question is informative, not normative.

Given crowder's recent change to the summary of bug 327796, this is now a dup of bug 327796 (which is also WONTFIX, for the same reasons).
Summary: Unable to see content on this website → Unable to see content on this website (<script src="..." /> in XHTML served as text/html)
Yes, it is a shame if the W3C validator treats your code as XHTML despite a text/html mime type.  It should warn you about that being invalid and/or point out things like self-closing SCRIPT tags where serving as text/html will cause compatibility issues.
You need to log in before you can comment on or make changes to this bug.