Jan 12, 2018
Last september, I published a first blog post to let people know a bit more about Igalia’s activities around the Web platform, with a plan to repeat such a review each semester. The present blog post focuses on the activity of the second semester of 2017.
As part of Igalia’s commitment to diversity and inclusion, we continue our effort to standardize and implement accessibility technologies. More specifically, Igalian Joanmarie Diggs continues to serve as chair of the W3C’s ARIA working group and as an editor of Accessible Rich Internet Applications (WAI-ARIA) 1.1, Core Accessibility API Mappings 1.1, Digital Publishing WAI-ARIA Module 1.0, Digital Publishing Accessibility API Mappings 1.0 all of which became W3C Recommandations in December! Work on versions 1.2 of ARIA and the Core AAM will begin in January. Stay tuned for the First Public Working Drafts.
We also contributed patches to fix several issues in the ARIA implementations of WebKit and Gecko and implemented support for the new DPub ARIA roles. We expect to continue this collaboration with Apple and Mozilla next year as well as to resume more active maintenance of Orca, the screen reader used to access graphical desktop environments in GNU/Linux.
Last but not least, progress continues on switching to Web Platform Tests for ARIA and “Accessibility API Mappings” tests. This task is challenging because, unlike other aspects of the Web Platform, testing accessibility mappings cannot be done by solely examining what is rendered by the user agent. Instead, an additional tool, an “Accessible Technology Test Adapter” (ATTA) must be also be run. ATTAs work in a similar fashion to assistive technologies such as screen readers, using the implemented platform accessibility API to query information about elements and reporting what it obtains back to WPT which in turn determines if a test passed or failed. As a result, the tests are currently officially manual while the platform ATTAs continue to be developed and refined. We hope to make sufficient progress during 2018 that ATTA integration into WPT can begin.
This semester, we were glad to receive Bloomberg’s support again to pursue our activities around CSS. After a long commitment to CSS and a lot of feedback to Editors, several of our members finally joined the Working Group! Incidentally and as mentioned in a previous blog post, during the CSS Working Group face-to-face meeting in Paris we got the opportunity to answer Microsoft’s questions regarding The Story of CSS Grid, from Its Creators (see also the video). You might want to take a look at our own videos for CSS Grid Layout, regarding alignment and placement and easy design.
On the development side, we maintained and fixed bugs in Grid Layout implementation for Blink and WebKit. We also implemented alignment of positioned items in Blink and WebKit. We have several improvements and bug fixes for editing/selection from Bloomberg’s downstream branch that we’ve already upstreamed or plan to upstream. Finally, it’s worth mentioning that the work done on
display: contents by our former coding experience student Emilio Cobos was taken over and completed by antiik (for WebKit) and rune (for Blink) and is now enabled by default! We plan to pursue these developments next year and have various ideas. One of them is improving the way grids are stored in memory to allow huge grids (e.g. spreadsheet).
Web Platform Predictability
We have implemented more
frame sandboxing attributes WebKit
to improve user safety and make control of sandboxed documents more flexible.
We improved the
sandboxed navigation browser context flag and implemented the new
allow-popup-to-escape-sandbox, allow-top-navigation-without-user-activation, and allow-modals values for the
Currently, HTML frame scrolling is not implemented in WebKit/iOS. As a consequence, one has to use the non-standard
-webkit-overflow-scrolling: touch property on overflow nodes to emulate scrollable elements. In parallel to the progresses toward using more standard HTML frame scrolling we have also worked on annoying issues related to overflow nodes, including
flickering/jittering of “position: fixed” nodes or broken Find UI or a regression causing content to disappear.
Another important task as part of our CSS effort was to address compatibility issues between the different browsers. For example we fixed editing bugs related to HTML List items: WebKit’s Bug 174593/Chromium’s Issue 744936 and WebKit’s Bug 173148/Chromium’s Issue 731621. Inconsistencies in web engines regarding selection with floats have also been detected and we submitted the first patches for WebKit and Blink. Finally, we are currently improving line-breaking behavior in Blink and WebKit, which implies the implementation of new CSS values and properties defined in the last draft of the CSS Text 3 specification.
We expect to continue this effort on Web Platform Predictability next year and we are discussing more ideas e.g. WebPackage or flexbox compatibility issues. For sure, Web Platform Tests are an important aspect to ensure cross-platform inter-operability and we would like to help improving synchronization with the conformance tests of browser repositories. This includes the accessibility tests mentioned above.
Last November, we launched a fundraising Campaign to implement MathML in Chromium and presented it during Frankfurt Book Fair and TPAC. We have gotten very positive feedback so far with encouragement from people excited about this project. We strongly believe the native MathML implementation in the browsers will bring about a huge impact to STEM education across the globe and all the incumbent industries will benefit from the technology. As pointed out by Rick Byers, the web platform is a commons and we believe that a more collective commitment and contribution are essential for making this world a better place!
While waiting for progress on Chromium’s side, we have provided minimal maintenance for MathML in WebKit:
- We fixed all the debug ASSERTs reported on Bugzilla.
- We did follow-up code clean up and refactoring.
- We imported Web Platform tests in WebKit.
- We performed review of MathML patches.
Regarding the last point, we would like to thank Minsheng Liu, a new volunteer who has started to contribute patches to WebKit to fix issues with MathML operators. He is willing to continue to work on MathML development in 2018 as well so stay tuned for more improvements!
One of the new features we focused on recently is BigInt. We are working on an implementation of BigInt in SpiderMonkey, which is currently feature-complete but requires more optimization and cleanup. We wrote corresponding test262 conformance tests, which are mostly complete and upstreamed. Next semester, we intend to finish that work while our coding experience student Caio Lima continues work on a BigInt implementation on JSC, which has already started to land. Google also decided to implement that feature in V8 based on the specification we wrote. The BigInt specification that we wrote reached Stage 3 of TC39 standardization. We plan to keep working on these two BigInt implementations, making specification tweaks as needed, with an aim towards reaching Stage 4 at TC39 for the BigInt proposal in 2018.
Igalia implemented and shipped async iterators and generators in Chrome 63, providing a convenient syntax for exposing and using asynchronous data streams, e.g., HTML streams. Additionally, we shipped a major performance optimization for Promises and async functions in V8.
We implemented and shipped two internationalization features in Chrome, Intl.PluralRules and Intl.NumberFormat.prototype.formatToParts. To push the specifications of internationalization features forwards, we have been editing various other internationalization-related specifications such as Intl.RelativeTimeFormat, Intl.Locale and Intl.ListFormat; we also convened and led the first of what will be a monthly meeting of internationalization experts to propose and refine further API details.
Thanks to sponsorship from Mozilla we have continued our involvement in the Quantum Render project with the goal of using Servo’s WebRender in Firefox.
Support from Metrological has also given us the opportunity to implement more web standards from some Linux ports of WebKit (GTK and WPE, including:
- Web Crypto
- Web Driver
- WebP animations support
- HTML interactive form validation
Thanks for reading and we look forward to more work on the web platform in 2018. Onwards and upwards!
Oct 23, 2017
At Igalia, we attend many browser events. This is a quick summary of some
recents conferences I participated to… or that gave me the opportunity to meet
Igalians in Paris 😉.
Week 31: Paris - CSS WG F2F - W3C
My teammate Sergio attended the CSS WG F2F meeting as an observer. On Tuesday morning, I also made an appearance
(but it was so brief that
ceux que j’ai rencontrés ne m’ont peut-être pas vu).
Together with other browser vendors and WG members,
Sergio gave an interview regarding the successful story of CSS Grid Layout.
By the way, given our
implementation work in WebKit and Blink, Igalia finally decided
to join the CSS Working Group 😊.
Of course, during that week I had dinner with
Sergio and it was nice to chat with my colleague in a French restaurant
Week 38: Tokyo - BlinkOn 8 - Google
Gyuyoung and I
attended BlinkOn 8. I had nice discussions and listened to
interesting talks about a wide range of topics (Layout NG,
Accessibility, CSS, Fonts,
Web Predictability & Standards, etc). It was a pleasure to finally meet in persons
some developers I had been in touch with during my projects on
For the lightning talks, we presented our activities
on embedded linux platforms and the Web Platform. Incidentally, it was great to see Igalia’s work
mentioned during the
Next Generation Rendering Engine session.
Obviously, I had the opportunity to visit places and taste Japanese food in
Asakusa, Ueno and Roppongi 😋.
Week 40: A Coruña - Web Engines Hackfest - Igalia
one of my favorite events, that gathers
the whole browser community during three days for
technical presentations, breakout sessions, hacking and galician food. This year, we had many
and attendees. It is good to see that the event is becoming more
and more popular! It was long overdue, but I was finally able to make
and WOFF2 installable as system libraries
on Linux and usable by WebKitGTK+ 😊. I opened similar bugs in Gecko and the same could be done in Chromium. Among the things I enjoyed,
I met Jonathan Kew in person and heard more about Antonio and Maksim’s progress on Ozone/Wayland.
As usual, it was nice to share time with colleagues, attend the assembly meeting,
play football matches, have meals, visit Asturias… and tell one’s story 😉.
San Jose - WebKit Contributors Meeting - Apple
In the past months, I have mostly been working on WebKit at Igalia and
I would have been happy to see my fellow WebKit developers.
However, given the events in Japan and Spain, I was not willing to make another
trip to the USA just after. Hence I had to miss the
WebKit Contributors Meeting again this year 😞.
my colleagues Alex,
were present. Igalia is an important contributor
to WebKit and we will continue to send people and propose some talks next year.
Week 42: Paris - Monthly Speaker Series - Mozilla
This Wednesday, I attended a conference on
Privacy as a Competitive Advantage in Mozilla’s office. It was
to hear about the increasing interest on privacy and to see the
regulation made by the European Union in that direction.
My colleague Philippe was visiting the office
to work with some Mozilla developers on one of our project, so I was also able
to meet him in the conference room. Actually, Mozilla employees were kind enough
to let me stay at the office after the conference… Hence I was able to work on Apple’s Web Engine on a project sponsored by Google at the Mozilla office… probably something you can only do at Igalia 😉. Last but not least, Guillaume was also in holidays in Paris this week, so I let you imagine
what happens when three French guys meet (hint: it involves food 😋).
Sep 7, 2017
A few years ago Bloomberg and Igalia started a collaboration to implement a new layout model for the Web Platform. Bloomberg had complex layout requirements and what the Web provided was not enough and caused performance issues. CSS Grid Layout seemed to be the right choice, a feature that would provide such complex designs with more flexibility than the currently available methods.
We’ve been implementing CSS Grid Layout in Blink and WebKit, initially behind some flags as an experimental feature. This year, after some coordination effort to ensure interoperability (talking to the different parties involved like browser vendors, the CSS Working Group and the web authors community), it has been shipped by default in Chrome 58 and Safari 10.1. This is a huge step for the layout on the web, and modern websites will benefit from this new model and enjoy all the features provided by CSS Grid Layout spec.
Since the CSS Grid Layout shared the same alignment properties as the CSS Flexible Box feature, a new spec has been defined to generalize alignment for all the layout models. We started implementing this new spec as part of our work on Grid, being Grid the first layout model supporting it.
Finally, we worked on other minor CSS features in Blink such as caret-color or :focus-within and also several interoperability issues related to Editing and Selection.
MathML is a W3C recommendation to represent mathematical formulae that has been included in many other standards such as ISO/IEC, HTML5, ebook and office formats. There are many tools available to handle it, including various assistive technologies as well as generators from the popular LaTeX typesetting system.
After the improvements we performed in WebKit’s MathML implementation, we have regularly been in contact with Google to see how we can implement MathML in Chromium.
Early this year, we had several meetings with Google’s layout team to discuss this in further details. We agreed that MathML is an important feature to consider for users and that the right approach would be to rely on the new LayoutNG model currently being implemented. We created a prototype for a small LayoutNG-based MathML implementation as a proof-of-concept and as a basis for future technical discussions. We are going to follow-up on this after the end of Q3, once Chromium’s layout team has made more progress on LayoutNG.
Servo is Mozilla’s next-generation web content engine based on Rust, a language that guarantees memory safety. Servo relies on a Rust project called WebRender which replaces the typical rasterizer and compositor duo in the web browser stack. WebRender makes extensive use of GPU batching to achieve very exciting performance improvements in common web pages. Mozilla has decided to make WebRender part of the Quantum Render project.
We’ve had the opportunity to collaborate with Mozilla for a few years now, focusing on the graphics stack. Our work has focused on bringing full support for CSS stacking and clipping to WebRender, so that it will be available in both Servo and Gecko. This has involved creating a data structure similar to what WebKit calls the “scroll tree” in WebRender. The scroll tree divides the scene into independently scrolled elements, clipped elements, and various transformation spaces defined by CSS transforms. The tree allows WebRender to handle page interaction independently of page layout, allowing maximum performance and responsiveness.
WebRTC is a collection of communications protocols and APIs that enable real-time communication over peer-to-peer connections. Typical use cases include video conferencing, file transfer, chat, or desktop sharing. Igalia has been working on the WebRTC implementation in WebKit and this development is currently sponsored by Metrological.
This year we have continued the implementation effort in WebKit for the WebKitGTK and WebKit WPE ports, as well as the maintenance of two test servers for WebRTC: Ericsson’s p2p and Google’s apprtc. Finally, a lot of progress has been done to add support for Jitsi using the existing OpenWebRTC backend.
Since OpenWebRTC development is not an active project anymore and given libwebrtc is gaining traction in both Blink and the WebRTC implementation of WebKit for Apple software, we are taking the first steps to replace the original WebRTC implementation in WebKitGTK based on OpenWebRTC, with a new one based on libwebrtc. Hopefully, this way we will share more code between platforms and get more robust support of WebRTC for the end users. GStreamer integration in this new implementation is an issue we will have to study, as it’s not built in libwebrtc. libwebrtc offers many services, but not every WebRTC implementation uses all of them. This seems to be the case for the Apple WebRTC implementation, and it may become our case too if we need tighter integration with GStreamer or hardware decoding.
WebVR is an API that provides support for virtual reality devices in Web engines. Implementation and devices are currently actively developed by browser vendors and it looks like it is going to be a huge thing. Igalia has started to investigate on that topic to see how we can join that effort. This year, we have been in discussions with Mozilla, Google and Apple to see how we could help in the implementation of WebVR on Linux. We decided to start experimenting an implementation within WebKitGTK. We announced our intention on the webkit-dev mailing list and got encouraging feedback from Apple and the WebKit community.
ARIA defines a way to make Web content and Web applications more accessible to people with disabilities. Igalia strengthened its ongoing committment to the W3C: Joanmarie Diggs joined Richard Schwerdtfeger as a co-Chair of the W3C’s ARIA working group, and became editor of the Core Accessibility API Mappings, [Digital Publishing Accessibility API Mappings] (https://w3c.github.io/aria/dpub-aam/dpub-aam.html), and Accessible Name and Description: Computation and API Mappings specifications. Her main focus over the past six months has been to get ARIA 1.1 transitioned to Proposed Recommendation through a combination of implementation and bugfixing in WebKit and Gecko, creation of automated testing tools to verify platform accessibility API exposure in GNU/Linux and macOS, and working with fellow Working Group members to ensure the platform mappings stated in the various “AAM” specs are complete and accurate. We will provide more information about these activities after ARIA 1.1 and the related AAM specs are further along on their respective REC tracks.
Web Platform Predictability for WebKit
The AMP Project has recently sponsored Igalia to improve WebKit’s implementation of the Web platform. We have worked on many issues, the main ones being:
- Frame sandboxing: Implementing sandbox values to allow trusted third-party resources to open unsandboxed popups or restrict unsafe operations of malicious ones.
- Frame scrolling on iOS: Addressing issues with scrollable nodes; trying to move to a more standard and interoperable approach with scrollable iframes.
- Root scroller: Finding a solution to the old interoperability issue about how to scroll the main frame; considering a new rootScroller API.
This project aligns with Web Platform Predictability which aims at making the Web more predictable for developers by improving interoperability, ensuring version compatibility and reducing footguns. It has been a good opportunity to collaborate with Google and Apple on improving the Web. You can find further details in this blog post.
with Bloomberg and Mozilla.
- Implementation of many ES6 features in V8, such as generators, destructuring binding and arrow functions
- Async/await and async iterators and generators in V8 and some work in JSC
- Optimizing SpiderMonkey generators
- Ongoing implementation of BigInt in SpiderMonkey and class field declarations in JSC
On the design/standardization side, Igalia is active in TC39 and with Bloomberg’s support
as well as working with the underlying ICU library.
Preparation of Web Engines Hackfest 2017
Igalia has been organizing and hosting the Web Engines Hackfest since 2009. This event under an unconference format has been a great opportunity for Web Engines developers to meet, discuss and work together on the web platform and on web engines in general. We announced the 2017 edition and many developers already confirmed their attendance. We would like to thank our sponsors for supporting this event and we are looking forward to seeing you in October!
Emilio Cobos has completed his coding experience program on implementation of web standards. He has been working in the implementation of “display: contents” in Blink but some work is pending due to unresolved CSS WG issues. He also started the corresponding work in WebKit but implementation is still very partial. It has been a pleasure to mentor a skilled hacker like Emilio and we wish him the best for his future projects!
During this semester we have been glad to welcome new igalians who will help us to pursue Web platform developments:
- Alicia Boya joined Igalia in March. She has experience in many areas of computing, including web development, computer graphics, networks, security, and software design with performance which we believe will be valuable for our Web platform activities.
- Ms2ger joined Igalia in July. He is a well-known hacker of the Mozilla community and has wide experience in both Gecko and Servo. He has noticeably worked in DOM implementation and web platform test automation.
- Participation to standardization bodies (W3C, TC39).
- Elaboration of conformance tests (web-platform-tests test262).
- Implementation and bug fixes in all open source web engines.
- Discussion with users, browser vendors and other companies.
Although, some of this work has been sponsored by Google or Mozilla, it is important to highlight how external companies (other than browser vendors) can make good contributions to the Web Platform, playing an important role on its evolution. Alan Stearns already pointed out the responsibility of the Web Plaform users on the evolution of CSS while Rachel Andrew emphasized how any company or web author can effectively contribute to the W3C in many ways.
Aug 30, 2017
The AMP Project and
have recently been collaborating to
improve WebKit’s implementation of
the Web platform.
Both teams are committed to make the Web better and we expect
that all developers and users will benefit from this effort.
In this blog post, we review some of the bug fixes and features currently being
Frame sandboxing: Implementing sandbox values to allow trusted
third-party resources to open unsandboxed popups
or restrict unsafe operations of malicious ones.
Frame scrolling on iOS: Trying to move to a more standard and
interoperable approach via
iframe elements; addressing miscellaneous
issues with scrollable nodes (e.g. visual artifacts while scrolling, view
not scrolled when using “Find Text”…).
Root scroller: Finding a solution to the
old interoperability issue
about how to scroll the main frame; considering a
new rootScroller API.
Some demo pages for frame sandboxing and scrolling are also available if you wish to test features discussed in this blog post.
AMP is an open-source project to enable websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms.
Several interoperability bugs and missing features in WebKit have
caused problems to AMP users and to Web developers in general. Although
it is possible to add platform-specific workarounds to AMP, the best way to
help the Web Platform community is to directly fix these issues in WebKit,
so that everybody can benefit from these improvements.
Igalia is a consulting company with a team dedicated to Web Platform
all open-source Web Engines (Chromium, WebKit, Servo, Gecko) working
in the implementation and standardization of miscellaneous technologies
(CSS Grid/flexbox, ECMAScript, WebRTC, WebVR, ARIA, MathML, etc).
Given this expertise,
the AMP Project sponsored Igalia so that they can lead these
developments in WebKit. It is worth noting that this project aligns with the
Web Predictability effort supported by both Google and Igalia, which aims at making the Web more
predictable for developers. In particular, the following aspects are considered:
- Interoperability: Effort is made to write
Web Platform Tests (WPT), to follow
Web standards and ensure consistent behaviors
between web engines or operating systems.
- Compatibility: Changes are carefully analyzed using telemetry techniques or
user feedback in order to avoid breaking compatibility with previous versions
- Reducing footguns: Removals of non-standard features (e.g. CSS vendor prefixes) are attempted while new features are carefully introduced.
Below we provide further description of the WebKit
improvements, showing concretely how the above principles are followed.
A sandbox attribute can
be specified on the
iframe element in order to enable a set of
restrictions on any content it hosts.
These conditions can be relaxed by specifying a list of values such as
(to allow the frame to open popups). By default, the same restrictions apply
to a popup opened by a sandboxed frame.
Figure 1: Example of sandboxed frames (Can they navigate their top frame or open popups? Are such popups also sandboxed?)
However, sometimes this behavior is not wanted. Consider for example the case
advertisement inside a sandboxed frame. If a popup is opened from this frame
then it is likely that a non-sandboxed context is desired on the landing page.
In order to handle this use case, a new allow-popups-to-escape-sandbox value
has been introduced. The value is now supported in Safari Technology Preview 34.
While performing that work, it was noticed that some WPT tests for the sandbox
attribute were still failing. It turns out that WebKit does not really
follow the rules to allow navigation. More specifically, navigating a top context
is never allowed when such context corresponds to an opened popup.
We have made some changes to WebKit
so that it behaves more closely to the specification. This is integrated into Safari Technology Preview 35 and you can for example
try this W3C test. Note that this test requires to change preferences to allow popups.
It is worth noting that web engines may slightly depart from the specification
regarding the previously mentioned rules. In particular, WebKit checks a
same-origin condition to be sure that one frame is allowed to navigate another
WebKit always has contained
a special case to ignore this condition when a sandboxed frame with
tries and navigate its top frame. This feature, sometimes known
as “frame busting,” has been used by third-party resources
to perform malicious auto-redirecting.
As a consequence, Chromium developers proposed to restrict
frame busting to the case where the navigation is triggered by a user gesture.
According to Chromium’s telemetry frame busting without a user gesture is very rare.
But when experimenting with the behavior change of
allow-top-navigation several regressions were reported.
Hence it was instead decided to introduce the
allow-top-navigation-by-user-activation flag in order to provide this improved
safety context while still preserving backward compatibility.
We implemented this feature in WebKit and it is now available in Safari Technology Preview 37.
Finally, another proposed security improvement is to use an
to explicitly allow sandboxed frames to display modal dialogs (with
prompt, etc). That is, the default behavior for sandboxed frames will be
to forbid such modal dialogs. Again, such a change of behavior must be done with
care. Experiments in Chromium showed that the
usage of modal dialogs in sandboxed frames is very low and no users complained.
implemented that behavior in WebKit
and the feature should arrive in Safari Technology Preview soon.
Check out the
frame sandboxing demos if
if you want to test the new
Apple’s UI choice was to (almost) always “flatten” (expand) frames so that
users do not require to scroll them. The rationale for this is that it avoids to
be trapped into hierarchy of nested frames. Changing that behavior is likely
to cause a big backward compatibility issue on iOS
so for now we proposed a less radical solution:
Add a heuristic to support the case of “fullscreen” iframes used by the AMP
Project. Note that such exceptions already exist in WebKit, e.g. to
avoid making offscreen content visible.
We thus added the following heuristic into
WebKit Nightly: do not flatten
out-of-flow iframes (e.g.
position: absolute) that have viewport units
vh). This includes the case of the “fullscreen” iframe previously
mentioned. For now it is still under a developer flag so that WebKit developers
can control when they want to enable it. Of course, if this is successful we
might consider more advanced heuristics.
The fact that frames are never scrollable in iOS is an obvious interoperability
issue. As a workaround, it is possible to emulate such “scrollable nodes”
overflow: scroll nodes with the
property set. This is not really ideal for our Web Predictability goal as we
would like to get rid of browser vendor prefixes. Also, in practice such
workarounds lead to even more problems in AMP as explained in these
posts. That’s why implementing scrolling of frames is
one of the main goals of this project and
significant steps have already been made in that direction.
Figure 2: C++ classes involved in frame scrolling
The (relatively complex) class hierarchy involved in frame scrolling is
summarized in Figure 2. The frame flattening heuristic mentioned above is
handled in the
WebCore::RenderIFrame class (in purple).
WebCore::ScrollingTreeOverflowScrollingNodeIOS classes from the
scrolling tree (in blue) are used to scroll, respectively,
the main frame and overflow nodes on iOS. Scrolling of
non-main frames will obviously have some code to share with the former, but
it will also have some parts in common with the latter. For example,
passing an extra
UIScrollView layer is needed instead of relying on the one
contained in the
WKWebView of the main frame. An important
step is thus to introduce a special class for scrolling inner frames that
would share some logic from the two other classes and
some refactoring to ensure optimal code reuse.
Similar refactoring has been done for scrolling node states (in red)
to move the scrolling layer parameter into
WebCore::ScrollingStateNode instead of having separate members
The scrolling coordinator classes (in green) are also important, for example to
handle hit testing. At the moment, this is not really implemented for
overflow nodes but it might be important to have it for scrollable frames.
Again, one sees that some logic is shared for asynchronous scrolling on macOS (
WebCore::ScrollingCoordinatorMac) and iOS (
in ancestor classes. Indeed, our effort to make frames scrollable on iOS
is also opening the possibility of
asynchronous scrolling of frames on macOS, something that is currently not implemented.
Figure 4: Video of this demo page on WebKit iOS with experimental patches to make frame scrollables (2017/07/10)
Finally, some more work is necessary in the render classes (purple) to ensure
that the layer hierarchies are correctly built. Patches
have been uploaded
and you can view the result on the video of Figure 4.
Notice that this work has not been reviewed yet and
there are known bugs, for example with
overlapping elements (hit testing not implemented) or
Various other scrolling bugs were reported, analyzed and sometimes fixed by
Apple. The switch from overflow nodes to scrollable iframes is unlikely to
address them. For example, the “Find Text” operation in iOS has
advanced features done by the UI process (highlight, smart magnification) but
the scrolling operation needed only works for the main frame. It looks like this could be fixed
by unifying a bit the scrolling code path with macOS. There are also
several jump and flickering bugs with
position: fixed nodes. Finally, Apple fixed
inconsistent scrolling inertia
used for the main frame and the one used for inner scrollable nodes by
making the former the same as the latter.
The CSSOM View specification extends the DOM element with some scrolling properties.
That specification indicates that the element to consider to scroll the main view
document.body in quirks mode while it is
in no-quirks mode. This is the behavior that has always been followed
by browsers like Firefox or Interner Explorer. However, WebKit-based browsers
document.body as the root scroller. This interoperability issue
has been a big problem for web developers.
One convenient workaround was to introduce the
document.scrollingElement which returns the element to use for scrolling the main
document.documentElement) and was recently
implemented in WebKit.
to verify whether your browser supports the
document.scrollingElement property and which DOM element is used to scroll
the main view in no-quirks mode.
Nevertheless, this does not solve the issue with existing web pages.
Chromium’s Web Platform Predictability team has made a huge communication effort
with Web authors and developers which has
drastically reduced the use of
document.body in no-quirks mode. For instance,
Chromium’s telemetry on Figure 3 indicates that the percentage of
document.body.scrollTop in no-quirks pages has gone
from 18% down to 0.0003% during the past three years. Hence the Chromium team
is now considering shipping the standard behavior.
Figure 3: Use of
document.body.scrollTop in no-quirks mode over time (Chromium's UseCounter)
In WebKit, the issue has been known for a long time and an
old attempt to fix it was reverted for causing regressions. For now, we imported
the CSSOM View tests and just
marked the one related to the scrolling element as failing. An analysis
of the situation has been left on
WebKit’s bug; Depending on
how things evolve on Chromium’s side we could consider the discussion and
implementation work in WebKit.
Related to that work, a
new API is being proposed
to set the root scroller to an arbitrary scrolling element, giving
more flexibility to authors of Web applications. Today, this is unfortunately
without losing some of the special features of the main view (e.g. on iOS,
Safari’s URL bar is hidden when scrolling the main view
to maximize the screen space). Such
API is currently being experimented in Chromium and we plan to
investigate whether this can be implemented in WebKit too.
In the past months, The AMP Project and Igalia have worked on analyzing some
interoperability issue and fixing them in WebKit. Many improvements for
frame sandboxing are going to be available soon.
Significant progress has also been
made for frame scrolling on iOS and collaboration continues with
Apple reviewers to ensure that the work will be integrated in future versions of
WebKit. Improvements to “root scrolling” are also being considered although they
are pending on the evolution of the issues on Chromium’s side. All these
efforts are expected to be useful for WebKit users and the Web platform
Last but not least, I would like to thank Apple engineers Simon Fraser,
Chris Dumez, and Youenn Fablet for their reviews and help, as well as Google
and the AMP team for supporting that project.
Aug 28, 2017
Mon ami Rolando a récemment annoncé la sortie de l’album “Un poquito más”. J’ai apporté ma modeste contribution en écrivant les paroles du titre “Rêve avec moi”. Je vous invite d’ailleurs à visionner le clip de cette chanson ainsi que d’autres vidéos sur la chaine Youtube de Rolando Salsa & Orquesta. Pour les personnes intéressées, cet article contient le texte de la chanson ainsi que des informations complémentaires (mais probablement pas exhaustives… à vous de faire votre propre interprétation!).
Rêve avec moi
À mon ami péruvien.
En sommeil onirique
Je prends mon essor,
Comme un icare mythique
Aux ailes du noir condor!
Les montagnes andines
Je peux survoler,
Machu picchu tes ruines
J'aperçois sous mes pieds!
Rêve avec moi,
De ces paysages splendides!
Contemplons tels des rois
Suspendus dans le vide!
Rêve avec moi,
De ces beaux décors lointains!
Envolons-nous de joie
Vers l'azur péruvien!
Rêve avec moi!
Un songe fantastique
S'élève de mon corps,
Je suis l'inca mystique
Veillant aux cités d'or!
Ses forêts sacrées,
À l'ouest la lave divine
Sort de lamas fâchés!
(Refrain × 2)
Le 28 juillet 2015, Rolando m’envoya la mélodie de la chanson avec un arrangement de guitare. Il ne m’avait pas vraiment fixé de contraintes, si ce n’est un thème joyeux et un refrain facile à retenir. Pendant un mois, il m’a été difficile de trouver le temps et l’inspiration…
J’ai alors pensé à la fois où il avait voulu me dire “j’ai rêvé de toi” en traduisant de l’espagnol “he soñado contigo” (littéralement j’ai rêvé avec toi). Cela m’a donné l’idée d’un thème onirique et d’une invitation au voyage vers son pays, le Pérou. En outre, je me suis souvenu du poème Élévation des fleurs du mal où Baudelaire décrit une ascension de l’esprit
Au-dessus des étangs, au-dessus des vallées, des montagnes, des bois, des nuages, des mers, ce qui allait bien avec la variété et beauté des paysages du Pérou.
Dans la nuit du 29 au 30 août, j’ai donc écrit les paroles en reprenant ces thèmes habituels mais en incluant les symboles et clichés du folklore péruvien (notez que je vous ai épargné le syrinx et le chullo) ! Le refrain à été écrit tout à la fin en quelques minutes, suivant les conseils de Rolando d’avoir quelque chose de simple.
Explication de texte
“sommeil onirique”: allusion aux différentes phases du sommeil, ici un état de rêve.
“Je prends mon essor”: cf le poème de Baudelaire:
… Celui dont les pensers, … prennent un libre essor ….
“icare mythique”: Dans la mythologie grecque, Icare est connu pour avoir volé trop près du Soleil avec des ailes de cire. L’expression “rêve d’Icare” renvoie au désir de voler.
“noir condor”: Le condor des Andes, symbole du Pérou.
“montagnes andines”: référence à la cordillère des Andes qui traverse le Pérou.
“Machu picchu”: la célèbre cité inca au sommet d’un mont de la Cordillère des Andes. Le site est aussi situé aux limites de la forêt amazonienne (cf second couplet).
“tels des rois”: idée des rois dominants le monde au haut de leur tours. Voir aussi “Inca” dans le second couplet.
“l’inca mystique”: Inca désigne à la fois une civilisation précolombienne des Andes et leur empereur. Les Incas vouaient un culte particulier à leur souverain, considéré comme le “fils du soleil”.
“cités d’or”: Allusion au mythe des cités d’or chez les conquistadors.
“amazonie”, “forêts”: référence à la forêt amazonienne qui s’étend sur une partie du Pérou.
“À l’ouest la lave”: La zone volcanique centrale des Andes est due à la subduction par l’ouest de la plaque de Nazca sous la plaque sud-américaine. Petit mea culpa: en réalité, à l’échelle du Pérou, les volcans sont plutôt situés au sud du pays…
“lave divine”, “lamas fâchés”: Référence au célèbre camélidé. Comme dirait l’indien quechua de Tintin et le Temple du Soleil, “quand lama fâché lui toujours faire ainsi”. De la même manière, on retrouve l’image usuelle des irruptions volcaniques comme manifestation de la colère des dieux, qui “crachent le feu”.
Analyse des paroles
Comme indiqué plus haut, le texte reprend les thèmes classiques (si j’ose dire)
du courant romantique:
rêve, imaginaire…: “sommeil onirique”, “mythique”, “songe fantastique”, “cités d’or”, rêve d’“icare”, “rêve avec moi”
mysticisme, spiritualité…: “mystique”, “sacrées”, “divine”
mouvement ascentionel, hauteur…: “je prends mon essor”, “icare”, “ailes”, “condor”, “survoler”, “sous mes pieds”, “rois”, “suspendus dans le vide”, “envolons-nous”, “azur”, “s’élève”
goût de l’ailleurs, invitation au du voyage: “azur péruvien” et toutes les références au Pérou précédemment citées, “rêve avec moi”, “envolons-nous”, “décors lointains”
nature, paysages, beauté, contemplation, plaisir…: “condor”, “montagnes”, “Machu picchu”, “paysages splendides”, “Contemplons”, “J’aperçois”, “beaux décors lointains”, “azur”, “cité d’or”, “amazonie”, “forêts”, volcans (évoqués par la métaphore des lamas fachés), “lamas”, “joie”.
Les couplets sont construits de façon symétrique. Idée de l’état de rêve du narrateur (“sommeil onirique” / “songe onirique”) suivie d’une élévation (“prends son essor”, “S’élève de mon corps” puis d’une personnalisation avec “l’icare mythique aux ailes du noir condor” ou avec “l’inca mystique veillant aux cités d’or” et enfin une admiration des paysages (“montagnes”, “Machu picchu” / “amazonie”, volcans). On notera aussi la métaphore animalière (“condor”, “lamas”).
De la même façon, les deux strophes du refrain sont construites de façons parallèles: “paysages splendides” / “beaux décors”, “Contemplons” / “Envolons-nous”, “vide” / “azur péruvien”. Le refrain forme un condensé des thèmes mentionnés ci-dessus. Il reprend le titre expliqué plus haut, qui lui même contient le “rêve”, “l’invitation au voyage” et implicitement le Pérou (par l’erreur de traduction hispanique).
Comme indiqué plus haut, la chanson est inspirée du poème Élévation. Dans la notice de de la bibliothèque de la pléiade (p. 838-839) Claude Pichois suggère que la fin du poème renvoie au thème des correspondances baudelairiennes. On remarquera que dans la chanson, les métaphores et comparaisons de la nature andine correspondent en effet aux mythes, légendes et dieux de l’imaginaire inca et occidental.
En guise de conclusion, notons que Claude Pichois cite aussi l’essai de Baudelaire sur Wagner où ce dernier raconte ses impressions à l’audition de Lohengrin:
Je me souviens que, dès les premières mesures, je subis une de ces impressions heureuses que presque tous les hommes imaginatifs ont connues, par le rêve, dans le sommeil. Je me sentis délivré des liens de la pesanteur, et je retrouvai par le souvenir l’extraordinaire volupté qui circule dans les lieux hauts
Est-ce qu’à son plus humble niveau, “rêve avec moi” permettra aux amateurs de musique latine d’être transportés vers l’“azur péruvien”… à vous de me le dire ;-)