On Mon, Sep 29, 2014 at 8:12 PM, Rik Cabanier <caban...@gmail.com> wrote:
>
>
> On Mon, Sep 29, 2014 at 10:20 AM, Markus Stange <msta...@themasta.com>
> wrote:
>>
>> Hi,
>>
>> I'd like to revive this discussion.
>>
>> On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze <dschu...@adobe.com> wrote:
>>
>> > I would suggest a filter attribute that takes a list of filter
>> > operations
>> > similar to the CSS Image filter function[1]. Similar to shadows[2], each
>> > drawing operation would be filtered. The API looks like this:
>> >
>> > partial interface CanvasRenderingContext2D {
>> > attribute DOMString filter;
>> > }
>> >
>> > A filter DOMString could looks like: “contrast(50%) blur(3px)”
>>
>> This approach sounds good to me, and it's what I've implemented for
>> Firefox in bug 927892 [1]. The Firefox implementation is behind the
>> preference canvas.filters.enabled which is currently off by default.
>>
>> > Filter functions include a reference to a <filter> element and a
>> > specification of SVG filters[4]. I am unsure if a reference do an
>> > element
>> > within a document can cause problems. If it does, we would just not
>> > support
>> > SVG filter references.
>>
>> I've included support for SVG filters in the Firefox implementation.
>> It's a bit of work and it increases the number of edge cases we need
>> to specify, but I think it's worth it.
>
>
> Can we limit it to just the set of CSS filter shorthands for now?
> I think other UA's are further behind in their implementation of integrating
> SVG filters in their rendering pipeline.
Sure. In Firefox I can put CSS and SVG filters for canvas behind
different prefs so that we can enable the CSS part without exposing
the SVG part.
>
>>
>> Here's a more fleshed-out proposal that attempts to define the edge
>> cases I've encountered during development.
>>
>> The ctx.filter property should behave like the ctx.font property in some
>> senses:
>> - It's part of the state of the context and honors ctx.save() and
>> ctx.restore().
>> - Setting an invalid value is ignored silently.
>> - Both "inherit" and "initial" are invalid values, as with font.
>> - Setting a valid value sets the current state's filter to that
>> value, and the getter will now return this value, possibly
>> reserialized.
>> Question: Do we want the getter to return the serialized form of the
>> filter?
>
>
> Since it's an attribute, it would be strange if it returns a different
> string. It should return the same value that it was set to.
I agree, returning the exact value that was assigned would be less
surprising. I brought this up because the font attribute does
something like this: Its getter returns a serialized value that
doesn't contain the line-height part, and also leaves out some
subproperty values that have default values.
>> Interaction with shadow:
>> - If both a filter and a shadow are set on the canvas, filtering will
>> happen first, with the shadow being applied to the filtered results.
>> In that case the global composite operation will be respected when
>> compositing the result with shadow into the canvas.
>> - As a consequence of the other statements, this is true: If a valid
>> filter is used, appending " drop-shadow(<shadowOffsetX>px
>> <shadowOffsetY>px <shadowBlur>px <shadowColor>)" to the filter will
>> have the same results as using the shadow properties, even if there is
>> a transform on the context.
>
>
> Since you can do a shadow with the filter attribute, maybe we can specify
> that the shadow attribute is ignored?
Hmm, we could do that but I don't really see the benefits. I think
it's more surprising to users when shadows stop working as soon as
they set a filter than if they just keep working.
Markus
