Bug 21092 - Tables with display:inline don't render as expected in strict mode
Summary: Tables with display:inline don't render as expected in strict mode
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tables (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: HasReduction
Depends on:
Blocks: 125640
  Show dependency treegraph
 
Reported: 2008-09-25 00:41 PDT by gmtfn
Modified: 2022-09-20 06:56 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description gmtfn 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>
Comment 1 sachin Puranik 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.
Comment 2 Alexey Proskuryakov 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.
Comment 3 gmtfn 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 :(
Comment 4 gmtfn 2010-03-15 21:59:07 PDT
this bug may be related to one described in bug 23008
Comment 5 gmtfn 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
Comment 6 Ahmad Saleem 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!