Editor’s Note: the following guest post was written by Hanna Zarour, Project Manager at Igalia
The AMP Project is humbled to help represent developers in their challenges with web interoperability and lack of important feature implementation. Over the last few years, we have collaborated with Igalia to advance interoperability and predictability among browsers. Standards and the degree of interoperability that we want can be a long process. New features require a lot of planning, experimentation and course corrections before more implementations can begin and users can discover issues for further improvement.
Both AMP and Igalia are very pleased to have been able to play important roles at all stages of this process and help drive things forward. We have been proud of the work we’ve done together in the second half of 2020. The details of that effort are highlighted below:
Scrolling
Chromium
In Chrome, we continued working on the standard scroll values in non-default writing modes. As we mentioned in our previous blog post, our changes were guarded by a runtime flag “CSSOM View Scroll Coordinates”. Because gaining interoperability required changed scroll values, we’ve had to be very cautious about the potential breakage it could cause. We’ve been working diligently for the last few months to do the work necessary to determine that it is safe to remove this flag. After working with Google engineers, here’s how we went about finally deciding this was safe and removing the flag:
To start, we used UMA/UKM to collect data for several months on possible breakage and analyzed that data. The summary of the full report can be found here.
In addition, we discussed the report in the blink-dev thread and decided to enable the Finch flag gradually (first on Canary, then for stable 85+). Meanwhile, we kept monitoring scrolling related bugs, and pulled back if the risk was higher than expected. We were fortunate to find few bugs. Our analysis of the data also showed good results. To complete this, we decided to remove the legacy code of the runtime flag.
WebKit
We continue to put efforts toward enhancing scrolling on WebKit. Over the last few months, we have been working on overscroll-behavior and implementing the scrollend event.
The CSS property overscroll-behavior, as you might know, sets what a browser does when reaching the boundary of a scrolling area. It includes scroll chaining, scroll stretching, swipe gestures, etc. To modify the default boundary actions, we need to handle it according to the type of scroll and the interfaces available in each platform. For instance, the scroll chaining of asynchronous scroll on iOS is handled inside UIScrollViews, we can’t modify it from outside. On the other hand, Mac has enough interfaces for us to implement overscroll-behavior. So we decided to start from Mac. Currently, we’ve landed a patch to parse overscroll-behavior and its values, i.e. from CSS to the WebKit internal type, like CSSPropertyID. It’s guarded by an experimental flag “CSS Overscroll Behavior”. The prototype of overscroll-behavior for synchronous scroll and asynchronous scroll on Mac is finished.
The scrollend event, as you might expect, is fired when the scroll is finished. To implement it, we need to handle scroll types separately, user scroll, programmatic scroll and the combination of them. For user scroll and programmatic scroll, the scrollend event needs to be fired according to different timers. For the combination of them, user scroll often has higher priority than programmatic scroll which usually is canceled or rewritten by user scroll. To avoid confusion, only user initiated scrolling fires the scrollend event. A state indicating whether user scroll is in progress is needed. Then the programmatic scroll can decide to fire scrollend events or not. As scrollend events are fired on the main thread, so we need to consider the consistency of an asynchronous scroll which performs scroll on the other thread or process. Currently, we’ve finished prototyping the firing of the scrollend event for user scroll and programmatic scroll, both synchronous and asynchronous scroll supported. As for the combination, we are currently working on a patch to gather the user scroll in progress state.
IntersectionObserver and ResizeObserver
Since 2019, we have maintained IntersectionObserver (enabled in iOS 12.2) and ResizeObserver (enabled in iOS 14 beta) in WebKit. As expected, a few bugs have been reported during this time. One such bug was regarding objects inside ResizeObserverCallback being garbage collected until reloading the page, if ResizeObserver is referenced inside ResizeObserverCallback. A similar bug occurred in IntersectionObserver. The solution was to make ResizeObserverCallback and IntersectionObserverCallback as weak callbacks and add them to the visitor of JSResizeObserver or JSIntersectionObserver. The patches to fix this have landed.
Web Vitals
Performance metrics such as the ones provided by the Web Vitals project are also critical for web developers to ensure they can quantify the user experience of their site and find concrete ways to improve that experience. A working prototype was created for Event Timing. Unfortunately when starting to land patches for Event Timing it became clear that the specification is currently not acceptable to Apple. Some bug fixes were made while working on related standards.
Resource Loading
Lazy iframe loading was added to the specification and implemented in WebKit. Lazy loading itself needs a few more bug fixes, so it is still behind a flag for now.
CSS aspect-ratio
In October permission was asked and given in Webkit to work on the CSS aspect-ratio feature which allows the setting of an aspect ratio to allow the auto sizing of elements, just as images and others automatically already do this. Shortly after permission was granted, implementation work started. A lot of progress was made and the expectation is that the work on this feature will be finished in Q2 2021.
What’s next
The work highlighted above will continue into 2021 and highlighted below are some of the key projects that Igalia will be contributing to:
- We will continue to focus on scrolling features mentioned such as scrollend event, overscroll behavior and scroll behavior.
- As a continuation of the work done for aspect ratio calculation of images, we are continuing to work on the more general CSS aspect-ratio property.
- We will be working on the implementation of CSS Containment in Safari. The work that your browser does to render everything you can specify with CSS at 60fps is amazing given the complex relationships that exist. The CSS containment property allows authors to provide careful advice which limits these relationships by isolating their style, paint and/or size. This sort of advice allows the rendering engine to significantly optimize rendering performance as it can perform a more limited amount of work on a smaller area of the DOM without so many complex interactions. CSS Containment L1 is implemented in both Chrome and Firefox, but is not currently implemented in WebKit browsers. The performance gains that this allows are on their own, are very valuable and worth getting across the finish line. However, what is potentially possible once such primitive concepts exist in engines is at least as exciting. New ideas like the specification and prototype for Container Queries that is underway, and content-visibility require the concepts laid out in CSS Containment.
Our collaboration has led to some very important and productive work in the web commons, and we are passionate about continuing to collaborate in supporting a better shared experience of a stronger web commons.