[Webkit-unassigned] [Bug 6314] Unclosed <style> element in <head> makes page completely blank
bugzilla-daemon at opendarwin.org
bugzilla-daemon at opendarwin.org
Sat Dec 31 13:50:03 PST 2005
------- 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?
> 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
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,
> served as text/html: http://validator.w3.org/check?uri=http%3A%2F%2Fbugzilla.opendarwin.org%
> 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
> 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
> 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
> html, expecting XHTML-compliant browsers to handle it correctly (recognizing it through the
> and older browsers to make a best effort at rendering it as HTML, instead of deciding to download it
> 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
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.
More information about the webkit-unassigned