Web Designer Blog
The latest news and tips from the Google Web Designer team
Masking in Google Web Designer
Friday, November 4, 2016
Investigating Masking in Google Web Designer
Masking routinely tops the list of requested features in Google Web Designer. We investigated different approaches to implementing masking in HTML5, and we concluded that the limitations of existing browsers make effective masking infeasible at this time. We recognize that this is a disappointing result, so we’re using this space to explain (and show!) what we tried, and why we think masking is not yet ready for production.
What is masking?
A mask defines a region of the plane where content (the
) is rendered; outside of this region, the content is invisible. For example, a circular mask may be used to create a spotlight effect, by only revealing content within the "light". A complete masking solution would meet the following criteria:
Everything is maskable.
The maskee may include text, images, animation, SVG, canvases, videos, custom elements, and even other masks.
A mask can have any shape.
It may be as simple as a circle, or it may be multiple disconnected regions with complicated geometry.
Masks can be animated.
The mask can be translated, rotated, and scaled; it can be morphed into new shapes; and in the most general case, the mask can be a video.
Masks stack and overlap.
Placing one mask inside another is equivalent to intersecting the two masks. If two independent masks overlap, the output of one is rendered atop the other, with no other interference.
Events are masked.
Events originating outside the mask are blocked, and otherwise they pass through to the maskee without modification.
What did we try?
There is no way to achieve all of the above properties on any particular browser, much less every browser we support (i.e., Chrome, Firefox, Safari, and IE 10+). We don’t require perfection, however; an approximate solution can still be useful in practice. We initially experimented with
. Smooth mask animation is only possible if the mask is a CSS basic-shape, but otherwise all masking behaviors, such as those listed in the section above, are supported. However, CSS3 masking is not yet available on all major browsers.
Another way to implement masking, which is already supported by all major browsers, is to represent a mask as an element styled with
. This exhibits all masking behaviors, although the mask’s shape is equivalent to the element’s border, which effectively limits masks to rectangles, circles, ellipses, and capsules. Despite this limitation, overflow-based masking would still be useful for basic effects like wipes and reveals. Moreover, on browsers that support CSS3 masking, the mask’s shape could essentially be arbitrary, although animation would still be limited to the element’s transform. Unfortunately, we discovered that even in simple cases, overflow-based masking produced blurring and flickering artifacts on some browsers.
Finally, it’s worth noting that in simple cases, masking-like effects can be achieved simply by overlaying an image with transparent regions, which is already possible in Google Web Designer. This technique, however, is really the opposite of masking -- instead of rendering
within the mask region, it paints over everything that is
in the mask region.
We started by exploring CSS3 masking, which comes in two forms: clipping (clip-path) and masking (image-mask). Clipping crops the rendering of an element and its children to a binary mask defined either through an inlined SVG, or a “basic shape” consisting of a circle, and ellipse, or a polygon. Masking crops the element’s content to an image’s boundary, and then applies an alpha channel determined by the image content. As of this writing, browser support for CSS3 masking is as follows:
on Chrome, Safari, and Firefox, although Firefox’s support for basic shapes is turned off by default.
in Chrome, Safari, and Firefox, but Firefox currently does not allow control over the image’s size or position.
IE does not currently support CSS3 masking, but future support
, at least for Edge.
We tested CSS3 clipping and masking in several different scenarios, and here’s what we found (
Clip paths defined as SVG elements offer the most flexible representation of a mask’s shape, but CSS animations applied to SVG clipping elements are ignored at render time. Basic shapes offer less expressive mask geometry, but at least they can be animated: for circles and ellipses, the centers and radii are interpolated, and for polygons, control points locations are linearly interpolated (assuming that each keyframe has the same number of control points). One quirk is that in some browsers,
must be set on the mask element, or else the clipping path will be ignored if the maskee contains 3D transforms or has animated transforms (2D or 3D).
Masking allows essentially arbitrary mask geometry, but animation of the mask shape is limited to defining CSS keyframes for mask-position and mask-size, allowing the mask to be translated and (non-uniformly) scaled. However, the mask is always rendered with positions and sizes rounded to the nearest integer, resulting in jagginess artifacts when the mask is animated slowly (
In summary, smoothly animatable masks are only possible using clip-path with a basic shape — and even then, currently only in Chrome and Safari.
An alternative to CSS3 masking is to set an element's overflow to “hidden”, and then add the maskee as a child element:
This crops the maskee to the bounds of the parent element. Because the maskee is a child of the mask, however, moving the mask will also move the maskee. To allow them to move independently, we can insert an intermediate element that cancels changes to the mask.
For example, if mask is moved ten pixels to the left,
is moved ten pixels to the right, giving the appearance that maskee remains stationary while the mask reveals a different portion of it. More generally, changes to the mask configuration can be canceled as follows:
The intermediate element is forced to the same size as the mask, by setting its width and height to 100%.
If the mask’s left and top are (x, y), the intermediate element’s left and top are (-x, -y).
The intermediate element’s transform origin is identical to that of the mask, and its transform is the inverse of the mask’s transform.
Similarly, if the mask is animated using CSS3 keyframes, additional keyframes rules must be added to the intermediate layer to cancel this animation. Assuming that animation is limited to transform (per existing
), this means:
Animation of the mask’s transform-origin is copied to the intermediate element.
The inverse of the mask’s transform animation is applied to the intermediate element.
(2) is by far the most complicated part of the process, and as it need not be understood to evaluate the practical effectiveness of overflow-based masking, we discuss it in the Appendix at the end of this post.
We built a
of overflow-based masking, and discovered that even in simple of cases, animating the mask transform produces blurring and flickering artifacts on some browsers. For example, here is a screenshot of Chrome’s output, using a circular mask that translates back and forth (
It appears as if the maskee is first being rendered with the intermediate layer’s transform applied, and then re-rendered with the mask’s transform, resulting in blurring and flickering artifacts. This behavior is not consistent across browsers: as of this writing, the artifacts appear in Chrome in all cases, they appear in Firefox if the animation includes scale or rotation (
), and they do not appear in IE or Safari. However, on all browsers, no artifacts are present if overflow is set to visible, but the mask/intermediate layer/maskee construct is otherwise left unmodified.
Animation of an element’s left, top, width, and height (LTWH) is generally discouraged, and by default GWD uses LTWH for static layout and translation/scale for animation. Still, in light of these rendering artifacts, it’s worth considering whether LTWH makes more sense for masking. One problem with LTWH animation is that it has
than transform animation: dozens of objects can easily be animated at 60Hz using transforms, but will slow down to 10Hz or worse if LTWH is used. If a document only has one or two masks and isn’t too complicated, however, perhaps the performance penalty is acceptable. A second problem is that LTWH values are rounded to the nearest integer at render time, which avoids the rendering artifacts discussed above, but at the expense of creating clunky, stair-step-like animations when objects animate slowly (
We would love to add masking to Google Web Designer, but as an HTML5 authoring tool, we're limited by what browsers are able to support. Still, the web is constantly evolving, and browsers are continually improving, so we still hope and expect to ultimately be able to add masking to our suite of tools.
Posted by Lucas, Software Engineer
Appendix: Inverting animation for overflow-based masking
If a mask is rotated or translated, then an inverse animation can easily be created by reversing the order of each key’s transforms and negating the values of each transform channel. For example, if the mask’s transform is
translate(tx, ty) rotate(rz) scale(sx, sy),
then the intermediate element’s transform is
scale(1/sx, 1/sy) rotate(-rz) translate(-tx, -ty).
If a mask is also scaled, then the inverse scale animation is defined in terms of a reciprocal. For example, a simple linear scaling from s1 to s2 over a time interval T can be written as
and the inverse scaling animation is then
Functions like this cannot be exactly represented in CSS3, which
defines animation curves
as 2D cubic Bezier segments where the first dimension is time and the second dimension is normalized value. While we could simply disallow scaling, this would make it impossible to achieve wipe and reveal effects. Instead, we generate samples of the ideal inverse scale animation
and fit an approximating animation curve. For simplicity, in our experiments we constructed inverse animations as piecewise linear functions, although more compact results can be obtained by fitting general cubic Bezier curves. To determine an acceptable error tolerance for the approximation, consider an absolute error e resulting in a net scale at the maskee of
At a distance
from the transform origin, this yields a positional error of
, and so given a maximum mask size of
, the maximum error
Positional discrepancies can therefore be kept below half a pixel by requiring
Intuitively, the smaller the scale value, the larger the error we can tolerate, because only a narrow slice of content will be visible through the mask. (It is also possible to invert animation of uniform scale by animating z translation, but this technique does not generalize to animations that include non-uniform scaling, and it alters the meaning of existing z translations authored in the maskee.)
google web designer
google cultural institute
google web designer
Google Web Designer training re-launched
New usability features for Google Web Designer
Masking in Google Web Designer
Official Google Blog
Public Policy Blog
Ads Developer Blog
HTML5 Rocks Blog