Bug 68471

Summary:

Add webkit 'filter' value to RenderStyle

Product:

WebKit

Reporter:

Dean Jackson <dino>

Component:

CSS

Assignee:

Dean Jackson <dino>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

cmarrin, krit, peter, simon.fraser, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Bug Depends on:

Bug Blocks:

68469, 68472

Attachments:

Description	Flags
Patch	none
Patch	simon.fraser: review+

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.