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

Sun Jan 1 11:12:19 PST 2006

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

------- Additional Comments From camillo.lists at gmail.com  2006-01-01 11:12 -------
(In reply to comment #7)
> 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.

I tested Firefox 1.5 with an XHTML+SVG document, and indeed it seems to give precedence to the 
Content-Type (the SVG is not visible when the content-type is text/html, which suggests that it's using 
the HTML parser, that has no support for namespaces).

However, I can give you something better than the example of another browser: the XHTML 1.0 
standard _itself_, which is an XHTML 1.0 Strict document, is served as text/html:

$ curl -I 'http://www.w3.org/TR/xhtml1/'
HTTP/1.1 200 OK
Date: Sun, 01 Jan 2006 18:30:23 GMT
Server: Apache/1.3.33 (Unix) PHP/4.3.10
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Cache-Control: max-age=21600
Expires: Mon, 02 Jan 2006 00:30:23 GMT
Last-Modified: Thu, 01 Aug 2002 13:56:02 GMT
ETag: "3d493df2"
Accept-Ranges: bytes
Content-Length: 71514
Content-Type: text/html; charset=utf-8

Surely the people who wrote the XHTML standard would know how to serve it properly. :-)
This example strongly suggests that both Firefox and Safari (and any other browsers that do the same 
thing) are in error, and the doctype declaration should take precedence over the Content-Type.

> 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.

Honestly, I don't think anyone is writing an XHTML doctype declaration and relying on it being ignored. 
:-)
But if you want to be forgiving, I have no problem with that. The problem is that your forgiveness is 
currently misdirected: you are accepting things that are invalid, and rejecting things which are perfectly 
valid.

> 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.

And that's exactly the problem: you shouldn't rely on the Content-Type when it's explicitly contradicted 
by the doctype. Now, if the Content-Type was image/jpeg, I'd understand assuming that it is correct 
and not looking for a doctype. But when parsing text/html, you have to read and parse the doctype 
anyway, so why not listen to it?

> 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.

But the idea was not to have all browsers treat is as HTML. The idea was to have modern browsers treat 
is as what it is, ie XHTML, and let old browsers attempt to parse it as HTML (which often gives 
acceptable results). And the W3C itself seems to think that there is nothing wrong with serving XHTML 
as text/html, as shown above. After all, isn't XHTML 1.0 the legitimate successor to HTML 4?

> 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.

Thank you for that, and also for taking the time to discuss this issue with me. I look forward to hearing 
any clarifications that other WebKit developers will want to give.

-- 
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.