<div dir="ltr">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.<div><div><br></div><div><br></div><div>  antti</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 2, 2017 at 10:00 AM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Aug 1, 2017 at 11:40 PM, Andreas Kling <<a href="mailto:akling@apple.com">akling@apple.com</a>> wrote:<br>
><br>
>> On 2 Aug 2017, at 01:03, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>> wrote:<br>
>><br>
>> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling <<a href="mailto:akling@apple.com">akling@apple.com</a>> wrote:<br>
>>> Some time has passed, and it seems that adoption of CSS regions on the web is not gonna happen.<br>
>>><br>
>>> Blink has long since removed their support.<br>
>>> Firefox never supported it AFAIK.<br>
>>> (The new) IE has some amount of support behind a prefix, but no plans to unprefix AFAIK.<br>
>>><br>
>>> I think it’s time we remove the code from WebKit, and relieve ourselves of the maintenance burden.<br>
>>> This should also open up numerous opportunities for clean-up and optimization.<br>
>>><br>
>>> 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!<br>
>><br>
>> Since we've been shipping CSS regions for a while, I think the first<br>
>> step we should take would be disabling the feature on trunk, and put<br>
>> that into STP and other ports' releases so that we can easily revert<br>
>> the change if we find out any Web content to be broken when the<br>
>> feature is disabled.<br>
><br>
</span><span class="">>> 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.<br>
><br>
> 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.<br>
<br>
</span>Given my concern is the compatibility, not the maintenance cost, what<br>
is the evidence that nobody is relying on this feature?<br>
<br>
It seems a little crazy to remove a feature that has been available<br>
(prefixed) since Safari 6.2 without any prior warning or gathering any<br>
usage metrics at all.<br>
<br>
Also see: <a href="https://trac.webkit.org/wiki/DeprecatingFeatures" rel="noreferrer" target="_blank">https://trac.webkit.org/wiki/<wbr>DeprecatingFeatures</a><br>
<span class=""><br>
> 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.<br>
<br>
</span>I'm more concerned about iOS and macOS apps that use WebKit than the<br>
Web content in the wild.<br>
<br>
- R. Niwa<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-dev</a><br>
</div></div></blockquote></div><br></div>