Removing support for CSS regions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Removing support for CSS regions

Andreas Kling
Hi folks,

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!

The removal work will be tracked in this bug:
https://bugs.webkit.org/show_bug.cgi?id=174978

Cheers,
kling
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Michael Catanzaro
On Mon, Jul 31, 2017 at 9:49 AM, Andreas Kling <[hidden email]> wrote:
Hi folks, Some time has passed, and it seems that adoption of CSS regions on the web is not gonna happen.

Yeah, it does indeed.

Does anyone have a good explanation for what went wrong? Why did Blink remove its support? Just curious.

Michael

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Håkon Wium Lie
Michael Catanzaro wrote:

 > > Some time has passed, and it seems that adoption of CSS regions on
 > > the web is not gonna happen.
 >
 > Yeah, it does indeed.
 >
 > Does anyone have a good explanation for what went wrong? Why did Blink
 > remove its support? Just curious.

Some answers can be found here:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/kTktlHPJn4Q/YrnfLxeMO7IJ
https://alistapart.com/blog/post/css-regions-considered-harmful
https://slashdot.org/story/14/01/29/1745233/google-planning-to-remove-css-regions-from-blink

Håkon Wium Lie     [hidden email]    www.wiumlie.no/en     +47 90192217


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Dean Jackson-7
In reply to this post by Andreas Kling
I've been told that Amazon's Kindle Cloud Reader uses CSS Regions if available, and gets a significant performance boost. It has a fallback though.

Also, it would be worth checking at least Apple's iBooks store for any content that might have used regions. It would be a shame if purchased books stopped working :)

Dean


> On 31 Jul 2017, at 10:49, Andreas Kling <[hidden email]> wrote:
>
> Hi folks,
>
> 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!
>
> The removal work will be tracked in this bug:
> https://bugs.webkit.org/show_bug.cgi?id=174978
>
> Cheers,
> kling
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Ryosuke Niwa-2
In reply to this post by Andreas Kling
On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling <[hidden email]> 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.

- R. Niwa
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Andreas Kling
In reply to this post by Dean Jackson-7


> On 1 Aug 2017, at 15:38, Dean Jackson <[hidden email]> wrote:
>
> I've been told that Amazon's Kindle Cloud Reader uses CSS Regions if available, and gets a significant performance boost. It has a fallback though.

Hi Dean! I’ve WebInspected around in a few books using Kindle Cloud Reader and can’t find any evidence that it uses CSS regions. Could this be outdated information?

> Also, it would be worth checking at least Apple's iBooks store for any content that might have used regions. It would be a shame if purchased books stopped working :)

A search (done around Christmas 2016) found no instances of iBooks using CSS regions.

kling
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Andreas Kling
In reply to this post by Ryosuke Niwa-2

> On 2 Aug 2017, at 01:03, Ryosuke Niwa <[hidden email]> wrote:
>
> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling <[hidden email]> 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.

Hi Ryosuke!

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.

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.

kling
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Ryosuke Niwa-2
On Tue, Aug 1, 2017 at 11:40 PM, Andreas Kling <[hidden email]> wrote:

>
>> On 2 Aug 2017, at 01:03, Ryosuke Niwa <[hidden email]> wrote:
>>
>> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling <[hidden email]> 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
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> wrote:
On Tue, Aug 1, 2017 at 11:40 PM, Andreas Kling <[hidden email]> wrote:
>
>> On 2 Aug 2017, at 01:03, Ryosuke Niwa <[hidden email]> wrote:
>>
>> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling <[hidden email]> 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
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Andreas Kling
In reply to this post by Ryosuke Niwa-2

On 2 Aug 2017, at 09:00, Ryosuke Niwa <[hidden email]> wrote:

On Tue, Aug 1, 2017 at 11:40 PM, Andreas Kling <[hidden email]> wrote:

On 2 Aug 2017, at 01:03, Ryosuke Niwa <[hidden email]> wrote:

On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling <[hidden email]> 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?

While I am not the all-seeing oracle of unused features, I can tell you a few things right now:

- There are no Mac or iOS clients of CSS regions among Apple’s own apps.
- There are no iBooks using CSS regions.
- I could only find one radar about CSS regions from anyone who’s not an engineer working on implementing CSS regions in WebKit.
- That radar was deemed a real bug, but got punted in 2014 because “we don’t know of any high priority regions client.” :|

kling

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Maciej Stachowiak
In reply to this post by Andreas Kling


On Aug 2, 2017, at 2:40 AM, Andreas Kling <[hidden email]> wrote:


On 2 Aug 2017, at 01:03, Ryosuke Niwa <[hidden email]> wrote:

On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling <[hidden email]> 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.

Hi Ryosuke!

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.

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.

If we wanted to use extra caution, I think the more useful thing to do would be to add telemetry to an STP build instead of doing a test disable and waiting for bugs. That's likely to get as an answer much sooner. (It won't tell us about content for non-browser apps, but disabling in STP can't tell us that either.)

 - Maciej



_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Geoffrey Garen
In reply to this post by Andreas Kling
Given my concern is the compatibility, not the maintenance cost, what
is the evidence that nobody is relying on this feature?

It’s difficult to prove a negative. Impossible, in fact.

Can anyone present evidence of a major client of CSS regions?

If not, I think that lack of evidence — in combination with the lack of support for CSS regions in other browsers — is the best we’ll be able to do to know that the feature can be removed.

Disabling at runtime might give us a little more information, but we don’t have a huge beta population and app developers don’t test against trunk WebKit, so it’s not that much information. Also, adding runtime enable/disable checks for a fundamental layout feature moves in the opposite direction of the goal, which is to simplify the code.

Maybe a compromise path is to disable parsing of CSS regions at compile time, but leave all the code in place, and then remove all the code after a Safari Technology Preview ships without incident. Would you feel better about that than just removing CSS regions right away?

Geoff

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removing support for CSS regions

Ryosuke Niwa-2
On Tue, Aug 15, 2017 at 10:56 AM, Geoffrey Garen <[hidden email]> wrote:

> Given my concern is the compatibility, not the maintenance cost, what
> is the evidence that nobody is relying on this feature?
>
>
> It’s difficult to prove a negative. Impossible, in fact.
>
> Can anyone present evidence of a major client of CSS regions?
>
> If not, I think that lack of evidence — in combination with the lack of
> support for CSS regions in other browsers — is the best we’ll be able to do
> to know that the feature can be removed.
>
> Disabling at runtime might give us a little more information, but we don’t
> have a huge beta population and app developers don’t test against trunk
> WebKit, so it’s not that much information. Also, adding runtime
> enable/disable checks for a fundamental layout feature moves in the opposite
> direction of the goal, which is to simplify the code.
>
> Maybe a compromise path is to disable parsing of CSS regions at compile
> time, but leave all the code in place, and then remove all the code after a
> Safari Technology Preview ships without incident. Would you feel better
> about that than just removing CSS regions right away?

Sure. Disabling the feature for a few STP releases would be a great
start. Meanwhile we can reach out to folks who maintain iBooks, etc...
to figure out if there's any epub content that relies on CSS regions,
etc...

- R. Niwa
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Loading...