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 <n...@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 <d...@apple.com> wrote: > >> >> On 15/03/2013, at 4:45 AM, Noam Rosenthal <n...@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 >> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
