Summary: | Tables with display:inline don't render as expected in strict mode | ||
---|---|---|---|
Product: | WebKit | Reporter: | gmtfn |
Component: | Tables | Assignee: | Nobody <webkit-unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | Normal | CC: | ahmad.saleem792, ap, bfulgham, sachin.puranik, simon.fraser, zalan |
Priority: | P2 | Keywords: | HasReduction |
Version: | 525.x (Safari 3.1) | ||
Hardware: | All | ||
OS: | All | ||
Bug Depends on: | |||
Bug Blocks: | 125640 |
Description
gmtfn
2008-09-25 00:41:12 PDT
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 :( 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! |