Summary: | Incorrectly indented items in a list (WebKit lacks Firefox <dd> quirk) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Gavin Sherlock <gsherloc> |
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | gsnedders, mitz |
Priority: | P2 | Keywords: | HasReduction |
Version: | 523.x (Safari 3) | ||
Hardware: | Mac | ||
OS: | OS X 10.4 | ||
URL: | http://genome-www5.stanford.edu/help/svd_how_to.shtml#references |
Description
Gavin Sherlock
2007-08-06 12:18:01 PDT
Looks like a difference in handling of misnested tags (<li>.....<dd><li>). The difference lies somewhere else, either CSS or layout. Here is a reduction: data:text/html,<li>a</li><dd><li>b</li></dd> Firefox lays out the two items the same. WebKit indents the second ont. Firefox has this rule in quirk.css: /* Quirk: DD not in DL has text-indent instead of margin (b=5119) */ :not(dl) > dd { display: inline; margin: 0; } There are a few more dl/dd quirks there. Changing the URL's DOCTYPE to <!DOCTYPE HTML> (instead of <!DOCTYPE html PUBLIC>) makes Firefox lay out the list items the same as WebKit. The real problem with the page, though, is that it has a stray <li> somewhere in the middle, and a funny DOCTYPE. FYI , the funny DOCTYPE field was generated by CGI.pm. Go to http://search.cpan.org/src/LDS/CGI.pm-3.29/CGI.pm and search for DOCTYPE to see the offending code (not mine). (In reply to mitz from comment #1) > Looks like a difference in handling of misnested tags (<li>.....<dd><li>). This is now interoperable following the HTML parser standardisation. (In reply to mitz from comment #3) > Firefox has this rule in quirk.css: > > /* Quirk: DD not in DL has text-indent instead of margin (b=5119) */ > > :not(dl) > dd { > display: inline; > margin: 0; > } > > There are a few more dl/dd quirks there. https://bugzilla.mozilla.org/show_bug.cgi?id=782551 dropped this quirk from Firefox 70, and quirks/dd-dl-firefox-001.html in WPT passes everywhere showing we have consistency here. The original URL no longer exists and doesn't appear to be in the Internet Archive, so I can't compare behaviour between browsers nowadays, but resolving this as invalid on the basis that we have interoperability on both of the behaviours described in this issue. |