|Summary:||box-shadow rendered differently from Firefox with negative spread|
|Product:||WebKit||Reporter:||Alex Yaroshevich <qfox>|
|Version:||528+ (Nightly build)|
Description Alex Yaroshevich 2011-06-10 16:45:39 PDT
Created attachment 96824 [details] Render example for FF5, Chrome and Opera The man said opera and chrome are not right. http://dbaron.org/log/20110225-blur-radius https://bugzilla.mozilla.org/show_bug.cgi?id=655580 Because he does update box-shadow property to the newest spec. But chrome and opera doesn't. Where is the truth? Looks like he's right after reading spec.
Comment 1 Alexey Proskuryakov 2011-06-10 20:21:19 PDT
The attachment is a link to an image. Could you please attach (not link to) your test case?
Comment 2 Alex Yaroshevich 2011-06-11 03:38:18 PDT
Created attachment 96853 [details] box-shadow render diff between webkit and gecko Yep. Sorry. I thought tracker will download it.
Comment 3 Alex Yaroshevich 2011-06-11 04:10:04 PDT
Created attachment 96854 [details] testcase Test-case for Webkit. I don't know how it can be tested).
Comment 4 Alex Yaroshevich 2011-06-11 04:15:53 PDT
Oops. It looks equals but it's because hack. Diff in spread-radius: -8px for webkit and -12px for gecko. But for positive numbers: 8px for webkit and 6px for gecko (or 12px for webkit and 8px for gecko). It's very strange.
Comment 5 Alex Yaroshevich 2011-06-11 09:44:35 PDT
That's not only if spread is negative. I'm sure. I must recalculate spread-radius for pretty now by algo: If spread > 0 then firefox-spread = spread*3/2; Elseif spread < 0 then firefox-spread = spread*2/3; But if FF is doing render as told in spec I could say chrome-and-opera-radius ;-) and could do inversion of calculations. Box-shadow render with spread-radius == 0 is fine (almost equal). And don't if spread is not eq to zero. Afaik.
Comment 6 Simon Fraser (smfr) 2011-06-11 15:27:35 PDT
I don't get what you're saying. Please just make a simple statement of what you think the bug is.