Consider the sample code below. With the DOCTYPE specified, the tables aren't rendered as specified (inline), and backgrounds are ignored. However, removing the DOCTYPE makes browsers that use Webkit (Safari and Google Chrome) render the code as expected -- like all other browsers (Firefox, IE, and Opera) do. I don't know how far reaching this problem is. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <body> <table style="display:inline; background: green; width: 100px;"> <tr><td>inline table 1</td></tr> </table> <table style="display:inline; background: blue; width: 100px;"> <tr><td>inline table 2</td></tr> </table> </body> </html>
Below are my findings for this bug. After DOCTYPE parsing stack flows to void HTMLDocument::determineParseMode(). This decides the parse mode of the document and passes the same to the Style objects which eventually decides the look and feel of the Object. While in HTMLDocument::determineParseMode(). does not find the entry for the given doctype using function findDoctypeEntry(pubIDStr.data(), pubIDStr.length()); So the document parse mode is set as "setParseMode(AlmostStrict);" This inturn affects the style object and changes the output. Not sure if this is the real bug or expected behavior. Can somebody please guide. if this is a valid bug i can try to fix.
>So the document parse mode is set as "setParseMode(AlmostStrict);" When doctype is not in the list, the mode is actually set to strict. I don't know if this bug is valid, but the workaround is obvious - one can just not specify a doctype, and use the quirks mode.
Alexey, in a world in which only Webkit browsers existed, your proposal would be fine. However, in our current world, this would affect users of major browsers, IE and Firefox. When I filed this report, Google Chrome just appeared (in beta version), and I was hoping that this bug would get removed soon. It's been about a year and half, and Chrome has become pretty popular and is gaining market share. A page on my site is f...-up in it. So, I will have to change my code to compensate for this defect in Webkit. So... thanks, guys :(
this bug may be related to one described in bug 23008
Here's what Mozilla people did for the same issue: http://weblogs.mozillazine.org/roc/archives/2005/06/displayinline_a.html
I changed the test case from Comment 01 (with DOCTYPE below): Link - https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10749 Safari 16 and Chrome Canary 108 render this same while Firefox Nightly 108 render it same but it seems the inside "text" is outside more than both other browsers. I don't know whether it is much of concern or is acceptable but just want to highlight latest results. Thanks!