[Webkit-unassigned] [Bug 6314] Unclosed <style> element in <head> makes page completely blank

Sat Dec 31 13:50:03 PST 2005

http://bugzilla.opendarwin.org/show_bug.cgi?id=6314

------- Additional Comments From macdome at opendarwin.org  2005-12-31 13:50 -------
(In reply to comment #6)
> You're assuming too much. ;-)

My appologies. :)  I did assume too much.  And you are correct, there is a real Safari bug here.  We 
should handle an unclosed <style> element better than we do.

> 1) is it wise to ignore the doctype specified inside the file and trust the HTTP content-type instead? 
The 
> doctype declaration is put in by the author, while the content-type is chosen by a webserver which is 
> often misconfigured, as you all know: it seems to me that the former should be considered more 
> reliable.

Unfortunately I'm not familiar enough all the reasons for this decision.  If you could show some other 
browser respecting a <meta> tag over the server's sent Content-Type, I'd be very interested to know.  I 
think you'll find that our behavior here is in line with other browsers.

> 2) The W3C HTML Validator has no complaints about an XML file uploaded with an .html extension, 
or 
> served as text/html: http://validator.w3.org/check?uri=http%3A%2F%2Fbugzilla.opendarwin.org%
> 2Fattachment.cgi%3Fid%3D5400
> I understand that the validator is not the source of all wisdom, but most webmasters will be satisfied 
> once it passes their pages. What am I supposed to tell them? "Go fiddle with your web server's 
settings 
> because Safari thinks your XHTML files are HTML 4.0, even though you put an explicit doctype 
> declaration inside them?"

I think that you'll find that FireFox/IE treats this file as html as well.  If you don't believe me, try putting 
invalid xhtml in it, and watch them not complain (as the xhtml spec would require, were they really 
parsing as xhtml).  Instead I think you'll find that this page is going through thier html parsers and 
parsed with all the forgivingness that the text/html content type requires.

The validator you referenced does correctly identify this as xhtml 1.0.  I don't think it looks at the 
Content-Type: header when doing so.  Safari also handles the page perfectly fine when it's sent with an 
xhtml Content-Type.

> 3) I'm going to go out on a limb here, and I haven't checked the standards recently, but wasn't the 
> XHTML syntax meant to be mostly compatible with HTML? Is it really so crazy to serve XHTML as 
text/
> html, expecting XHTML-compliant browsers to handle it correctly (recognizing it through the 
doctype), 
> and older browsers to make a best effort at rendering it as HTML, instead of deciding to download it 
to 
> disk because it has an unrecognized MIME type?

Yes, it is meant to be compatble.  But not *all* xhtml 1.0 is compatible with HTML.  For example, if you 
check the html 4.01 spec, you'll see that <style>*requires* an end tag.  So this <style> tag w/ a bogus 
"/" attribute, and no end, is invalid html.  Again, Safari should handle it better than we do, but the html 
in invalid.

http://www.w3.org/TR/html4/present/styles.html#h-14.2.3

Perhaps other WebKit hackers who know more about the decision to respect Content-Type over a 
<meta> tag will be able to more fully answer your above questions.  Thanks again for reporting the 
bug.  We'll definitely look into the issue of the unterminated <style> tag not being handled properly by 
our html parser.

-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.