Bug 93304 - Understand and fix problems fantasai and boris are frustrated about our CSS implementation
Summary: Understand and fix problems fantasai and boris are frustrated about our CSS i...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 64608 78087 86071 12520 18027 54373 84930 86520
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-06 15:58 PDT by Ryosuke Niwa
Modified: 2017-07-18 08:29 PDT (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2012-08-06 15:58:02 PDT
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.
Comment 1 Julien Chaffraix 2012-08-06 16:09:28 PDT
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.
Comment 2 Boris Zbarsky 2012-08-06 16:10:08 PDT
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.
Comment 3 Boris Zbarsky 2012-08-06 16:17:32 PDT
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.
Comment 5 Abhishek Arya 2012-08-06 18:11:50 PDT
(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.
Comment 6 fantasai 2012-08-06 18:50:56 PDT
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&mdash;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.
Comment 7 Ryosuke Niwa 2012-08-06 19:53:15 PDT
(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&mdash;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.
Comment 8 Theresa O'Connor 2012-08-07 11:32:08 PDT
(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