[webkit-dev] Removing support for CSS regions

[Antti Koivisto]

This is a blocker for making the render tree more secure and for
architectural progress there in general. The feature is extremely invasive
and has design issues. I think the security benefits of removing it alone
are worth taking a small regression risk.


  antti

On Wed, Aug 2, 2017 at 10:00 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Tue, Aug 1, 2017 at 11:40 PM, Andreas Kling <akling at apple.com> wrote:
> >
> >> On 2 Aug 2017, at 01:03, Ryosuke Niwa <rniwa at webkit.org> wrote:
> >>
> >> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling <akling at apple.com>
> wrote:
> >>> Some time has passed, and it seems that adoption of CSS regions on the
> web is not gonna happen.
> >>>
> >>> Blink has long since removed their support.
> >>> Firefox never supported it AFAIK.
> >>> (The new) IE has some amount of support behind a prefix, but no plans
> to unprefix AFAIK.
> >>>
> >>> I think it’s time we remove the code from WebKit, and relieve
> ourselves of the maintenance burden.
> >>> This should also open up numerous opportunities for clean-up and
> optimization.
> >>>
> >>> If you know of any reason to keep the feature, such as a major website
> or WebKit client depending on it, do speak up now!
> >>
> >> Since we've been shipping CSS regions for a while, I think the first
> >> step we should take would be disabling the feature on trunk, and put
> >> that into STP and other ports' releases so that we can easily revert
> >> the change if we find out any Web content to be broken when the
> >> feature is disabled.
> >
> >> Unless there is evidence of at least one major site or client depending
> on CSS regions, I don’t agree that such a slow removal process is necessary.
> >
> > IMO doing that would only further increase the maintenance burden
> incurred by the feature, since we’d have to add tons of runtime checks
> throughout the codebase.
>
> Given my concern is the compatibility, not the maintenance cost, what
> is the evidence that nobody is relying on this feature?
>
> It seems a little crazy to remove a feature that has been available
> (prefixed) since Safari 6.2 without any prior warning or gathering any
> usage metrics at all.
>
> Also see: https://trac.webkit.org/wiki/DeprecatingFeatures
>
> > I would feel differently if we were pioneering this removal, but since
> we’ve already seen it succeed in Blink I’m far less concerned.
>
> I'm more concerned about iOS and macOS apps that use WebKit than the
> Web content in the wild.
>
> - R. Niwa
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20170802/3977f75e/attachment-0001.html>