- From: Alan Gresley <alan@css-class.com>
- Date: Wed, 05 Oct 2011 21:45:10 +1100
- To: "Gregg Tavares (wrk)" <gman@google.com>
- CC: www-style list <www-style@w3.org>
On 5/10/2011 3:52 AM, Gregg Tavares (wrk) wrote: Hello Gregg. It good to reply to the same message thread instead of creating a new topic. > Note that that isn't just a "display" problem. > > If you look at the 2 screenshots > > http://greggman.com/downloads/examples/correct-3d-css-polygon-sorting-subdivisions-safari.png > http://greggman.com/downloads/examples/incorrect-3d-css-polygon-sorting-subdivisions-chrome.png > > > You'll notice that in the chrome screenshot Element #2 (green) has been > drawn in front of the other 2 elements (red, blue). Based on what is > displayed the user would expect to be able to click on anything in Element > #2. But, being based on WebKit the clicking code acts as though the scene > was subdivided meaning if you click on areas that overlap you'll get > unexpected results. > > This will only get much worse with CSS shaders where without proper sorting > it will be very hard to figure out to which elements mouse events should go. I don't see how this is related to CSS shaders. I don't see how you can even suggest that it could cause problems with clicking. You are jumping to fast and what is needed are simpler test cases. Anyway, it's a Chrome painting bug and it's wrong. Here a test case (with two examples). http://css-class.com/test/bugs/transforms/painting-order-intersecting-transforms1.htm The div with a blue background paints in front of parts of the div with a lime background and parts of the #frame with a red border. Changing the order of the source does nothing to change the bug. Note for implementers. I was going to report it on WebKit Bugzilla but Chrome is not available for selection. Where can I report this bug? -- Alan Gresley http://css-3d.org/ http://css-class.com/
Received on Wednesday, 5 October 2011 10:45:54 UTC