WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 68471
Add webkit 'filter' value to RenderStyle
https://bugs.webkit.org/show_bug.cgi?id=68471
Summary
Add webkit 'filter' value to RenderStyle
Dean Jackson
Reported
2011-09-20 14:05:43 PDT
filter needs to be exposed to all content
Attachments
Patch
(44.63 KB, patch)
2011-09-26 15:40 PDT
,
Dean Jackson
no flags
Details
Formatted Diff
Diff
Patch
(45.41 KB, patch)
2011-09-26 17:30 PDT
,
Dean Jackson
simon.fraser
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2011-09-20 14:08:14 PDT
<
rdar://problem/10155630
>
Dean Jackson
Comment 2
2011-09-21 13:31:49 PDT
This is wrong. Obviously the property should be prefixed, so I'm retitling this to be implement a new RenderStyle value. I propose the implementation goes: 1. prefixed version for HTML. SVG filter remains untouched. 2. implement prefixed version for SVG in addition to existing filter (who wins?) 3. eventually merge when we can drop prefix
Dirk Schulze
Comment 3
2011-09-22 00:55:24 PDT
(In reply to
comment #2
)
> This is wrong. Obviously the property should be prefixed, so I'm retitling this to be implement a new RenderStyle value. I propose the implementation goes: > > 1. prefixed version for HTML. SVG filter remains untouched. > 2. implement prefixed version for SVG in addition to existing filter (who wins?)
But you still plan to use the same work flow and the same CSS property for both, HTML and SVG, no?
Dean Jackson
Comment 4
2011-09-26 14:38:45 PDT
(In reply to
comment #3
)
> (In reply to
comment #2
) > > This is wrong. Obviously the property should be prefixed, so I'm retitling this to be implement a new RenderStyle value. I propose the implementation goes: > > > > 1. prefixed version for HTML. SVG filter remains untouched. > > 2. implement prefixed version for SVG in addition to existing filter (who wins?) > > But you still plan to use the same work flow and the same CSS property for both, HTML and SVG, no?
Yes, eventually. (And eventually is not that long away - I just don't want to disrupt the working SVG filter path while CSS is in flux)
Dean Jackson
Comment 5
2011-09-26 15:40:00 PDT
Created
attachment 108738
[details]
Patch
Simon Fraser (smfr)
Comment 6
2011-09-26 15:46:41 PDT
Comment on
attachment 108738
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=108738&action=review
> Source/WebCore/platform/graphics/filters/FilterOperation.h:230 > + double m_offsetX; > + double m_offsetY;
What is this offset? Is it a blur radius? If so, how is it defined?
Dean Jackson
Comment 7
2011-09-26 15:47:59 PDT
(In reply to
comment #6
)
> (From update of
attachment 108738
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=108738&action=review
> > > Source/WebCore/platform/graphics/filters/FilterOperation.h:230 > > + double m_offsetX; > > + double m_offsetY; > > What is this offset? Is it a blur radius? If so, how is it defined?
Yes, a blur radius. We expose lengths into the filter operation. I expect we'll need to plumb them through similar to the way TranslateTransformOperation has to.
Dean Jackson
Comment 8
2011-09-26 17:30:26 PDT
Created
attachment 108764
[details]
Patch
Dean Jackson
Comment 9
2011-09-26 17:33:56 PDT
New patch with Simon's change to stdDeviation. I guess I shouldn't copy the r+ (not even sure I can do that)
Dean Jackson
Comment 10
2011-09-27 12:48:56 PDT
http://trac.webkit.org/changeset/96142
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug