[webkit-dev] CSS filter behavior change - what is our policy?

[Noam Rosenthal]

I'm not so worried about existing content, as there's not that much of it
and web developers can always adapt it, but unlike other bleeding edge
features this one is already enabled by default in several released
browsers, which means new content that wishes to use the brightness filter
would have to create cross-webkit-browser-version workarounds from day
one...
Maybe a feature that's enabled by default in more than one browser is
effectively no longer bleeding edge?

I'm afraid that the current situation renders the brightness filter useless
- people who use -webkit-filter: brightness(0) would know for sure that
using it would generate completely different results on different
(shipping) versions of webkit.

I see two options here, but maybe there are more I can't think of right now:
1. revert the change, and bring it back for the unprefixed version of the
filter CSS attributes, living with the "incorrect" brightness filter for
the lifetime of -webkit-filter.
2. Create a "quirks" media-query or something like that, where using CSS
the web developer can query for the new behavior.

If these aren't acceptable, what would be your recommendation to web
developers who want to use brightness and target both new browsers and
currently shipping browsers?


On Thu, Mar 14, 2013 at 9:07 PM, Noam Rosenthal <noam at webkit.org> wrote:

> I'm not so worried about existing content, as there's not that much of it
> and web developers can always adapt it, but unlike other bleeding edge
> features this one is already enabled by default in several released
> browsers, which means new content that wishes to use the brightness filter
> would have to create cross-webkit-browser-version workarounds from day
> one...
> Maybe a feature that's enabled by default in more than one browser is
> effectively no longer bleeding edge?
>
> I'm afraid that the current situation renders the brightness filter
> useless - people who use -webkit-filter: brightness(0) would know for sure
> that using it would generate completely different results on different
> (shipping) versions of webkit.
>
> I see two options here, but maybe there are more I can't think of right
> now:
> 1. revert the change, and bring it back for the unprefixed version of the
> filter CSS attributes, living with the "incorrect" brightness filter for
> the lifetime of -webkit-filter.
> 2. Create a "quirks" media-query or something like that, where using CSS
> the web developer can query for the new behavior.
>
> If these aren't acceptable, what would be your recommendation to web
> developers who want to use brightness and target both new browsers and
> currently shipping browsers?
>
>
>
> On Thu, Mar 14, 2013 at 7:35 PM, Dean Jackson <dino at apple.com> wrote:
>
>>
>> On 15/03/2013, at 4:45 AM, Noam Rosenthal <noam at webkit.org> wrote:
>>
>> How do we go about rendering behavior changes that affect features that
>> are enabled on shipping browsers?
>>
>> I'm specifically referring to http://trac.webkit.org/changeset/139770
>> The brightness filter is enabled by default on chrome and Safari if I
>> remember correctly, and now pages that use brightness(0) would have their
>> element blackened, while before those elements would have been left
>> unchanged. This is of course "correct" so I can't claim it's a bug, but
>> still it would break existing websites, even if not many.
>>
>> Do we see CSS filters as being "bleeding edge" enough where we don't
>> care? Do we have a way to warn web developers about this? They'd basically
>> have to check Chrome/Safari/Other version in order to work around the
>> problem, as there's no media query for "check if brightness behaves
>> correctly".
>>
>>
>> I think in this case it was enough of a combination of "bleeding edge" +
>> definite bug (where bleeding edge is determined by it being a prefixed
>> property that isn't even at the candidate recommendation stage as well has
>> young enough to not have widespread use). But you raise a good point - I
>> would have been more reluctant to make this change as time passed.
>>
>> Dean
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130314/56fb4c33/attachment.html>