Bug 21092

Summary:

Tables with display:inline don't render as expected in strict mode

Product:

WebKit

Reporter:

gmtfn

Component:

Tables

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED CONFIGURATION CHANGED

Severity:

Normal

CC:

ahmad.saleem792, ap, bfulgham, karlcow, sachin.puranik, simon.fraser, zalan

Priority:

Keywords:

HasReduction

Version:

525.x (Safari 3.1)

Hardware:

All

OS:

All

Bug Depends on:

Bug Blocks:

125640

Attachments:

Description	Flags
testcase with doctype	none
testcase without doctype	none

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.