RESOLVED CONFIGURATION CHANGED21092
Tables with display:inline don't render as expected in strict mode 
https://bugs.webkit.org/show_bug.cgi?id=21092
Summary Tables with display:inline don't render as expected in strict mode
gmtfn
Reported 2008-09-25 00:41:12 PDT
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>
Attachments
testcase with doctype (423 bytes, text/html)
2025-01-16 18:10 PST, Karl Dubost 		no flags
Details
testcase without doctype (407 bytes, text/html)
2025-01-16 18:10 PST, Karl Dubost 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
sachin Puranik
Comment 1 2010-01-29 10:08:02 PST
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.
Alexey Proskuryakov
Comment 2 2010-01-29 16:22:48 PST
>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.
gmtfn
Comment 3 2010-03-15 21:11:56 PDT
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 :(
gmtfn
Comment 4 2010-03-15 21:59:07 PDT
this bug may be related to one described in bug 23008
gmtfn
Comment 5 2010-03-15 22:11:52 PDT
Here's what Mozilla people did for the same issue: http://weblogs.mozillazine.org/roc/archives/2005/06/displayinline_a.html
Ahmad Saleem
Comment 6 2022-09-20 06:55:54 PDT
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!
Karl Dubost
Comment 7 2025-01-16 18:10:18 PST
Created attachment 473928 [details] testcase with doctype
Karl Dubost
Comment 8 2025-01-16 18:10:39 PST
Created attachment 473929 [details] testcase without doctype
Karl Dubost
Comment 9 2025-01-16 18:16:44 PST
Both with doctype and without doctype the renderings are very similar. The current test cases do not show any significant differences. Roc blog's post is still readable at https://web.archive.org/web/20060218001756/http://weblogs.mozillazine.org/roc/archives/2005/06/displayinline_a.html I think we can close. If there's a major difference affecting the layout, there is still the possibility to open a new bug.
Note You need to log in before you can comment on or make changes to this bug.