https://twitter.com/bz_moz/status/232607703938252802 Apparently our implementation of display: run-in, and "+" and "-" combinators in CSS selectors are bad. Let's figure out what's wrong with them and fix them.
Abhishek hacked on display: run-in back in May (we don't know when Boris tested). AFAICT we wouldn't properly run-in or not run-in in several simple cases. See bug 86387 for example.
For run-in, you may want to see https://bugzilla.mozilla.org/show_bug.cgi?id=2056#c38 (though there is talk of changing that part in the spec) and https://bugzilla.mozilla.org/show_bug.cgi?id=2056#c51 and https://bugzilla.mozilla.org/show_bug.cgi?id=2056#c52 but the summary is that pretty much everything I tested about run-in in WebKit was broken at the time. For the combinator thing, see <http://weblogs.mozillazine.org/bz/archives/2009/10/performance_vs_correctness_tra.html>. Since then some hackery has fixed most of the simple cases, but it's still not that hard to get failures with ":hover" and '~' last I tested a few months ago.
Oh, fwiw the "change the text data" testcase I mentioned above still fails in a WebKit nightly, though the bogosity with the run-in disappearing completely if the block it ran into is removed from the DOM seems to have been fixed at first glance.
Related combinator bugs: https://bugs.webkit.org/show_bug.cgi?id=54373 https://bugs.webkit.org/show_bug.cgi?id=12520 https://bugs.webkit.org/show_bug.cgi?id=18027
(In reply to comment #3) > Oh, fwiw the "change the text data" testcase I mentioned above still fails in a WebKit nightly, though the bogosity with the run-in disappearing completely if the block it ran into is removed from the DOM seems to have been fixed at first glance. Run-in fixes and rewrite was done in http://trac.webkit.org/changeset/117482 http://trac.webkit.org/changeset/117865 http://trac.webkit.org/changeset/118249 http://trac.webkit.org/changeset/124556 There is still quite a lot of stuff left [e.g.https://bugs.webkit.org/show_bug.cgi?id=86520]. The above attempt was to capture most of the general usecases.
Media Queries bugs: http://lists.w3.org/Archives/Public/public-css-testsuite/2012Jun/0006.html http://www.w3.org/Style/CSS/Test/MediaQueries/20120229/reports/implement-report.html I can understand not caring about parsing edge cases, but the last section is fairly critical for forwards-compat. (Implementing 'resolution' would be pretty high on my wishlist, too, since this is probably preventing authors from switching to it from -webkit-device-pixel-ratio. But that's not a QoI issue, it's just a fairly major completeness one.) Wrt Writing Modes, orthogonal flows are not handled correctly: https://bugs.webkit.org/show_bug.cgi?id=64608 Even with -webkit-column-width: 15em; added to the inner div, the rendering is wrong and overflows the containing block. And from what Koji and jdaggett are telling me, the orientation of characters in vertical writing modes is really off. Here's a fun example: <style>body { -webkit-writing-mode: vertical-rl; -webkit-text-orientation: upright; } </style> <p>(Current—behavior)</p> Spacing's messed up on Linux at least, parens and dashes are the wrong orientation, and letters are not centered horizontally in the line.
(In reply to comment #6) > And from what Koji and jdaggett are telling me, the orientation of characters > in vertical writing modes is really off. > Here's a fun example: > <style>body { > -webkit-writing-mode: vertical-rl; -webkit-text-orientation: upright; } > </style> > <p>(Current—behavior)</p> > Spacing's messed up on Linux at least, parens and dashes are the wrong > orientation, and letters are not centered horizontally in the line. FWIW, writing mode only works on Mac at the moment. We really need to disable that on other platforms. See the bug 84930.
(In reply to comment #6) > (Implementing 'resolution' would be pretty high on my wishlist, too https://bugs.webkit.org/show_bug.cgi?id=78087 > And from what Koji and jdaggett are telling me, the orientation of characters > in vertical writing modes is really off. [...] > Spacing's messed up on Linux at least, parens and dashes are the wrong > orientation, and letters are not centered horizontally in the line. I think this is all captured in https://bugs.webkit.org/show_bug.cgi?id=86071