Tested with r24875 1. Go to the bug url (note should go to the bottom of the page, but does not, though if you go back to the top of the page and click on "Useful References" link, it will go to the correct place). 2. Listed URLs under "These tools are further described in:" should be part of one list. Second and third items in list are incorrectly indented. Firefox does not show any additional indentation. This is not a regression, as it happens in shipping Safari
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.