Der Schepp

Effects for the Web!

2011-12-27T00:00:00Z

In the late nineties CSS 2.1 brought us a basic set of good-enough tools to finally get table-free layouts en route. Then came CSS3 which started off by providing us with more creative tools to carve out the details. Today we finally have embeddeable fonts, rounded corners, gradients, semitransparent elements and colors, box and text shadows and so on and so forth.

Yet, comparing our toolset with that of an image editor like Photoshop we still discover a lot to desire. In Photoshop, for example, we have possibilities to desaturate parts of an image, or to sharpen or blur them. How might we need that for the web? Well, desaturating or blurring an area of a web page might be a means of directing your visitor’s attention to where you want it to be. Or it might help your visitor to concentrate better on an area, which you left untouched. Such a case might be magnifying pictures of a gallery:

A sharpen effect on the other hand might be useful when you scale down images in the browser, since without counter-measures you lose a lot of image details.

That said, it would be nice if we had such effects and could apply them the same way we do apply opacity to tranparentize a whole area. Alas, we don’t.

The status quo #

Instead, to replicate a desaturation/grey scaling we are currently forced to cycle “by hand” through the color values of every affected element with JavaScript and set them to a corresponding grey value. When we meet (background-)images or videos it gets even more complicated: Then we need to switch to HTML5 canvas to manipulate their color-values pixel by pixel and swap out the original ones. But even if we get help from libraries like CamanJS or Hoverizr, it remains a profound messy affair.

A blur effect can also be simulated, this time by using text-shadows and/or box-shadows that use the same color/background-color as the to be blurred text/box. The thing is, the illusion doesn’t work with multicolored boxes and, as before, not with images or video. This requires again some HTML5 canvas action. Sigh.

Speaking of HTML5 canvas: A very brutal approach to that blurring topic is being made by a library called blurry.js, which extracts all the content, recreates it in a canvas (partially via Cufón), blurs it there and injects the whole thing back to where the original content was.

Finally, for sharpening elements there is no CSS-based trick at all, which leaves us alone with HTML5 Canvas.

SVG to the rescue #

Interestingly SVG knows a huge palette of so-called filters since ages, e.g. color blending, brightness/contrast adjustments, lighting, displacement mapping, gaussian and motion blur, clouds, noise, sharpen et cetera.

Now, what we might try, since SVG is more and more widely supported, is to not put our content into HTML, but instead to put it into an SVG which we then inline or embed into out HTML “frame”. Inside that SVG we are then able to apply any effect we like to our contents. The drawback is that a HTMLer won’t be too keen on switching to SVG markup like the following:

<text font-family="Arial"
      font-weight="900"
      font-size="40"
      x="20" y="55%">SVG Example</text>

Something way cooler is an SVG thing called ForeignObject/xlink, which allows us to embed foreign objects or areas of foreign markup inside an SVG. Think of it like inlining SVG into an HTML5 document, but the other way ’round. Once you have embedded your stuff, you can apply filters to it like you can for any other area of your SVG. You might embed and filter a full HTML page from A to Z, or you restrict yourself to just embedding and filtering a single bitmap image. Of course, you’d need to put the holding SVG into an HTML page again, which makes up for some Inception-like braintwister (HTML with embedded SVG with embedded HTML). Browser support of the ForeignObject is quite good. Remains left IE, who will follow suite in version 10 both with SVG filters and ForeignObject.

SVG Filters in HTML via CSS #

Firefox since version 3.5 goes even further. He allows you to reach out to a filter that resides inside an SVG from out your HTML document’s stylesheet and have that filter then applied to any HTML element. We could for example define a feGaussianBlur-filter in an SVG with a radius of 2px and assign it the id gaussian_blur:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="1" height="1" version="1.1"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
    <filter id="gaussian_blur">
      <feGaussianBlur in="SourceGraphic" stdDeviation="2" />
    </filter>
  </defs>
</svg>

Then we could reference that filter by the SVG’s file name and the filter’s id in our styles and have it applied to every image:

img {
  filter: url(blur.svg#gaussian_blur);
}

You find a live-demo here. Alas, as I said, this just works with Firefox.

Thankfully this is not the end of the story. IE also knows filters, although not SVG-based, but instead based on early incarnations of the Windows graphics library DirectX. Amongst those filters are not only the well known alpha oder gradient filters that we use to fix bugs or to replicate CSS3 features. There are also filters that are quite similar to many of the interesting SVG filters:

/* blur by 2 pixels */
filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);
/* 13 pixel motion blur rotated to an angle of 310° */
filter: progid:DXImageTransform.Microsoft.MotionBlur(strength=13, direction=310);
/* grey scale / desaturate */
filter: gray;
/* Röntgen effect (inverted grey scale) */
filter: xray;
/* light cone */
filter: light();
/* emboss */
filter: progid:DXImageTransform.Microsoft.emboss();

You find a full list of those visual filters here.

So, with the help of conditional comments we can now already serve certain effects to two browser families, which together make up a considerable amount of the browser market:

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--> <html lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
</style>
</head>
<body>
  <img src="stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

margin: -2px counters the increased dimensions of the filtered element in IE. zoom: 1 is needed for most filters to work in IE6/7. Sad fact: IE10 won’t support filters anymore :(

Here you find the extended example

As people liked Firefox’s idea to open up SVG filters for use with HTML, those people formed a new task force in the W3C called W3C FX Task Force whose purpose it got to standardize and even simplify usage of SVG filters for use in all browsers. Because Firefox already pioneered filter effects the first draft didn’t take too long to appear under the label of W3C Filter Effects 1.0. The mechanics proposed in that draft work almost like in Firefox, but with the addition of offering shortcuts to some of the most interesting filters. Filters that have a shortcut defined work without the help of an external SVG. They are sort of permanently hard wired inside browser engine. Those are the filters with shortcuts:

grayscale
sepia
saturate
hue-rotate
invert
opacity
brightness
contrast
blur
drop-shadow

Another advantage of the shortcut filters is that they are animateable via CSS transitions or animations:

.foo {
  filter: blur(2px);
  transition: filter 1s ease-in-out;
}

.foo:hover {
  filter: blur(0);
}

This would be much harder and less efficient to do within an SVG.

Finally the filter effects are planned to be extended with OpenGL/WebGL vertex and fragment shaders. Vertex shaders will let you span a 2D mesh over an element and then let you distort the object by moving all the crossing points of the mesh following a mathematical formula of your choice. Fragment shaders on the other hand will allow you to do such mathematical processing on the colors of every pixel of that element. And all of it, on top, hardware accelerated on your graphics card.

Conveniently last week saw the first implementation of those filters in the WebKit-Nightlies, from were they quickly spawned over to Chrome Canary. That means that within a 3 months timeframe CSS filter effects will be available in your everyday Chrome browser and probably not too much later also in Safari. And this means that we are not too far away from being able to serve some flavor of CSS filters to 90% – 95% of all browsers on the market!

Returning to our code example, all that we need to add for WebKit now is a simple -webkit-filter: blur(2px); which for once we need to put after the unprefixed filter-property. The reason is that once WebKit will support an unprefixed filter-property that Firefox-specific syntax in the last line would kill our CSS transition, which we do apply in order to fade nicely from blurred to unblurred and back via -webkit-transition: -webkit-filter 1s ease-in-out:

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie"> <![endif]-->
<!--[if gt IE 9]><!--> <html> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
  -webkit-filter: blur(2px);
  -webkit-transition: -webkit-filter 1s ease-in-out;
}
img:hover {
  filter: none;
  -webkit-filter: blur(0);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
.ie img:hover {
  margin: 0;
  filter: none;
}
</style>
</head>
<body>
  <img src="stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

And here is the final example.

And that’s it, filter effects for everyone! Let 2012 be the year of the CSS filters and have fun playing with’em.

This blog post was originally published at drublic.de/blog/effects-for-the-web/

CSS Masks – How To Use Masking In CSS Now

2012-12-20T00:00:00Z

Almost one year ago I wrote an article that dealt with an emerging WebKit CSS technique, the CSS filter effects, and the question if we could not have/emulate them in other browsers, too. Turned out we could.

Today I want to talk about another WebKit-only feature and show you how you might be able to use it across all of the browsers: This is about…

CSS Masks #

CSS masks were added to the WebKit engine by Apple quite a while ago, namely back in April 2008. Masks offer the ability to control the opacity/transparency of elements on a per-pixel basis, similar to how the alpha/transparency-channel of "24-bit"-PNGs or 32-bit-TIFFs work.

These images consist of the usual R(ed) G(reen) and B(lue) channels that define the colors of each pixel. But on top there is a fourth channel, the alpha channel, that defines every pixel's opacity through luminance: White meaning opaque, black meaning transparent, and countless grey values defining the semi-transparent inbetweens. As you can see in the picture to the left.

With CSS masks it is an HTML element that gets this type of treatment. And instead of using an alpha channel you assign an image resource to a CSS property named -webkit-mask-image, e.g. -webkit-mask-image: url(mouse.png);. Transparency is then read from that mask image and applied to the HTML element, like the picture on the right shows.

Neat! So what could that be good for? Well, masking could be used for images to style them in shapes. Or you could have long scrollable text smoothly fade out by using a mask image with a gradient from opaque to transparent.

As with the background-image property you can also use a CSS gradient instead of an actual bitmap image, as in this code example:

Note: Beware that this is the "old" syntax that will soon be replaced by linear-gradient(to bottom, rgba(0,0,0,1), rgba(0,0,0,0)) (the destination keyword changes to to bottom). Lennart Schoors has a short article on that topic.

-webkit-mask-image: -webkit-linear-gradient(
  top,
  rgba(0, 0, 0, 1),
  rgba(0, 0, 0, 0)
);

While Apple brought CSS masks to WebKit, they failed to specify their implementation details and file a proposal with the W3C. Which means that if other vendors would have wanted to implement masks they would have had to reverse engineer and find out about all the implementation details first. Dirty work nobody wanted to do. So it was not until a few days ago, on the 15th of November (2012), that there appeared a first public working draft by the W3C called CSS Masking. But that one will be rather different to Apple's version.

The good news: Turns out the other browsers do have different capabilities which we can use as hooks to emulate WebKit's proprietary CSS masks. Woot!

Emulating a simple `-webkit-mask-image` cross browser #

So let's say we want to mask an HTML element to the shape of a mouse's head as seen in the picture above.

With WebKit's proprietary CSS masks we would have this HTML:

<div class="element">
  <p>Lorem ipsum dolor sit … amet.</p>
</div>

And define the following CSS:

.element {
  width: 400px;
  height: 300px;
  overflow: hidden;
  color: #fff;
  background: url(background.png);
  -webkit-mask-image: url(mouse.png);
}

The modern browsers #

Let's start with the modern browsers.
Current HTML5-ready browsers are able to parse SVG embedded inline into HTML, like so:

<!DOCTYPE html>
<html>
<body>
  <svg width="300px" height="300px">
    <circle cx="125"
            cy="150"
            r="50"
            fill="pink"
            stroke="green"
            stroke-width="5" />
  </svg>
</body>
</html>

On top of that WebKit as well as Firefox and Opera are also capable of doing the opposite - embedding XHTML into SVG, thanks to SVG 1.1's extensibility feature and its <foreignObject>-element:

<?xml version="1.0" standalone="yes"?>
<svg width="400px" height="300px" version="1.1" xmlns="http://www.w3.org/2000/svg">
  <foreignObject width="400px" height="300px">

    <!-- HTML begin -->
    <div class="element">
      <p>Lorem ipsum dolor sit … amet.</p>
    </div>
    <!-- HTML end -->

  </foreignObject>
</svg>

Internet Explorer 9 and 10 are, the only modern browsers that lack support for <foreignObject>. We will turn to the IEs later.

What inline-SVG and <foreignObject> enable us to do is to enclose certain parts of our page's HTML in SVG wrappers, in this case the HTML blocks we want to mask:

<!DOCTYPE html>
<html>
<head>
  <style>
    .element {
      width: 400px;
      height: 300px;
      overflow: hidden;
      color: #fff;
      background: url(background.png);
      -webkit-mask-image: url(mouse.png);
    }
  </style>
</head>
<body>

  <!-- SVG wrapper begins -->
  <svg>
    <foreignObject width="400px" height="300px">

      <!-- inner HTML begins -->
      <div class="element">
        <p>Lorem ipsum dolor sit … amet.</p>
      </div>
      <!-- inner HTML ends -->

    </foreignObject>
  </svg>
  <!-- SVG wrapper ends -->

</body>
</html>

Next step is to define an SVG-mask inside our inlined SVG that we can feed a mask image, and then apply that via style="mask:[mask id]" to our foreignObject/embedded HTML:

<!DOCTYPE html>
<html>
<body>

  <!-- SVG begins -->
  <svg>

    <!-- Definition of a mask begins -->
    <defs>
      <mask id="mask" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse">
        <image width="400px" height="300px" xlink:href="mouse.png"></image>
      </mask>
    </defs>
    <!-- Definition of a mask ends -->

    <foreignObject width="400px" height="300px" style="mask: url(#mask);">

      <!-- HTML begins -->
      <div class="element">
        <p>Lorem ipsum dolor sit … amet.</p>
      </div>
      <!-- HTML ends -->

    </foreignObject>
  </svg>
  <!-- SVG ends -->

</body>
</html>

And finally we need to have a proper mask image. We cannot simply use the image from WebKit's proprietary CSS mask, since SVG masks do not look at transparency values but at luminance values. So what we need to do is turn all opaque image pixels into shades of white.

In Photoshop that's super easy:

Open the transparent 24-bit-PNG you want to use as mask
Select the "Layer" menu, then "Layer Style" and finally "Color Overlay"
In the "Color Overlay" dialog change the color to white
Close the dialog with "OK"
Select the "File" menu, "Save for web", and replace the old file.

And KABOOOM! Masking of HTML content is up and running in WebKit, Firefox and Opera! Nice.

The Internet Explorers #

Internet Explorers <= 8 do not understand any of the SVG markup above. They will just treat those tags as unknown elements. They will render the page as if it had this HTML code:

<!DOCTYPE html>
<html>
<body>
  <svg></svg>
  <defs></defs>
  <mask id="mask" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse"></mask>
  <image width="400px" height="300px" xlink:href="mouse.png"/></image>
  </mask><//mask>
  </defs><//defs>
  <foreignObject width="400px" height="300px" style="mask: url(#mask);"></foreignObject>

  <div class="element">
    <p>Lorem ipsum dolor sit … amet.</p>
  </div>

  </foreignObject><//foreignObject>
  </svg><//svg>
</body>
</html>

This is cool, since this automatically degrades gracefully.

Where we have a problem is with IE9 and IE10. Both of them know SVG but they do not know the <foreignObject>-element. They render the SVG but consider the part that is enclosed into <foreignObject> was invalid SVG markup. So they discard this part of the SVG altogether. Meaning: our content is lost to our readers. Not good.

We could think about hiding the SVG parts for IEs using conditional comments but Microsoft decided for IE10 that they remove CCs altogether. So no solution yet.

The only solution we have is a) to test the client for the support of SVG extensibility / <foreignObject> and b) have JavaScript render the SVG snippets when SVG extensibility is supported. This is the JavaScript we need, and that we put at the head of our page:

function head () {
  if (window.SVGForeignObjectElement) {
    document.write('\
      <svg width="400px" height="300px">\
        <defs>\
          <mask id="mask" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse">\
            <image width="400px" height="300px" xlink:href="mouse.png"/>\
          </mask>\
        </defs>\
        <foreignObject width="100%" height="100%" style="mask: url(#mask);">\
    ');
  }
}

function foot () {
  if (window.SVGForeignObjectElement) {
    document.write('\
        </foreignObject>\
      </svg>\
    ');
  }
}

And in our HTML markup we need to replace the SVG parts with calls to those JavaScript functions:

<body>
  <script>head();</script>
  <div class="element">
    <p>Lorem ipsum dolor sit … amet.</p>
  </div>
  <script>foot();</script>
</body>

Now content will remain intact in all Internet Explorers that do not support <foreignObject>. Should IE11 support it, it will get to see it.

Note 1: The backslashes you see at the end of lines inside our strings allow for multiline strings. They are supported by every browser and were officially standardized with ECMAScript 5.

Note 2: Isn't document.write the Antichrist of JavaScript best practices? He's nuts! Why is he using it? Well, nothing is just black and white - it all depends on the context. document.write is indeed very very bad if you make use of it in external JavaScript files. document.write forces you to embed external scripts at predefined places of your HTML and prevents almost any attempts of making them load asynchronous. And that means that if these external scripts fail to load, they'll bring your page to a grinding halt. But we are not dealing with an external file here - and you should leave it that way. So there is no blocking. Plus, thanks to having JavaScript outputting the extra markup to the screen while the HTML parser is still running you don't get to witness any flash of unstyled content (FOUC) as it would be the case if you fired a script on DOMContentLoaded. Now back to topic…

We could stop here and all be happy. But how about getting CSS masks working in the IEs, too? Wouldn't that take the cake? Well then, let's go…

Internet Explorers 4 - 9 have a proprietary filter named "Chroma". What the Chroma filter does is comparable to the filmmaker's bluebox / greenscreen technique: it lets pixels of an element in a defined color vanish from the screen. The color is therefore used as a "color mask".

The following CSS code would let disappear all cyan colored parts of an element:

filter: progid:DXImageTransform.Microsoft.Chroma(color='cyan');
zoom: 1; /* Needed in IE < 8 */

Why cyan? Well it is just a suggestion. You are not bound to cyan, you are free to use any color you like as color mask. But this is probably the one color that nobody would ever use to colorize anything, right? So it cannot get mixed up with content that should not be masked.

Now, what's even more interesting with the chroma filter is the fact that the filter does not only look at the colors of the filtered element itself but also takes into account it's children. Because of this one could create some sort of 10px thick frame by applying the following styles:

.parent {
  width: 120px;
  background-color: #eee;

  filter: progid:DXImageTransform.Microsoft.Chroma(color='cyan');
  zoom: 1;
}
.child {
  height: 100px;
  margin: 10px;

  background-color: cyan;
}

to this markup:

<div class="parent">
  <div class="child"></div>
</div>

Then the cyan area of the element .child would be punched out of the filtered element .parent and we could look through it.

So coming back to our mouse shaped example, what we need to do is create a version of the mouse shape image, where the outer parts are cyan and the inner shape is transparent as seen above.

In Photoshop do the following:

Open the existing SVG mask PNG
Hold CMD/Ctrl-key pressed and click on "Layer 0" in the layers window
Press the Backspace key (or the "Del" key on Windows) on your keyboard to remove the white
Select "Invert selection" from the "Select" menu
Click into the "Foreground Color" and change it to #00FFFF (RGB: 0,255,255)
Select "Fill" from the "Edit" menu, take the foreground color as fill
Select the "File" menu, "Save for web"
In the "Save for web" dialog chose "PNG-8" with 2 colors and transparency
Save as separate file, e.g. "mouse-cyan.png"

Saving with just 2 colors removes the anti-aliasing from the shape's borders. The reason we need to do that is because the chroma filter can only punch out one single color.

Now we need to layer that image over the element we want to mask, like in the picture on the right.

A difficulty we face with that is that we need to accomplish this without using CSS's position property. Why? IE's filters disable themselves when they hit positioned elements. The best approach is to work with negative margins in order to slide the cyan mask over the element, e.g.:

<div class="element">
  <p>Lorem ipsum dolor sit … amet.</p>
</div>
<img src="mouse-ie.png" style="display: block; margin-top: -300px;">

And now you would filter the whole thing:

<div style="width: 400px; height: 300px; filter: progid:DXImageTransform.Microsoft.Chroma(color='#00FFFF'); zoom: 1;">
  <div class="element">
    <p>Lorem ipsum dolor sit … amet.</p>
  </div>
  <img src="mouse-ie.png" style="display: block; margin-top: -300px;">
</div>

A sad aspect of this technique is that Microsoft decided besides conditional comments to remove all proprietary filters from IE10. They also removed them from all of the legacy modes. So this solution remains one for IE 4 to 9 only.

In order to serve this to the IEs we need to extend our JavaScript a bit:

function head () {
  if(window.SVGForeignObjectElement) {
    document.write('\
      <svg width="400px" height="300px">\
        <defs>\
          <mask id="mask" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse">\
            <image width="400px" height="300px" xlink:href="mouse.png"/>\
          </mask>\
        </defs>\
        <foreignObject width="100%" height="100%" style="mask: url(#mask);">\
    ');
  } else {
    document.write('\
      <div style="width: 400px; height: 300px; filter: progid:DXImageTransform.Microsoft.Chroma(color=\'#00FFFF\'); zoom: 1;">\
    ');
  }
}

function foot () {
  if(window.SVGForeignObjectElement) {
    document.write('\
        </foreignObject>\
      </svg>\
    ');
  } else {
    document.write('\
        <!--[if lte IE 9]>\
        <img src="mouse-ie.png" style="display: block; margin-top: -300px;">\
        <![endif]-->\
      </div>\
    ');
  }
}

So if <foreignObject> is supported we wrap our element into SVG, if not we wrap it into markup that triggers IE's filters (IE <= 9). In the end this gives us a CSS mask in all browsers except one: IE10. Still pretty awesome, isn't it? Here is the final result:

Mouse shaped mask

Note that this works best when you use masks that use hard clipping along their shape edges. Should you be interested in masks with softer edges then you will lose IE support, as the chroma filter is not capable of punching out shapes with soft edges. Which is okay, too.

In any case, don't forget to check if the outcome without mask applied degrades nicely. Because there is IE10. And because JavaScript might be disabled, too.

Have I really said "all browsers browsers except one"? Ooops, I lied. This is true for desktop. Most mobile WebKit browsers still trail behind technology-wise. Not only Android but also Safari on iOS can't handle our SVG magic well. So for them we will double our SVG mask with -webkit-mask-image. We can assign that in our stylesheet:

.element {
  width: 400px;
  height: 300px;
  overflow: hidden;
  background: #36f url(background.png);
  color: #fff;
  -webkit-mask-image: url(mouse.png);
}

Finally, we are done!

Linear Gradient Masks #

Remember the beginning where I told you that you could also use a gradient as mask? This is also possible in all of the above browsers, with some changes to our setup. First we need to replace the SVG's <mask>'s content either with an image of a gradient or we take the pure SVG route and define a SVG rectangle that is filled with an SVG gradient, like so:

<mask id="mask" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse">
  <linearGradient id="g" gradientUnits="objectBoundingBox" x2="0" y2="1">
    <stop stop-color="white" stop-opacity="1" offset="0"/>
    <stop stop-color="white" stop-opacity="0" offset="1"/>
  </linearGradient>
  <rect width="400px" height="300px" fill="url(#g)"/>
</mask>

This represents a gradient that goes from top to bottom (from X1,Y1:0,0 to X2,Y2:0,1), who's first color stop is a fully opaque white and who's second stop is a fully transparent white.

For IE we don't need a cyan colored image any more since we will not use the chroma filter this time. Instead we will use the "Alpha" filter. We used to use the alpha filter to polyfill the missing opacity property in older IEs. But it is capable of much much more. You can switch it into a gradient mode where you can define start and end points as well as start and end opacities. It's a simple as this:

filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=100,FinishOpacity=0,Style=1,StartX=0,FinishX=0,StartY=0,FinishY=300);

This gradient style alpha filter starts at pixels 0,0 and extends to pixels 0,300. Start opacity is 100%, end opacity is 0%.

On mobile WebKit we should normally be fine with a

-webkit-mask-image: -webkit-linear-gradient(top, rgba(0,0,0,1), rgba(0,0,0,0));

but it turns out that Android 2.x does not support gradients as mask image. We have no choice but to point to a PNG of a gradient, that starts opaque at the top and fades out into transparency to the bottom. Since -webkit-mask behaves like background it repeats images that are smaller than the area to cover. Therefore it is sufficient to use an image with a 1px width and 300px height. Finally to save on HTTP requests we embed the image as data URI with the help of duri.me. So this is the assigment we make in out stylesheet:

-webkit-mask-image: url(data:image/png;base64,iVBORw…[shortedned a bit]…FTkSuQmCC);

And the following are the changes to our JavaScript:

function head () {
  if (window.SVGForeignObjectElement) {
    document.write('\
      <svg width="400px" height="300px">\
        <defs>\
          <mask id="mask" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse">\
            <linearGradient id="g" gradientUnits="objectBoundingBox" x2="0" y2="1">\
              <stop stop-color="white" stop-opacity="1" offset="0"/>\
              <stop stop-color="white" stop-opacity="0" offset="1"/>\
            </linearGradient>\
            <rect width="400px" height="300px" fill="url(#g)"/>\
          </mask>\
        </defs>\
        <foreignObject width="100%" height="100%" style="mask: url(#mask);">\
    ');
  } else {
    document.write('\
      <div style="width: 400px; height: 300px; filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=100,FinishOpacity=0,Style=1,StartX=0,FinishX=0,StartY=0,FinishY=300); zoom:1;">\
    ');
  }
}

function foot () {
  if (window.SVGForeignObjectElement){
    document.write('\
					</foreignObject>\
				</svg>\
			');
  } else {
    document.write('\
				</div>\
			');
  }
}

Radial Gradient Masks #

Radial gradients are possible as well. Let's say we wanted to mask an image of 400px × 400px:

<body>
  <script>head();</script>
  <img src="photo.jpg" width="400" height="400" alt="Dude">
  <script>foot();</script>
</body>

Then we would need to change our SVG mask to this:

<mask id="mask" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse">
  <linearGradient id="g" gradientUnits="objectBoundingBox" x2="0" y2="1">
    <stop stop-color="white" stop-opacity="1" offset="0"/>
    <stop stop-color="white" stop-opacity="0" offset="1"/>
  </linearGradient>
  <rect width="400px" height="400px" fill="url(#g)"/>
</mask>

And switch the alpha filter to style=2, the "2" standing for radial shape:

filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=100,FinishOpacity=0,Style=2);

Translated to our script, this is how it would look like:

function head () {
  if (window.SVGForeignObjectElement) {
    document.write('\
      <svg width="400px" height="400px">\
        <defs>\
          <mask id="mask" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse">\
            <radialGradient id="g" gradientUnits="objectBoundingBox" cx="0.5" cy="0.5" r="0.5" fx="0.5" fy="0.5">\
              <stop stop-color="white" stop-opacity="1" offset="0"/>\
              <stop stop-color="white" stop-opacity="0" offset="1"/>\
            </radialGradient>\
            <rect width="400px" height="400px" fill="url(#g)"/>\
          </mask>\
        </defs>\
        <foreignObject width="100%" height="100%" style="mask: url(#mask);">\
    ');
  } else {
    document.write('\
      <div style="width: 400px; height: 400px; filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=100,FinishOpacity=0,Style=2); zoom: 1;">\
    ');
  }
}

function foot () {
  if (window.SVGForeignObjectElement) {
    document.write('\
					</foreignObject>\
				</svg>\
			');
  } else {
    document.write('\
				</div>\
			');
  }
}

For mobile WebKits we again create a bitmap of a radial gradient. To save a little on bytesize it is sufficient to use an image with the dimensions 50px x 50px. To have that mask stretch over our 400px × 400px object we need to also set -webkit-mask-size: cover.

img {
  -webkit-mask-size: cover;
  -webkit-mask-image: url(data:image/png;base64,iVBORw0…[shortened a bit]…lFTkSuQmCC);
}

Final Words #

I admit it wasn't the shortest of all articles but I hope I got you interested in playing around with masks on the web. So if you happen to create some decent stuff with the aforementioned techniques please drop us a note on Twitter. Also if you have any further questions regarding masks, don't hesitate to give me a shout.

This blog post was originally published at thenittygritty.co/css-masking

Dealing with Ads in 2020

2019-12-01T00:00:00Z

As you may know, I currently work for a news company in Germany, the Rheinische Post Mediengruppe. My task there is to concept and build the frontend for a bunch of news sites in the form of a white label framework. Sadly, but not surprisingly my client is still depending on ads to generate revenue. Which is why we wanted to adjust our frontend to be in a better position to deal with them. Mostly because...

Ads suck! #

And there are many ways in which they suck:

Ads are still sold to customers as fixed-sized canvases, counteracting the idea of true responsiveness.
Ads have a substantial negative impact on a site's performance, be it render time, time to interactive, or general input lag.
Ads take a massive toll on user happiness due to all the layout shifts they create, which make people lose their focus and which break the back button experience.
So-called skyscraper or wallpaper ads tend to make sure that they are always visible even if this means that they cover essential site UI like the header or menu.
And ads sometimes turn out to be trojan horses who's innards try to steal sensitive data from you without you noticing.

Oh yes, ads really are a kind of its own. But for us, there was no way around them, so we needed to find ways to work with them and to minimize their impact.

Ads & Responsiveness #

Back in the days, the newspaper I work for had a standard website for desktops and an mdot site for mobile. This setup made integrating ads into the site pretty straight forward, because we knew when to send the ad code for desktop devices and when the one for mobile devices. But maintaining two separate sites has a lot of drawbacks, too:

you need to develop many features twice
you constantly have to keep your list of devices and corresponding user agent strings up to date to continue sending visitors to the right site
you constantly had to troubleshoot your URL scheme.

These drawbacks were the reason why for our relaunch, we wanted to go the responsive route, which would make user agent sniffing redundant, too.

We had to find a way to send down the ad codes both, for desktops and for mobile devices, down the wire and then to have the client somehow sort out which one of the two to execute. Not too hard to achieve. But now comes the real challenge: The people working in the ads division putting corresponding code into our site are no programmers. They do get isolated code snippets via email or from documentation, either for a mobile or a desktop ad and all they do is paste those into textareas labeled "mobile ad code" and "desktop ad code". They are not able to transform and combine them into one responsive ad loading code. We had to develop a generic solution that would handle the task.

One way to do this is to leverage the power of Web Components by putting both snippets in separate <template> elements and then to import the correct one into the current DOM, like so:

<div class="ad">
  <template class="ad__mobile">
    // Mobile ad HTML code with inline script
  </template>
  <template class="ad__desktop">
    // Desktop ad HTML code with inline script
  </template>
  <script>
    const isMobile = matchMedia('(max-device-width: 20em)').matches;
    const ad = document.currentScript.closest('.ad');
    const content = ad
      .querySelector(isMobile ? '.ad__mobile' : '.ad__desktop')
      .content;

    ad.appendChild(document.importNode(content, true));
  </script>
</div>

Note that you can't go "all in" with Web Components and make it a full custom element, as ads often rely on being able to reach into the rest of the document. Browser support for the above is quite good, with only IE and Edge < 15 not supporting both document.currentScript and document.importNode at the same time.

The above was not the route we chose, though. When we started developing our site in late 2017, Web Components support in Edge was not yet there and we still had a considerable amount of IE traffic that we wanted to monetize. So our approach was a different one. The way to go was still to deliver both ad codes but to use document.write to render one of them useless at parse time. One idea would have been to use an HTML comment, like so:

<div class="ad">
  <script>
    (function() {
      var isMobile = matchMedia('(max-device-width: 20em)').matches;
      if (!isMobile) {
        document.write('<!--');
      }
    })();
  </script>
    // Mobile ad HTML code with inline script
  -->
  <script>
    (function() {
      var isMobile = matchMedia('(max-device-width: 20em)').matches;
      if (isMobile) {
        document.write('<!--');
      }
    })();
  </script>
    // Desktop ad HTML code with inline script
  -->
</div>

The closing comment declarations would be hardcoded into the HTML (-->), whereas the opening declarations would be inserted depending on the device type (<!--), thereby disabling the code in between. But again, this wasn't good enough. Since our people managing the ads would probably just copy & paste code into the respective CMS textareas, we were fully prepared for them to also carry over any HTML comments that they would come across in their code snippets. Just one such occurrence would be enough to transform our whole site into a Frankenstein, due to messed up HTML nesting.

I remembered one more discovery I made a few years back, in regards to HTML, and that was the <xmp> element. This tag has been marked deprecated in HTML 3.2 and completely removed in HTML 5. But browsers still support it. The <xmp> was once meant to display preformatted text and was superseded by the <pre> element. But <xmp> has one huge advantage over <pre>: it does not need HTML to be entity encoded inside it. Similarly to the <template> element, it mutes the effect of any contained HTML, with the only difference being that it would visibly show up in the browser and not hide itself. And the probability of an ad code to break it with a closing </xmp> tag is close to zero. This is the code we went live with:

<div class="ad">
  <script>
    (function() {
      var isMobile = matchMedia('(max-device-width: 20em)').matches;
      if (!isMobile) {
        document.write('<xmp>');
      }
    })();
  </script>
    // Mobile ad HTML code with inline script
  </xmp>
  <script>
    (function() {
      var isMobile = matchMedia('(max-device-width: 20em)').matches;
      if (isMobile) {
        document.write('<xmp>');
      }
    })();
  </script>
    // Desktop ad HTML code with inline script
  </xmp>
</div>

And it worked like a charm, except for Firefox complaining about having to render an unbalanced DOM tree:

Lazy Loading Ads for better performance #

But our ad people would not be who they are if they didn't crank the difficulty level up one notch. After a certain amount of time they asked if it would be possible to have ad slots loaded lazily, when they scroll into view. Because some ads pay off only when they are seen by the user, not when they are loaded. So from a performance standpoint it makes total sense to only load them on demand.

Triggering actions once an element enters the viewport got pretty easy nowadays thanks to the Intersection Observer API (and the available polyfill). The more difficult problem to tackle was how to postpone the execution of arbitrarily shaped scripts into the future. As you might know, just reading out the ad's HTML snippet and injecting it into the DOM via .innerHTML would not execute contained <script> elements. One possibility could have been to parse out any script tags, to recreate them via document.createElement, and then to append them. But then again, how would we handle document.write? Since our base document has finished parsing and is now considered "closed", such a late document.write would replace the whole document, instead of just adding little pieces to it. A <template> element together with document.importNode could solve the problem, but as already outlined above, they are not (yet) an option for us. But I stumbled upon one more interesting DOM feature capable of helping me out: the Range object and its .createContextualFragment() method, creating a, well, Contextual Fragment.

TIL: Unlike innerHTML, if you create elements using createContextualFragment, scripts will execute https://t.co/CfqYAu5pZr (ht @zcorpan)
— Jake Archibald (@jaffathecake) 7. Dezember 2016

And here is how I put it to use (Media Queries and IntersectionObserver code are left out for the sake of a better understanding of the range technique):

<div class="ad">
  <xmp class="ad__mobile">
    // Mobile ad HTML code with inline script
  </xmp>
  <xmp class="ad__desktop">
    // Desktop ad HTML code with inline script
  </xmp>
  <script>
    (function() {
      // We know we must be the last .ad element in the document
      var ads = document.querySelectorAll('.ad');
      var ad = ads[ads.length - 1];
      var xmp = ad.querySelector(isMobile ? '.ad__mobile' : '.ad__desktop');
      var activateCode = function activateCode(html) {
          var range = document.createRange();

          range.setStart(ad, 0);
          ad.appendChild(range.createContextualFragment(html));
      }

      activateCode(xmp.textContent);
    })();
  </script>
</div>

The above snippet enables us to have <script> elements in our code and even document.write and it is easily combined with an Intersection Observer for a lazy load approach. On top of it all, since we do not need to dynamically open <xmp>sections anymore, Firefox stops complaining about the unbalanced DOM tree.

One thing we did not account for, though, is that externally loaded scripts can also contain document.write. Those document.writes won't be caught by our Contextual Fragment, as these scripts are only loaded and executed after we injected and executed our initial code block. External scripts doing document.writes do not happen very often, but unfortunately often enough to consider them. Since we really liked what we saw, we didn't want to give up. We rolled up our sleeves and went ahead to patch document.write.

We had to patch document.write into something that

a) would catch what was supposed to be written into the DOM, then
b) create another Contextual Fragment with that content, which would
c) be appended right after the script calling it.

Here is how that came together:

  (() => {
    // We store the original since we still need
    // it outside of ad containers
    const originalDocumentWrite = document.write;

    document.write = (html) => {
      const sourceScript = document.currentScript;
      const div = document.createElement('div');
      const range = document.createRange();

      // if document.write is called from the console, or
      // if document.write is not called from inside an
      // ad container delegate back to the original one
      if (!sourceScript || !sourceScript.closest('.ad')) {
        // .apply() is needed to reinstate the right context
        originalDocumentWrite.apply(document, [html]);
        return;
      }

      range.setStart(div, 0);

      sourceScript.after(range.createContextualFragment(html));
    };
  })();

The above code uses ES6 as this time it is not an inline script and so can be transpiled. And I am using .closest() and .after(), which you need to polyfill in older Edge browsers, as well as document.currentScript).

Okay, NOW we're finally done. Now we have responsive, and lazily loadable ad slots that work for any type of copy & paste code snippet in the world!

"But what about tablets?", you may ask. Valid remark! For advertisers the tablet category does not exist. For them there is just desktop or mobile, nothing in between. This differentiation means it is upon you as a publisher to decide which of those two categories to serve to tablet users. Since desktop ads bring more revenue, we chose to serve those to tablet users. Now, not every tablet offers the screen size to flank our main content with skyscrapers and the likes. But those bring most of the money!

Our solution was to manipulate the viewport meta tag in a way that we force tablets into creating a virtual drawing canvas of 1325 pixels, similarly to what they fall back to when no viewport meta tag is set at all:

  <meta name="viewport"
        content="width=device-width, initial-scale=1">
  <script>
    // If tablet or bigger, fix viewport to create space for the ads
    // Our cut-off point was at a width of 725 pixels
    // (also see: http://mydevice.io/#compare-devices)
    if (
        window.matchMedia &&
        matchMedia('screen and (min-width: 45.3125em)').matches
      ) {
      // In the first step we also turn off user scaling
      // so that the browser zooms out
      document
        .querySelector('meta[name="viewport"]')
        .setAttribute('content', 'width=1325, user-scalable=no');

      // Then we re-enable zooming
      window.setTimeout(function () {
        document
          .querySelector('meta[name="viewport"]')
          .setAttribute('content', 'width=1325');
      }, 1000);
    }
  </script>

Politely bowing out when the user's connection is constrained #

Sometimes your connection happens to be super slow. You don't need to live in poorer regions of the world to experience slow connections. Reasons can be:

someone's allocated high-speed traffic volume for the current month is depleted
someone is part of a mass gathering and the network is overloaded (e.g. New Year's Eve)
someone travels by train having a super flaky connection (looking at you, Deutsche Bahn)
someone is on vacation in rural areas (like I experienced each time we were on vacation at a farm), or
a European travels to Florida, his/her 4G phone doesn't support the US frequencies and falls back to the next slower available connection speed, which turns out to be 2G, as Florida already got rid of its 3G network in favor of 4G (exactly this happened to poor me two years ago)

In those situations it is not desirable to still have ads compete on bandwidth against the main content of your site. Even less so with news sites as sometimes they spread vital information, like informing people when a sgnificant incident happened and what to do. If we leave ads on even at 2G speeds, chances are that neither those nor our main content will ever load.

We wanted to take the user connection into account using the Network Information API. If this API is available we check a visitor's effective connection speed:

const hasFastConnection = () => {
  // Let's also prepared for offline scenarios
  if (navigator.onLine === false) {
    return false;
  }

  // Mark the connection as slow if it falls into the 2G category
  if (navigator.connection && navigator.connection.effectiveType) {
    switch (navigator.connection.effectiveType) {
      default:
        return true;

      case 'slow-2g':
      case '2g':
        return false;
    }
  }

  return true;
};

const initAds = () => {
  if (!hasFastConnection()) {
    console.info('Disabling ads due to slow connection');
    return;
  }

  // initialize the ads
};

You can try it out yourself by throttling the network in Chrome Devtools to "Slow 3G" and then go visit rp-online.de.

According to the Chrome User Experience Report, this affects 0.02% to 0.03% of our visitors, which, given that we hover around 60M page views per month, still amounts to 12K views.

Bringing stability back to layout #

One other side effect of having ads on your page is that slots pop open once an ad gets loaded into them, thereby pushing the content below it and to its side around. The same happens if you use fixed-sized placeholders in slots and it then turns out that there is no ad with those dimensions left in the pool to deliver, but only smaller or taller ones. Then the slot shrinks or grows, pushing things around. Usability suffers tremendously as the human eye constantly loses orientation and the browser needs to re-layout the page each time (including paint and compositing). Most browsers try to compensate for it through a technique called "Scroll Anchoring", but there are limits as to how good that works. The Chrome team recently added a new performance metric they call "Cumulative Layout Shift" which aims to quantify these problems.

What we did was introducing a new type of placeholder slot, that would always be as large as the largest possible ad format it is configured for, and that would turn any loaded ad inside of it into a position: sticky element that would slide along with the user scrolling the page:

That way, we get around the need to resize the slot once the ad is loaded, thereby reducing the layout shift.

One thing you need to know though with position: sticky-elements which is not mentioned a lot around the internets, is that it stops working the moment one of the ancestors uses overflow: hidden. It turned out we had quite had few elements on our page set to overflow: hidden, mostly to clear floats or to stop things from exceeding the horizontal boundaries of the page on mobile. So we had to refactor these.

In order to find ad slots that are affected with such a constellation, we created the following snippet which we could run in the browser console:

[...document.querySelectorAll('.ad')].forEach((adSlot) => {
  const problematicParents = [...document.querySelectorAll('*')]
    .filter(elem => elem.contains(adSlot))
    .filter(elem => getComputedStyle(elem)
                        .getPropertyValue('overflow') === 'hidden');

  if (problematicParents.length) {
    console.warn('Sticky will break in slot:', adSlot, problematicParents);
  } else {
    console.info('Sticky will work in slot:', adSlot);
  }
});

Now we still needed to find a solution for when there's no remaining ad in the ad server pool. In the past, when that was the case, we collapsed the slot. Our new approach is to have "backup" ads of our own to serve when this happens. These can be ads for our own offers or it could be a piece of usage info about your site, or it could be ads for a good cause, e.g. organizations that can't afford booking ads on larger news sites.

Winning the z-Index Wars #

As mentioned in the introductory section a few types of ads tend to break out of their given place and to cover up important site UI like the header or the navigation. Typical candidates are (sticky) skyscrapers flanking the page that extend to the top and bottom of the viewport, ignoring that there might be a header bar that they shouldn't cover. Another ad format is the fireplace ad that tries to lay itself all around the content: to the left, to the right and above. Covering up navigation leads to people feeling like they lost control over the site.

And then there are ads which do sit where they are supposed to be but that boast such a high z-index that they will even sit there when you've opened your off-canvas menu and then they'll cover that up, too. While there are guidelines by the IAB, the "Interactive Advertising Bureau", on which z-indexes to use as a site owner and which ones to use as an ad creator, seeing what crap comes in over the ad servers makes me have no faith in that standard being applied correctly. Which is why we prefer to take things into our own hands.

What we noticed was that all those ads that ended up covering up things were accessing document.body to append themselves to it. That's when we got the idea to patch document.body! Instead of returning the <body> element, we would return a <div> that extends over the whole surface of the <body> element, but that would come equipped with z-index: 0. And then those ads would become children of that element instead. What seemingly only a few people know is that once a parent of an element is already part of a stacking context child elements cannot stick out higher in the stack than the parent. So now even ads with a z-index in the millions range could not go higher than the stacking height of that new element, which was 0. We then equipped our header with z-index: 4 and our off-canvas menus with z-index: 3 and from that moment on they remained forever uncovered. And how did we patch document.body? With a property getter, supported in all relevant browsers:

Object.defineProperty(document, 'body', {
  get: function () {
    return document.querySelector('.fakebody');
  }
});

Of course, what this meant for us was to revert to document.querySelector('body') every time we wanted to access body ourselves. But that was feasible.

Shielding our Users #

(at least a little bit)

In an ideal world, what we would do is to lock every ad into either an iframe or a Web Component custom element to block it from accessing the rest of the page. In practice, we can not do this, as a lot of ads rely on being able to reach outside of their initial slot. An ad could, for example, turn out to be a fireplace ad which in turn needs to add plenty of graphic elements on all sides and also needs to move the content area of the page around. Or there are so-called "understitials", which open up a hole in your text content, through which to see the ad. Or you have a sticky ad that needs to attach itself to the body. So we cannot restrict them.

Restricting access would be wise, though, as these ads can observe you and read out everything that you type into any sort of input field. And they do! For example, they try to trigger your browser's form autofill feature or hope for autofill to just run to get very sensible data. Maybe to fingerprint and track you across different sites. Maybe to sell your profile data, who knows. And other types of third party scripts do too! If you use the Facebook pixel, it constantly reads out every input you do on the page. The same goes for Google's Recaptcha. Maybe they do that to ensure you are not a robot. Maybe not.

Since we don't want that to happen and we could not lock out the third party, we had to do something else. And again we patched a browser built-in, and this time it was input.value:

(() => {
  // This will hold a list of CSS selectors of inputs,
  // that can be read out the standard way:
  const allowedSelectors = [];

  // Store the real value access
  const realValue =
     Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, 'value');

  // Remap the former .value to a new .realValue property
  Object.defineProperty(HTMLInputElement.prototype, 'realValue', {
    get() {
      return realValue.get.call(this);
    },
  });

  // Create a new behavior for .value via getter
  Object.defineProperty(HTMLInputElement.prototype, 'value', {
    get() {
      // Go though the allowlist and if a selector matches,
      // return the real value
      for (const selector of allowedSelectors) {
        if (this.matches(selector)) {
          return realValue.get.call(this);
        }
      }

      // Otherwise send an alarm and return an empty value
      console.trace('A script just tried to access an input\'s value', this);
      return '';
    },
  });

  // Create an interface with which one can
  // mark certain forms as okay via CSS selector
  window.safeInputs = {
    allowSelector: (selector) => {
      allowedSelectors.push(selector);
    },
  };
})();

What we basically did there was making .value to always return an empty string and hiding the real value behind a new property accessible via .realValue. This allowed us to still read out the form inputs in our own code. On top of that we had an alarm in the console together with a console.trace to find the code that tried to access the input. And finally we added the possibility to allow certain inputs to stay readable (window.safeInputs.allowSelector), as from time to time we have a quiz or something that is not programmed with our patch in mind. This works by handling it a CSS selector à la .quiz input:window.safeInputs.allowSelector('.quiz input') . Now, if you access an input that matches .quiz input, the value stays readable.

The patch does not change anything in regards to normal HTML-based form submission and you can also use the FormData API as normal. Still, the above change is enough to cover almost all third party situations as they never use anything else than .value.

Closing Notes #

Working with ads is messy and also a bit delicate, because you don't wanna break stuff in a way that cuts off revenue (e.g. break an advertiser's measurement tools). One thing on our list is to take on common scripts like Google's osd.js or Meetrics' mtrcs.js monitoring tool, as both tend to burn most of our CPU cycles.

We think we'd like to probe them to see where exactly they waste processing time. We hope that force-debouncing scroll events and mapping layout trashing reads to less expensive, maybe even async methods in the background will manage to reduce the pressure on our site.

What we would wish for even more is for companies like Google and Meetrics to put out their code on Github and to allow people to send them pull-requests that improve it. But this will never happen.

Do you have similar experiences with ads? Have you also tried decreasing the harm they do on your site? If so, I'd love to hear from you on the Twitters! My handle is @derSchepp.

A thousand thanks go out to Stefan Judis, who was so kind to check this huge post ❤

The cover image of this post is Lord of The Rings • Mordor • Mount Doom • Eye of Sauron by Muna

A CSS-only Carousel

2019-12-08T00:00:00Z

I've recently read about and discussed CSS Scroll Snapping so often that I felt like I should build a CSS-only carousel based on it. There it is:

Link to Codepen

Here are a few things to note: #

Accessibility is in line with all other CSS-only experiments: it can only be considered mediocre in term of semantics and visual indicators. Don't do this in production.

The going forward and back is done via a combination of CSS Scroll Snap together with scroll-behavior: smooth and moving the focus through the slides via anchor links.

The nicest trick I pull off is the one for the auto-forward:

first I slowly offset the scroll snap points to the right, making the scroll area follow along due to being snapped to them.
after having scrolled the width of a whole slide, I deactivate the snapping. The scroll area is now untied from the scroll snap points.
Now I let the scroll snap points jump back to their initial positions without them "snap-dragging" the scroll area back with them
Then I re-engage the snapping which now lets the scroll area snap to a different snap point 🤯 Whatever... look at the code 🙃

The cover image of this post is Carousel spinning in Sunset by bubutu

Today, the Trident Era Ends

2020-01-15T00:00:00Z

When I was a child, I was always fascinated by stories about ancient civilizations. I devoured books about Atlantis, or the story of Heinrich Schliemann's discovery of Troy, stories about the Greek, the Romans, the Inca Empire, or Ancient Egypt. And I was always fascinated by the extent of their capabilities in the fields of astronomy, math, and medicine, their incredible achievements, like building those vast monuments, or their highly functional social systems. What's even more incredible is that most of this already happened way before Jesus Christ first set foot on our earth!

And yet, all these eras of highly developed civilizations one day came to an end. Some just died out quietly, some were outpaced by civilizations with better military capabilities. Most of the time when that happened, the capabilities of the defeated ones did not carry over to the now dominating group, thereby enriching their pool, but instead vanished. Which I always found unfortunate.

The Era of the Trident Engine #

Starting now, Microsoft will roll out their new Chromium-based Edge browser to their millions of Windows 10 users. And this will also mark the end of an era. The era of the Trident-Engine.

But hadn't the Trident era already ended when Edge appeared? Not really.

When Microsoft created the Edge browser in 2015, what they really did was to fork Trident into EdgeHTML and to strip out plenty of legacy code paths like ActiveX (Microsoft's version of Java Applets) or emulation of older IE rendering engines. Both browsers sharing the same genes gets apparent when you read posts like these on the Edge Blog or when you see bug reports that similarly affect IE 11 as well as Edge 17. Most of the initial Edge improvements came from Chakra, the JavaScript engine, whereas only a moderate few could be attributed to the rendering engine itself. Renaming the browser could be considered more of a marketing move, though, as the removal of legacy features already started earlier, when the browser was still called Internet Explorer.

Rebooting Internet Explorer under a new name didn't win back the hearts of the web developers. Up until today Microsoft remained busy playing catch up. Therefore, when we get excited about the web platform nowadays, it is not because of a new Edge release but because of Google unveiling new ideas or APIs during Google I/O or the Chrome Dev Summit. A lot of these innovations are driven by other teams at Google working on Google frameworks like Angular and AMP, or on Google products like Gmail, Search, Drive, Maps, Google Docs, Analytics or in recent times: Lighthouse. In fact, a lot of what defines HTML5 can be rooted back to Google looking for a way to improve the web platform to better accommodate its ideas around web apps. Remember Google Gears? Or later Google Chrome Frame?

Funnily that same kind of process also drove innovation in Internet Explorer in the old days. ActiveX capability was added to Internet Explorer 3.0, together with the <object> tag, to offer one more "compile target" for Microsoft's own Java competitor. It was certainly not the IE team that came up with this idea. Or take what we know today as "AJAX": the idea of lazily fetching content in the background via JavaScript was born in the Exchange / Outlook Web Access team, a product that could be seen as a precursor to Gmail. After pulling a few tricks inside Microsoft they got it (silently) shipped with Internet Explorer 5.0 in 1999. It wasn't until 6 years later that the term AJAX was coined and its concepts became widely known.

we pretty quickly struck a deal to ship the thing as part of the MSXML library. Which is the real explanation of where the name XMLHTTP comes from- the thing is mostly about HTTP and doesn't have any specific tie to XML other than that was the easiest excuse for shipping it so I needed to cram XML into the name (plus- XML was the hot technology at the time and it seemed like some good marketing for the component).

The same goes for document.designMode (apparently a wish coming from the Hotmail team) & contentEditable, the DOM the Drag-n-Drop API, iframes or Clipboard Access. Internet Explorer was also the first browser to have permission prompts:

Back in the days, Microsoft was single-handedly pushing the web forward, with around 1.000(!) people working on Internet Explorer and with a 100 million dollar budget to burn per year, with almost no-one left to compete. This was massive!

[Scott] Isaac also invented the iframe HTML tag. It has been speculated that the tag name stands for the Isaacs Frame, although Scott has denied this.

The last time Internet Explorer introduced new features driven by other business units was in 2012. At that time Windows 8 introduced the Windows Store and corresponding Windows Store Apps. Those apps could be written once and could then be run on Windows, Xbox and Windows Phone. Since Microsoft was late to the app store game, they had to put the entry barrier for developing apps as low as possible, so they got the idea of allowing people to develop apps with web technologies. As a communication path to the underlying OS, they created a JavaScript library called "WinJS" and Internet Explorer 10 was meant to be the runtime environment for those apps.

But to be able to model the Windows UI with web technologies, Microsoft had to add plenty of new capabilities to IE: CSS Grid, CSS Flexbox, CSS Scroll Snap Points and the Pointer Events API for touch and stylus interactions (the latter one was required as Apple had filed a patent on the Touch API).

Microsoft even invented what later became Origin Trials, as documented in a podcast interview we did with Jacob Rossi from the Edge team in 2015.

Coming back to my introductory part on ancient civilizations and their achievements: For me, it feels like Internet Explorer already had many of the things that we came to reinvent later and that we now celebrate as innovations. Although our modern reinventions offer more features combined with better developer experience, I came to wonder why we, as a community, only picked up very few of them. The ones mentioned above were picked up - either because browsers were striving for compatibility with IE or because Microsoft was at the right place at the right time. But a lot more were not!

The Forgotten Parts #

MHTML #

The first one on the list is MHTML. MHTML or "MIME encapsulation of aggregate HTML documents" was meant as a packaging format. It shared a lot of concepts with how email clients append attachments to an email. MHTML would take an HTML file and inline all of its resources like CSS, JavaScript files or images via base64 into extra sections. So it was basically data URIs, but on steroids. You could also see MHTML as the precursor of Web Bundles. The format was supported from IE 5 onwards, as well as in Presto-based Opera. No other browser officially supported MHTML, but Chromium added the feature later behind a flag called chrome://flags/#save-page-as-mhtml. MHTML was proposed as an open standard to the IETF but somehow it never took off.

Fun fact: Did you know that Outlook Express used MHTML inside the .eml email message files, which it used to store emails together with their corresponding attachments on your disk?

Page Transition Filters #

Internet Explorer had page transition filters which you would define as HTTP header or in the form of a meta tag:

<meta http-equiv="Page-Enter"
      content="RevealTrans(Duration=0.600, Transition=6)">

As the name implies, such a filter would smoothly transition the user from page to page upon navigation, instead of having pages appear as abruptly as we are used to. There was an extensive list of transition filters you could choose from by referencing them via number:

0 - Box in
1 - Box out
2 - Circle in
3 - Circle out
4 - Wipe up
5 - Wipe down
6 - Wipe right
7 - Wipe left
8 - Vertical blinds
9 - Horizontal blinds
10 - Checkerboard across
11 - Checkerboard down
12 - Random dissolve
13 - Split vertical in
14 - Split vertical out
15 - Split horizontal in
16 - Split horizontal out
17 - Strips left down
18 - Strips left up
19 - Strips right down
20 - Strips right up
21 - Random bars horizontal
22 - Random bars vertical
23 - Any random pattern

In addition to Page-Enter you could specify additional transitions for Page-Exit, Site-Enter and Site-Exit. Those soft transitions between pages are something that we see reappearing in the form of Portals or the Page Transition API.

Object Transition Filters #

Similarly to how you could use filters to transition between pages, you could also transition between two states of the same DOM object. This is similar to Rich Harris' ramjet, only that it would not morph between two states, but instead blend over with a movie-like "cut".

What you could also do with those object transition filters is something similar to CSS Transitions or to an animated CSS crossfade() function.

You would start off with applying a blend filter to the element (with a duration of 600ms):

img.style.filter = 'blendTrans(duration=0.600)';

Then, before making any change to the object, you would freeze its current state:

img.filters.blendTrans.apply();

Finally you would change the image source and trigger the transition:

img.src = 'different-src.jpg';
img.filters.blendTrans.play();

Effects Filters #

The filter category most people still remember from Internet Explorer 4+ is effects filters. In 1997 they already offered, although in a lower fidelity, what CSS Filters brought to the table when they first appeared in 2012 in Apple Safari 6.

You could also use Internet Explorer's Matrix Filter to do things that would later be introduced by CSS Transforms:

transform: rotate(15deg);
filter: progid:DXImageTransform.Microsoft.Matrix(
            M11=0.9659258262890683,
            M12=-0.2588190451025207,
            M21=0.2588190451025207,
            M22=0.9659258262890683,
            SizingMethod='auto expand');

Or, you could use the Chroma Filter to key out certain color pixels of an element in order to create rounded corners or to apply masking.

Gradient Filter #

You always though Internet Explorer 10 was the first version to support gradients? Not entirely true, there was a CSS filter for that, too:

filter: progid:DXImageTransform.Microsoft.gradient(enabled='false',
                startColorstr=#550000FF, endColorstr=#55FFFF00)

Also note how Internet Explorer already supported 8-digit hex codes for RGBA colors, something that only officially appeared in CSS around 2016 as part of the CSS Color Module Level 4.

Custom Scrollbar Styling #

Internet Explorer first introduced custom scrollbar styling back in 1999 and it wasn't until 2013 that Safari came up with its own mechanic of styling them.

Credit: Stack Overflow, @iambondbaby

body {
  scrollbar-base-color: #C0C0C0;
  scrollbar-3dlight-color: #C0C0C0;
  scrollbar-highlight-color: #C0C0C0;
  scrollbar-track-color: #EBEBEB;
  scrollbar-arrow-color: black;
  scrollbar-shadow-color: #C0C0C0;
  scrollbar-darkshadow-color: #C0C0C0;
}

Box-Sizing #

Internet Explorer initially implemented the box model as if box-sizing: border-box was set by default. Even though many people found Microsoft's take a lot more logical and user friendly, the CSS WG ultimately chose another default where width was not referring to the outer width of a box but to width of the usable content space inside.

Logically, a box is measured from border to border. Take a physical box, any box. Put something in it that is distinctly smaller than the box. Ask anyone to measure the width of the box. He'll measure the distance between the sides of the box (the 'borders'). No one will think of measuring the content of the box. Web designers who create boxes for holding content care about the visible width of the box, about the distance from border to border. The borders, and not the content, are the visual cues for the user of the site. Nobody is interested in the width of the content.

It was only with IE 6 that Microsoft added an additional browser rendering mode, this time sticking to the standards. It was not active by default so not to mess old layouts up. You had to opt-in to it, which you would do by starting your HTML document with a doctype declaration (think of it as JavaScript's 'use strict';).

Nowadays everyone goes back to IE's model by starting off their CSS with resetting the box sizing:

html {
  box-sizing: border-box;
}

*, *::before, *::after {
  box-sizing: inherit;
}

CSS Expressions #

Up until version 7, Internet Explorer had a great feature called "CSS Expressions", also known as "Dynamic Properties". In essence, they were JavaScript snippets wrapped in a CSS function and what the snippet evaluated to went into the CSS property's value. They could be considered as one precursor of CSS Houdini and CSS'es calc() function and other functions.

You could for example script your own min() and max() functions:

width: expression(Math.min(this.parentElement.clientWidth, 400) + 'px');

The above code would set the width of the element to the width of the parent until it exceeds 400px. Then it would stop there, similarly to how max-width works. The this keyword would refer to the current element.

Since IE only supported pseudo-elements from version 8 on, you could use CSS Expressions to "polyfill" these, like so:

zoom: expression(
    this.runtimeStyle.zoom = '1',
    this.insertBefore(document.createElement('span'),(this.hasChildNodes()
                        ? this.childNodes[0]
                        : null)).className='before',
    this.appendChild(document.createElement('span')).className='after'
  );

The code above is assigned to a more or less irrelevant CSS property: zoom. The first thing it would do is to disable further executions of the expression by replacing it with a static value of 1. This stops it from creating more and more elements with every new evaluation run. Then it creates <span> elements which it injects at the beginning and end of its content area, with the CSS class names .before and .after. Since Internet Explorer 8 was the first version to support pseudo-elements but at the same time dropped support for CSS Expressions, the above code would do no damage in pseudo-element aware browsers.

The reason CSS Expressions were dropped so early from IE was that they quickly acquired themselves a bad image. And that was because with CSS Expressions you could quickly tank a website's rendering performance, bringing it to a crawl. The "problem" with CSS Expressions was that they executed after every single event that the browser registered, which also included resize, scroll and mousemove. Have a look at the following example:

background: expression('#'+Math.floor(Math.random()*16777216).toString(16));

The above code would randomly calculate a HEX color which would then be assigned as background.You can see it in action in the following video (epilepsy warning because of flashing colors):

See how the background color updates every time one moves the mouse? This is indeed bad for performance, which is why leading figures in the web development scene soon started advising against using them or to replace them with real JavaScript. Back in the days, though, only a few were really versed at writing JavaScript, including me. Nowadays I would argue that it all depends on how you write your code and that you can equally create badly performing code in proper JavaScript. One solution to the problem is the one shown in the pseudo-element code, where the expression disables itself after the first run by assigning a static value to this.style or this.runtimeStyle (which is another proprietary Microsoft thing representing a style object with even higher precedence in the CSS cascade than inline styles). If the value was meant to stay dynamic, you could modify the code to only do costly calculations when it was supposed to:

<script>
  window.calcWidth = '100%';
  window.updateWidth = false;
  window.onresize = function() {
    window.updateWidth = true;
  };
</script>
<style>
  .element {
    width: expression(
      updateWidth ?
      (
        calcWidth = Math.min(this.parentElement.clientWidth, 400) + 'px',
        updateWidth = false
      ) :
      calcWidth
    );
  }
</style>

But why not just use plain JavaScript? Well, it's true that you can do all of these things with pure JavaScript. One thing though, that I find super handy about expressions, is that they are easier to invoke on many different sorts of elements, as you can use CSS (selectors) to assign them to elements. And in the case of the pseudo-element polyfill expression it makes even more sense to have it in your CSS as that's also the place where you would create real pseudo-elements. So it depends.

Fonts #

Internet Explorer was the first browser to allow the use of custom fonts. The corresponding @font-face rule was part of CSS 2.0 but got pulled out of CSS 2.1 as browser support was too bad - mostly due to font foundries opposing the idea of putting fonts into the web, easy to pirate for everyone. Microsoft continued to support it and paired it with a new file format, which they developed together with the font foundry Monotype: the Embedded OpenType (EOT) format. EOT was meant to tackle these problems from two directions. On the one side, authoring tools, like Microsoft's Web Embedding Fonts Tool (WEFT), would only accept source fonts that were not marked with a no embedding flag. That way font foundries could disallow the use of them on the web. On the other side, during creation, you would specify a list of allowed URLs for the font to be used on and the browser would then check against it and only display the font if the current URL was indeed listed.

Microsoft and Monotype submitted EOT to be standardized to the W3C in 2008. But ultimately, the other browser makers of that time decided not to implement it, as it didn't use the (then) commonly supported GZIP algorithm for compression, but a proprietary algorithm called "MicroType Express" which they didn't want to implement on top. So instead they asked the W3C to develop yet another font embedding format, but based on GZIP, which in 2010 appeared as the WOFF format.

Rather than embed the URL of a document in the font, it relies on an HTTP feature (the origin header), which allows to give the domain part of a document's URL: less precise than a full URL, but still good enough for most font makers. In the end, however, WOFF still adopted parts of EOT's MicroType Express algorithm, and a new compression algorithm (Brotli), because it allowed better compression than gzip.

Fun fact: Did you know that when you chose to embed fonts into a Powerpoint 2007 or 2010 presentation, that Powerpoint would embed that font as an EOT file in the corresponding .pptx?

HTML Components: Attached Behaviors, Element Behaviors & Default Behaviors #

As early as 1998, Microsoft already suggested techniques that came close to what we celebrate today as CSS Houdini and Web Components: HTML Components:

The growth of HTML with scripting as an application platform has exploded recently. One limiting factor of this growth is that there is no way to formalize the services that an HTML application can provide, or to allow them to be reused as components in another HTML page or application. HTML Components address this shortcoming; an HTML Component (HTC for short) provides a mechanism for reusable encapsulation of a component implemented in HTML, stylesheets and script.

Componentization is a powerful paradigm that allows component users to build applications using 'building blocks' of functionality without having to implement those building blocks themselves, or necessarily understand how the building works in fine detail. This method makes building complex applications easier by breaking them down into more manageable chunks and allowing the building blocks to be reused in other applications. HTML Components brings this powerful development method to Web applications.

In fact, Microsoft's work was considered prior art in the early Web Component discussion.

The first browser to implement HTML Components was Internet Explorer 5 in 1999 and the last one was Internet Explorer 9 in 2010.

And there were three kinds of HTML Components: Attached Behaviors, Element Behaviors, and Default Behaviors.

Attached Behaviors #

Attached Behaviors worked similarly to a CSS Houdini Worklet in that you had a (.htc) file which would add new capabilities to any element it was attached to. The attaching itself was done via CSS:

img {
  behavior: url(roll.htc);
}

The .htc files consisted of special XML markup used to connect with the outside world, and a script block which would define how the element would behave. The attached DOM element was exposed to the script as the element global. The following Attached Behavior is tailored for image elements and would change their source every time the mouse would hover over them (hat tip for his deep dive and and credit for all of the following examples goes to Jasper St. Pierre):

<public:attach event="onmouseover" onevent="rollover()" />
<public:attach event="onmouseout" onevent="rollout()" />
<script>
var originalSrc = element.src;
function rollover() {
    element.src = "rollover-" + originalSrc;
}
function rollout() {
    element.src = originalSrc;
}
</script>

Element Behaviors #

Element Behaviors went one step further by not only outsourcing behavior into a .htc file but also markup, thereby creating a custom element. This is pretty similar to Web Components' Custom Elements which also look trivial from the outside, from the "Light DOM", but hide a complex DOM structure inside in their Shadow DOM. Microsoft's version of Shadow DOM is called "Viewlink", into which you can opt-in, and like Shadow DOM it will protect the inner structure from any document styles bleeding in or from external scripts manipulating it.

Viewlink is a feature of element behaviors that enables you to write fully encapsulated Dynamic HTML (DHTML) behaviors and import them as robust custom elements in a Web page.

In order to use Element Behaviors it wasn't enough anymore to use CSS to tie an HTML element to a behavior. Instead you had to leverage the power of XML by creating a new namespace for your custom components:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:custom>
<head>
  <?import namespace="custom" implementation="RollImgComponent.htc">
</head>

custom is a XML namespace name which you could freely chose. It could also be something else. The <?import> tag does what we previously used CSS for: referring to a .htc file holding the code for that component. In the .htc file, you then needed to add a few more parts:

You needed to define the custom HTML tag under which to use the element: <public:component tagname="rollimg">
You had to define any HTML attributes this element allowed for, e.g.: <public:property name="src" />
And you needed to add the inner markup of your element similarly to today's <template> element.

<public:component tagname="rollimg">
  <public:attach event="onmouseover" onevent="rollover()" />
  <public:attach event="onmouseout" onevent="rollout()" />
  <public:property name="src" />
</public:component>

<img id="image" />

<script>
  // IE's document.getElementByID
  var img = document.all['image'];
  img.src = element.src;
  img.id = undefined;
  element.appendChild(img);

  function rollover() {
    img.src = "rollover-" + element.src;
  }
  function rollout() {
    img.src = element.src;
  }
</script>

Note that within the .htc file you had your own scoped document object to traverse.
Now you were ready to go and use your custom element in your HTML markup like so:

<custom:rollimg src="logo.png">

Custom elements like these were synchronously parsed and created. After the creation of the above example component the page's DOM would look like this:

<custom:rollimg src="logo.png">
  <img src="logo.png" />
</custom:rollimg>

As you can see, these img elements became visible and could therefore be targeted from with the HTML document via DOM traversal or CSS. Which may not have been what you wanted. To fix that, you needed to activate Internet Explorer's version of Shadow DOM called "viewLink", like so:

<public:component tagname="rollimg">
  <public:attach event="onmouseover" onevent="rollover()" />
  <public:attach event="onmouseout" onevent="rollout()" />
  <public:property name="src" />
</public:component>

<img id="image" />

<script>
  // Activates IE's Shadow DOM
  defaults.viewLink = document;

  // IE's document.getElementByID
  var img = document.all['image'];
  img.src = element.src;

  function rollover() {
    img.src = "rollover-" + element.src;
  }
  function rollout() {
    img.src = element.src;
  }
</script>

Default Behaviors #

Default Behaviors are the third variant of HTML Components. They are basically standard libraries built into the browser that you could tap into via CSS or XML extension and that unlocked a completely new set of functionality.

Triggering a Download #

One of them was behavior:url(#default#download).

Nowadays when you want to trigger a download just from within the front-end, what you would do is make use of a link with a download attribute and execute .click() on it. Well, back in the old days it went like this:

<!--
the following element needs to be created once in the document.
It then exposes new utility methods you can use, like .startDownload()
-->
<span id="download" style="behavior:url(#default#download)"></span>

<button onclick="download.startDownload('menu.pdf')">Download</button>

Persisting Data #

Another super useful Default Behavior was behavior: url(#default#userData). It solves the same problems as localStorage does, just in a completely different manner. The following illustrates how to save and restore the values of input elements in old IE:

<style>
  #store {
    behavior: url(#default#userData);
  }
</style>

<script>
  function save(){
    store.setAttribute('username', username.value);
    store.setAttribute('email', email.value);
    store.save('exampleStore');
  }
  function restore(){
    store.load('exampleStore');
    username.value = store.getAttribute('username');
    email.value = store.getAttribute('email');
  }
</script>

<span id="store"></span>
<input id="username">
<input id="email">
<button onclick="restore()">restore values</button>
<button onclick="save()">save values</button>

There is even localStorage polyfills for IE that use this technique.

Client Capabilities #

Another Default Behavior is the Client Capabilities Behavior. As the name already hints at, it allows you to find out more about the client. The most interesting piece of information is the one about the user's connection type, similar to today's navigator.offline or the Network Information API:

<span id="clientcapabilities"
      style="behavior:url(#default#clientCaps)">
</span>

<script>
  // Either "modem" or "lan" or "offline"
  var connectionType = clientcapabilities.connectionType;
</script>

Animating via Timed Interactive Multimedia Extensions #

You think Internet Explorer could not animate stuff? Not entirely true. Because, back in the days there was already SMIL, the Synchronized Multimedia Integration Language. SMIL is a markup language to describe multimedia presentations, defining markup for timing, layout, animations, visual transitions, and media embedding. While Microsoft was heavily involved in the creation of this new W3C standard, they ultimately decided against implementing it in Internet Explorer. What they did, though, was to derive from it a dialect that would integrate with HTML and submitted that to W3C, too: HTML+TIME, the Timed Interactive Multimedia Extensions. The W3C later reworked it into something that became part of SMIL 2.0 and that was called XHTML+TIME. Internet Explorer 5 was the first browser to support it in 1999 in version 1.0. Internet Explorer 5.5 one year later supported HTML+TIME version 2.0, the implementation of which was closer to W3C's XHTML+TIME draft. Microsoft still held on to the old name without a leading X, though.

This feature was also encapsulated in a Default Behavior which you had to activate first, either by CSS or by extending the (XML) namespace. Afterwards, what you could do with it was e.g. to show and hide elements over the course of ten seconds, five times in a row:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
  <style>
    .time {
      behavior: url(#default#time2);
    }
  </style>
</head>
<body>
<div class="time" repeatcount="5" dur="10" timecontainer="par">
  <p class="time" begin="0" dur="4">First line of text.</p>
  <p class="time" begin="2" dur="4">Second line of text.</p>
  <p class="time" begin="4" dur="4">Third line of text.</p>
  <p class="time" begin="6" dur="4">Fourth line of text.</p>
</div>
</body>
</html>

Or, switching to the XML namespace variant, you could animate HTML attributes like the background color of the body:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:t="urn:schemas-microsoft-com:time">
<head>
  <?import namespace="t" implementation="#default#time2">
</head>
<body id="body">
  <t:animateColor targetElement="body"
    attributeName="backgroundColor"
    from="black" to="white"
    begin="0" dur="3" fill="hold"/>
</body>
</html>

Or you could embed a video or audio in HTML, similarly to how you use <video> or <audio> nowadays, and even have accessible HTML controls:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:t ="urn:schemas-microsoft-com:time">
<head>
  <?import namespace="t" implementation="#default#time2">
</head>
<body>
  <t:video id="video" src="video.mpeg" type="video/mpeg"/>
  <div class="controls">
    <button type="button" onclick="video.resumeElement()">play</button>
    <button type="button" onclick="video.pauseElement()">pause</button>
    <button type="button" onclick="video.speed = 1">1x</button>
    <button type="button" onclick="video.speed = 4">4x</button>
  </div>
</body>
</html>

All formats were supported for which the underlying Windows operating system found an appropriate decoder. By default those were for example MPEG-1 and AVI encoded with Microsoft Video-1 codec.

You could even combine the Microsoft specific format with HTML5:

<video id="html5video" autoplay muted>
  <source src="video.mp4" type="video/mp4"/>
  <t:video id="video" src="video.mpeg" type="video/mpeg"/>
</video>
<div class="controls">
  <button type="button"
    onclick="html5video.play ? html5video.play() : video.resumeElement()">play</button>
  <button type="button"
    onclick="html5video.pause ? html5video.pause() : video.pauseElement()">pause</button>
  <button type="button"
    onclick="html5video.playbackRate = video.speed = 1">1x</button>
  <button type="button"
    onclick="html5video.playbackRate = video.speed = 4">4x</button>
</div>

You find the demo here. You'll need a (virtual) machine with IE 5.5-8 to experience the IE implementation which you see in the above video.

Vector Markup Language #

Microsoft were also the first to support a vector graphics format in a browser in 1999: the Vector Markup Language, in short VML. VML was developed by Autodesk, Hewlett-Packard, Macromedia, Microsoft, and Vision and submitted to the W3C in 1998. Unfortunately, around that same time, the W3C also received a competing submission called Precision Graphics Markup Language (PGML), developed by Adobe Systems and Sun Microsystems. So W3C merged both proposals and created the Scalable Vector Graphics format (SVG) in 2001. The first browser to support SVG was Konqueror 3.2 in 2004.

To be honest, there isn't much to complain about VML, other than that it could only be used embedded into an HTML file, not externally referenced. Here is how you would create an ellipse both in SVG as well as in VML:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>SVG Ellipse</title>
</head>
<body>
<svg>
  <ellipse cx="200"
    cy="80"
    rx="100"
    ry="50"
    fill="yellow"
    stroke="purple"
    stroke-width="2" />
</svg>
</body>
</html>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:v="urn:schemas-microsoft-com:vml" lang="en">
<head>
  <title>VML Ellipse</title>
  <style>v\:* {behavior:url(#default#VML);}</style>
</head>
<body>
<v:oval
  style="position: absolute; width: 200; height: 100; left: 100; top: 30;"
  fillcolor="yellow"
  strokecolor="purple"
  strokeweight="2">
</v:oval>
</body>
</html>

Both dialects look similar and seem equally unfamiliar to us web developers.

Data Binding #

Back since Internet Explorer 4.0 in 1997 you could embed data sources into your document. This could be done by referencing an external CSV file via <object> element:

<object id="data" classid="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83">
 <param name="DataURL" value="data.csv">
</object>

Instead of a CSV file you could also establish a connection to your database server (not suggested in writing mode :):

<object id="data" classid="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33">
    <param name="Server"  value="http://server">
    <param name="Connect" value="dsn=database;uid=guest;pwd=">
    <param name="SQL"     value="select name from people">
</object>

(Note how the classid attribute changes depending on the source of data?)

And finally you could also reference an external XML file via <xml> tag…

<xml src="http://localhost/xmlFile.xml"></xml>

…or use embedded inline XML in HTML as your data source:

<body>
<xml id="data">
  <?xml version="1.0" encoding="UTF-8" ?>
  <records>
    <record>
      <name>Willa Galloway</name>
      <email>tortor@dictum.com</email>
      <phone>098-122-8540</phone>
      <city>Tenali</city>
    </record>
    <record>
      ...
    </record>
    ...
  </records>
</xml>
</body>

That inlined XML was called "XML Data Islands" and it worked similarly to how browsers nowadays handle SVG embedded in HTML or HTML embedded into an SVG <foreignObject> by switching to another parser on the fly.

An XML data island is an XML document residing within an HTML page. This avoids having to write code (i.e. a script) just to load the XML document, or having to load it through a tag. Client side scripts can directly access these XML data islands. These XML data islands can be bound to HTML elements also.

Now that you had the data in your page you could use Internet Explorer's data binding to e.g. edit it:

<input type="text" datasrc="#data" datafld="name">

2-way Data Binding #

Not only could you bind data to an input, but also to arbitrary elements. And you could create a two-way data flow, just with declarative markup:

<xml id="data">
  <record>
    <name></name>
  </record>
</xml>
<h1>Hello, <span datasrc="#data" datafld="name"></span>!</h1>
<label>Your name: <input datasrc="#data"
                         datafld="name"
                         onkeyup="this.blur();this.focus()">
</label>

The only reason there is onkeyup="this.blur();this.focus()" is to trigger data flow after each key press, as otherwise the other connected elements would only receive the updated value after the user left the input.

Data Grids #

Internet Explorer also shipped with a native data grid implementation that you hooked up to the above data sources and which is built on top of the <table> element. This was called Tabular Data Control. You would use the HTML attributes datafld to map data fields to table columns, dataformatas to enable or disable HTML entity encoding of the contained data, and the datapagesize attribute to denote how many entries a page of the grid should show at once. And then there were the methods previousPage, nextPage, firstPage, lastPage to easily navigate through the pages.

<table id="datagrid"
       datasrc="#people"
       datapagesize="10">
  <thead>
    <tr>
      <th>Name</th>
      <th>Email</th>
      <th>Phone</th>
      <th>City</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><span datafld="name"></span></td>
      <td><span datafld="email"></span></td>
      <td><span datafld="phone"></span></td>
      <td><span datafld="city"></span></td>
    </tr>
  </tbody>
</table>
<button onclick="datagrid.previousPage()">&lt; previous</button>
<button onclick="datagrid.nextPage()">next &gt;</button>

Property Change Event #

Internet Explorer featured an interesting propertychange event, which you could attach to DOM elements and which would trigger each time one of its properties would be changed programmatically. This could have happened via setAttribute() or via object property access. This allowed to create observed/instrumented objects for similar use cases you could use ES Proxies nowadays. All you needed was a dummy DOM element with propertychange event applied:

<div id="store"></div>

<script>
  function handler() {
    // A magic 'event' variable is passed into
    // the event handler function. When coming
    // from the 'propertychange' event, it comes
    // with a 'propertyName' property.

    if (event.propertyName === 'onpropertychange') {
      // Don't execute right at the beginning on itself
      return;
    }

    alert(
        event.propertyName +
        '\'s value was changed/set to "' +
        store[event.propertyName] +
        '"'
    );
  }

  store.onpropertychange = handler;

  store.test = true;
  store.test = false;
  store.literal = {};
  store.literal = {
    key: 'value2'
  };
</script>

Resize Events for DOM Elements #

Internet Explorer had plenty of unique events, but the most interesting one is the element based resize event, available up until IE 9.

The onresize event fires for block and inline objects with layout, even if document or CSS (cascading style sheets) property values are changed.

This event is basically in relation to Resize Observer what mutation events are to the Mutation Observer. With the only difference to the usual events in that it triggered asynchronously, similarly to an observer.

element.onresize = function(e) {
    /* React to the element's size change */
}

JavaScript Preloading #

One interesting implementation of Internet Explorer was how it would load and execute JavaScript sources added via script:

var script = document.createElement('script');
var head = document.getElementsByTagName('head')[0];

script.src = '...';
head.appendChild(script);

Other browsers would fetch and execute such a script the moment it was appended to the DOM. Internet Explorer had a more nuanced approach: it splitted both steps up. Fetching already happened as soon as the .src property was assigned whereas execution only happened once the script was appended to the DOM. That way you could easily preload scripts without blocking the main thread. Something developers could only implement in a more complicated fashion in other browsers, at least until we got Resource Hints.

Internet Explorer was also the first browser to introduce the defer attribute for scripts.

Finding the currently executing script #

At some point, the HTML5 standard introduced document.currentScript which pointed to the <script> element which was currently being executed. Why would you need this? For example to read out extra configuration like this one in the data-main attribute:

<script src="scripts/require.js" data-main="js/main"></script>

Somewhere inside scripts/require.js there would be this line:

var main = document.currentScript.getAttribute('data-main');

Sadly, this only got implemented in Edge 12. What only a few people knew was that Internet Explorer had another mechanism in place which not only offered the same result, but that was also more in line with how a document would communicate if it was still loading or if it was fully interactive: scripts had a .readyState property.

function currentScript() {
  var scripts = document.getElementsByTagName('script');

  for (; i < scripts.length; i++) {
    // If ready state is interactive, return the script tag
    if (scripts[i].readyState === 'interactive') {
      return scripts[i];
    }
  }

  return null;
}

The .readyState property was dropped in Internet Explorer 11 which made this version the only one supporting neither .currentScript nor .readyState (luckily, a genius named Adam Miller found another way to polyfill it).

So what led to IE's downfall? #

Looking at the above list, I would say that Microsoft was lightyears ahead of everyone else in regards to providing tools and solutions for architecting complex and delightful websites. Some syntax may look unfamiliar to us, but this is just because we are not used to it. Back in the days, XML was all the rage. And remember how you felt when you opened an SVG for the first time? Or when you saw ES6'es arrow notation? Or BEM? JSX? You probably had the same feelings.

One part of why Microsoft's ideas didn't really catch on was that we developers just didn't get it. Most of us were amateurs and had no computer degree. Instead we were so busy learning about semantic markup and CSS that we totally missed the rest. And finally, I think too few people back then were fluent enough in JavaScript, let alone in architecting complex applications with JavaScript to appreciate things like HTML Components, Data Bindings or Default Behaviors. Not to speak of those weird XML sprinkles and VML.

The other reason could have been a lack of platforms to spread knowledge to the masses. The internet was still in its infancy, so there was no MDN, no Smashing Magazine, no Codepen, no Hackernoon, no Dev.to and almost no personal blogs with articles on these things. Except Webmonkey. There were also no conferences yet, where Microsoft devrel people could have spoken. And there was also no broadband and therefore no conference talks you could have watched on video. All there was, was mailing lists like "A List Apart" and IRC to get in contact with others, which was basically Slack, but with a lot less polish.

The final nail in the coffin was that after the release of Internet Explorer 6, Microsoft decided to tightly couple new Internet Explorer releases to Windows releases. So they dismantled the Internet Explorer team and integrated it into the Windows product team. Sadly, the Windows version in the making, Windows XP's successor with codename "Longhorn" (later Windows Vista), got massively delayed as development was so unfocused and chaotic that they even needed to reset it. This also delayed a new Internet Explorer release and left the web in a vacuum, with no one fixing bugs and improving existing technology. When Microsoft woke up five years later, it was already too late. W3C had developed new standards and the remaining other browser makers not only implemented them but also founded the WHATWG which brought even more innovations to the table. Microsoft lost its technical leadership, lost its market share, and never recovered from that period.

Update: don't miss the interesting discussion happening over at Hacker News.

The cover photo of this post is shot from within the ruins of the Monument House of the Bulgarian Communist Party, built on Buzludzha Peak in central Bulgaria by Natalya Letunova on Unsplash

Fixing Smooth Scrolling & Page Search (updated!)

2021-01-06T00:00:00Z

Yesterday, as I was browsing my Twitter timeline, a tweet from Chris Coyier popped up, in which he mentioned feedback he got for one of his CSS Tricks experiments. It went as follows:

Anecdotal thing: when I had this on @CSS, I had SO MANY reports of people annoyed that when they did "find on page" and ⬆️⬇️ through the results, the smooth scrolling was slow and annoying. Unfortunately, you can't control the speed or when it happens. https://t.co/HAio46bYQt
— Chris Coyier (@chriscoyier) January 5, 2021

Apparently Chris had once switched out JavaScript-based smooth anchor scrolling in favor of a more modern, purely CSS-based solution. All you need to do is slap a scroll-behavior: smooth on html and all of a sudden scrolls to different places on the page happen smoothly. And that's great!

Page Search #

Sadly, as Chris points out in his tweet, native smooth scrolling negatively affects the UX of page search when cycling through its search results:

Smooth scrolling is consequently applied to everything. Always. Even when cycling through the browser's page search results. At least that's the case for Chromium. So for the page search it would be desirable for the browser to make an exception to that rule and to deactivate smooth scrolling.

Until the Chromium team fixes it, here is a trick how to solve the problem on your own with a little bit of extra CSS --and HTML--.

The Solution #

First you need to move your assignment of scroll-behavior from html selector to html:focus-within. This will ensure that smooth scrolling is only active while the focus is within the page. Sadly Chrome and Firefox, upon clicking an on-page anchor link, both first assign and then remove focus from the document. Therefore you need to flank the above with two (identical) time-limited animations that force smooth scrolling onto the document for a certain period of time after the click.

@keyframes smoothscroll1 {
  from, to { scroll-behavior: smooth; }
}

@keyframes smoothscroll2 {
  from, to { scroll-behavior: smooth; }
}

html {
  animation: smoothscroll1 1s;
}

html:focus-within {
  animation-name: smoothscroll2;
  scroll-behavior: smooth;
}

Link to Codepen

Now everytime the user interacts with the surrounding browser interface, as is the case with the page search, smooth scrolling will be disabled and jumping to the results will be instantaneous.

And that's it. Problem solved!

2021/01/17 Update: My initial solution broke smooth scrolling on a perfectly working Firefox (due to this long standing bug). So I reworked the code. The CSS got more complex, but on the winning side you don't need to add tabindexes to your HTML any more.

Thanks go out to Matthias Ott and Stefan Judis for pushing me to publish this post ❤

The cover image of this post is Graceful Ballet Dancer by Master1305

On leaving out the alt Attribute

2021-01-16T00:00:00Z

As it seems I'm currently looking at my Twitter timeline way too often. Because this time it was a tweet from Šime Vidas that caught my attention:

Do I need alt text if there’s a visible image description?

<figure>
<img src="x.jpg" width="900" height="600" alt="">
<figcaption>Caption serves as alt text</figcaption>
</figure>
— Šime Vidas (@simevidas) January 16, 2021

What Šime is asking is if alt could not be left out if the corresponding image is being described through other technical means, i.e. a <figcaption>.

As most commentators correctly answered: you cannot leave it out. This is due to the different use cases and therefore user expectations for alt and <figcaption>:

alt is literally meant as an alternative representation of the visual "data". Therefore it should be a textual reproduction of the image's appearance. It would describe its format, colors, what shapes and things can be spotted and where, as well as text that is visible and in what type of font it is presented. Imagine one of those new AIs which can draw an image from a text you provide. Ideally your text is written in such a way that the image generated by the AI closely matches the original one.
<figcaption> on the other hand is meant as an accompanying caption or legend. Similarly to a <table>'s <caption> element, it could provide a headline-like description of the given <figure>. For example: "Usage of jQuery vs. React in %". Or in the case of a photograph, it could offer additional info like artist and copyright.

So we need both, as alt and <figcaption> are not interchangeable.

One more thing to spot in Šime's code example is that he leaves the alt attribute an empty string. This is only allowed when the corresponding image is of purely presentational character and not conveying any additional info:

In many cases, the image is actually just supplementary, and its presence merely reinforces the surrounding text. In these cases, the alt attribute must be present but its value must be the empty string.

In general, an image falls into this category if removing the image doesn't make the page any less useful, but including the image makes it a lot easier for users of visual browsers to understand the concept.

…or when it is not meant for the user to see at all:

Generally authors should avoid using img elements for purposes other than showing images.

If an img element is being used for purposes other than showing an image, e.g. as part of a service to count page views, then the alt attribute must be the empty string.

In such cases, the width and height attributes should both be set to zero.

Would any the above be true, then Šime's image would probably never be located inside a <figure> element with its rather strong semantic implications to begin with.

Does it all boil down to something we already know, which is that the alt attribute is mandatory - end of the story? Not quite!

When you write your HTML the way Šime was suggesting… 👇

<figure>
  <img src="./image.jpg">
  <figcaption>Description</figcaption>
</figure>

…and run it through the validator you will find that it is perfectly valid HTML! The same holds true if the image has a title attribut instead of alt:

<img src="./image.jpg" title="Description">

This again is perfectly valid HTML! Is this a glitch in the validator? Well, no. The reason for allowing these constellations is explained in the HTML Spec:

In some unfortunate cases, there might be no alternative text available at all, either because the image is obtained in some automated fashion without any associated alternative text (e.g. a Webcam), or because the page is being generated by a script using user-provided images where the user did not provide suitable or usable alternative text (e.g. photograph sharing sites), or because the author does not himself know what the images represent (e.g. a blind photographer sharing an image on his blog).

Basically when an image is meant for the user to be seen and it does convey information, but when at the same time it is technically impossible to offer, or generate, a textual alternative describing what can be seen, then it is allowed to leave away alt altogether, as an empty alt="" would mark the image as to ignore - which is not what you'd want. One example mentioned above is a live webcam feed, another one would be a CAPTCHA. In both cases it is impossible at the time of authoring the HTML to say what later will be shown in the image. At the same time both types of images are important for the user and nothing to skip over. Therefore dropping the alt attribute in these cases makes sense.

So in the end things turn out again more nuanced than we initially thought (and maybe hoped for). But since omitting the alt attribute in the described cases is optional whereas all the other cases require it to be present, the easiest strategy is to keep adding them to every image element, and you are good.

Please have a look and subscribe to Šime's Web Platform News ❤

Thanks go out again to Stefan Judis for proof reading. ✨

The cover image of this post is Audio Sound Wave by edwardolive

Gradient Multiline Padded Text

2021-01-18T00:00:00Z

For whatever reason a question from Dan Mall from 2018 popped up in my timeline where he was asking how to create multiline padded text with a consistent gradient background in CSS:

CSS superfriends! Have you seen examples of how to do multi-line padded text like this article on @css (https://t.co/2j8p4jmaT4), but with a gradient that doesn't reset for each line? pic.twitter.com/MVPdAjxt1W
— Dan Mall (@danmall) December 3, 2018

Here is my take:

See the Pen Gradient Multiline Padded Text by Christian Schaefer (@Schepp) on CodePen.

Link to Codepen

The trick is to set background-attachment to fixed, so that it uses the viewport instead of the element (or rather inline fragments) as its reference. That keeps the background from resetting in each line and also from starting at different origins for each line.

The second relevant setting is box-decoration-break: clone, which repeats the padding on every line, instead of applying padding-left only in the first and padding-right only in the last line.

Try commenting out both properties in the Codepen to see the differences.

Important caveat: The background will only spread as far as the size of the viewport. If you need to style text in such a way, but below the fold, you're out of luck. So this only works well with the main headline.

Running WebKit on Windows

2021-01-21T00:00:00Z

Safari 5.1, back in 2010, was the last WebKit browser that somebody released for the Windows platform. Since then debugging things in WebKit came down to either buying a whole Mac or using a remote Safari in Browserstack.

Funnily enough, the WebKit team kept pumping out nightly builds for Windows together with those for the other platforms. It's just that Apple didn't want to invest anymore time in providing a browser UI around it. But it is still perfectly possible to get WebKit on Windows to start, with almost all the engine features of the newest Safari.

There are two ways to do so: a manual and an automated one.

Alexander Skachkov was kind enough to describe all required steps of the manual way in a blog post three years ago. The only update from my side would be to not install Cygwin and Apple iTunes, as both are monsters, but instead to download the so-called "WebkitForWindows WebKitRequirements" as ZIP and to put the content of their bin64 folder into the one with the same name of your WebKit-Cairo folder. Afterwards you run MiniBrowser.exe and should be greeted with a spartan browser window.

But you probably don't wanna jump through the hoops of manual installation, especially not each and everytime you need to upgrade WebKit. The automated way is to use "Playwright". Playwright is basically what Puppeteer is for Chrome, but for Chrome, Firefox and Safari at the same time. All you need to get going is npm. Then you run it like this:

npx playwright wk https://webkit.org/

The wk parameter indicating that you wanna use WebKit. Then you are greeted with this window:

Giving it a spin on html5test.com tells me that it trails Safari by quite a bit (492 vs 416 points). But the areas affected are basically due to proprietary things or the missing browser chrome and OS integration around it:

color input
fullscreen support
Web Notifications
gamepad support
Pointer Lock API
Web Audio API
Speech Recognition
Speech Synthesis
video and audio codecs
video streaming
video DRM
JPEG image export
WebRTC
Webcam support
Web Payments API
Objectstore blob support
Web SQL

Looking though the list, only the missing video codec support is a bummer. The rest it pretty much irrelevant for the average site.

Have fun!

Chaining Declarations via Animation Composition

2023-06-11T00:00:00Z

I just returned from this year's CSS Day in Amsterdam, and it was fantastic! Year after year, PPK and Krijn organize one of the best conferences you can wish for: The program is mind-blowing with the best of speakers coming from all over the world, and at the same time they cater so well for everyone attending <3. This is also true for their other conference series: Performance.now(). If you haven't been to any of their conferences, maybe it's about time!

What also happened was that Nils and I ran the second installment of an in-person CSS Café meetup as a side event the day after CSS Day. It's a place for people to relax and come down after three intense days, with a few high-quality talks sprinkled in to help against going cold turkey on CSS. And what a lovely day that was!

Individual Transforms: the Good, the Bad, and the Ugly #

This was the title of the first talk given by Amit Sheen. His talk was about the individual transforms properties that got recently added to the web platform, showing us what kinds of problems they help solve, but also pointing out where they do have their shortcomings.

The Good #

Individual transforms, which have landed in all browsers, allow us to manipulate the different kinds of transforms individually, allowing us to layer them and keep our CSS code more DRY.

So instead of writing such repetitive code:

.element {
  transform: translateY(50px);
}

.element:hover {
  /* translateY needs to be repeated, 
  otherwise, it's going to be lost */
  transform: translateY(50px) rotate(-45deg);
}

we can now do this:

.element {
  translate: 0 50px;
}

.element:hover {
  rotate: -45deg;
}

No need to carry over the translate when all we want is to change the rotation.

With animations, it's even more useful when you need each transform to change at a different pace:

@keyframes anim {
  0% { transform: translateX(0%) }
  5% { transform: translateX(5%) rotate(90deg) scale(1.2) }
  10% { transform: translateX(10%) rotate(180deg) scale(1.2)}
  90% { transform: translateX(90%) rotate(180deg) scale(1.2)}
  95% { transform: translateX(95%) rotate(270deg) scale(1.2)}
  100% { transform: translateX(100%) rotate(360deg) }
}

With individual transforms, this gets a lot DRYer - and easier, too:

@keyframes anim {
  0% { translate: 0 0 }
  100% { translate: 100% 0 }

  0%, 100% { scale: 1 }
  5%, 95% { scale: 1.2 }

  0% { rotate: 0deg }
  10%, 90% { rotate: 180deg }
  100% { rotate: 360deg }
}

That way you can also layer multiple keyframe animations on top of one another, each animating a different individual property:

@keyframes move {
  0% { translate: 0% 0; }
  100% { translate: 100% 0; }
}

@keyframes scale {
  0%, 100% { scale: 1; }
  5%, 95% { scale: 1.2; }
}

@keyframes rotate {
  0% { rotate: 0deg; }
  10%, 90% { rotate: 180deg; }
  100% { rotate: 360deg; }
}

.target {
  animation: move 2s, scale 2s, rotate 2s;
  animation-fill-mode: forwards;
}

The Bad #

The big caveat of individual transforms is that the order in which they get processed and applied is predetermined:

translate always comes first,
followed by rotate,
then scale
and finally the classic transform.

That can be a problem as the order in which transforms get applied can lead to different visual outcomes.

Take the example from the beginning, but let's flip things around this time and have us add a translate to an existing rotate:

.element {
  transform: rotate(-45deg);
}

.element:hover {
  transform: rotate(-45deg) translateY(50px);
}

While it's possible to do the following, the visual outcome will not be the same anymore:

.element {
  rotate: -45deg;
}

.element:hover {
  translate: 0 50px;
}

The reason is that an individual rotate will always be applied after an individual translate. So in the :hover-state, instead of the element first being rotated and then moved along the rotation axis, the element will first be moved and only then rotated.

See the Pen Untitled by Christian Schaefer (@Schepp) on CodePen.

Solutions? #

One thing I was very surprised to learn from Amit is that when you set individual transforms and the classic transform at the same time the latter one would not clear out the individual declarations but queue itself up after them. So a solution can be to put our translate into the classic transform as it will then come in last:

.element {
  rotate: -45deg;
}

.element:hover {
  transform: translateX(50px);
}

See the Pen Individual Transforms Caveat by Christian Schaefer (@Schepp) on CodePen.

Amit's suggestion was another one, though. He made the case for using Custom Properties, like so:

.element {
  transform: rotate(var(--rotate, -45deg) 
             translate(var(--translate, 0));
}

.element:hover {
  --translate: 0 50px;
}

While I think, this works well for the given example, where it falls short is when you want to add transforms to elements that have not been set up with Custom Properties. This could be a component from another team or a third party. And it also only works for the amount + type + order of transforms that the element has been set up with.

Enters Animation Composition! #

An unorthodox way of solving this is by making use of, or rather misuse, CSS Animation Composition to chain transforms after existing ones. animation-composition is a new animation property, that allows you to determine if the effects of an animation should wipe out what may already be defined on an element or if its effects get added on top of what is already there.

What you can do now is define an animation, which carries your additional transforms, which is paused and composited on top of the existing values. This is how this would look like, applied to our example:

@keyframes translate {
  0% { transform: translateY(50px) }
}

.element2 {
  transform: rotate(-45deg);
}

.element2:hover {
  animation: translate 1ms paused;
  animation-composition: add;
}

See the Pen Combining individual and classic transforms by Christian Schaefer (@Schepp) on CodePen.

Animation Composition can also fill other gaps in CSS, for example when you want to add a background image via shorthand to an element while preserving any background color that might already be assigned to it.

We often run into situations where background-color has already been set for an element or component, and in a separate class we want to also add a background image to it.

In order to do this without overriding the color, we have to use the background-image property specifically.

Then we need to size, position, no-repeat it and that's 3 more longhand properties.

Add two bg images and we're managing parallel arrays in every longhand property above to avoid overriding the background-color set elsewhere.

It gets pretty tedious very quickly.

Jane Ori at the W3C CSS Working Group Issues

This is what a solution via Animation Composition might look like:

.element {
  background-color: yellow;
}

@keyframes background {
  0% { background: no-repeat center/cover url(bg.png) }
}

.element {
  animation: background 1ms paused;
  animation-composition: add;
}

See the Pen CSS Animation Composition for Composing Backgrounds by Christian Schaefer (@Schepp) on CodePen.

This would also work for composing complex shorthands like font or other layered properties like fill.

But is it available in all browsers? #

As of writing this article, CSS Animation Composition is available in all browsers, except for Firefox, where the feature still has to be enabled via the layout.css.animation-composition.enabled flag. Hopefully, this will change soon! 🤞🏼

Restore your Followings from Twitter/X in Bluesky

2024-11-14T00:00:00Z

As we all know X, née Twitter, is turning more and more into a shitshow. Time to move on to other platforms! Sadly, the people I used to follow flock into all sorts of directions: be it LinkedIn, Mastodon, Bluesky or all of them. So here I am on Bluesky: @schepp.dev.

After having made that first step I wondered if there was an easy way to reconnect with everyone I followed on X, ideally in an automated way as I follow almost 5.000 people on Twitter/X.

Luckily there is a Chrome browser plugin called Sky Follower Bridge that does everything for you. This is how it works:

Reinstating your Twitter/X followings on Bluesky #

Open (or install) the Chrome browser and install the Sky Follower Bridge extension. You should see a new icon appear in your browser bar at the top:
Then go to your Twitter/X "Following" page, click the icon, feed it with your Bluesky account handle and a Bluesky app password, which you can generate here, and finally click "Find Bluesky Users":
Then it'll scan all your followings bit by bit and is going to try to find them on Bluesky. That might take some time:
Finally it'll present you with its findings. You can now go through the list and click "Follow on Bluesky" for each user you are interested in. If you want to follow them all then click the button "Follow all" on the lower left:
And, boom, you are done!

Boost Website Speed with Prefetching and the Speculation Rules API

2024-12-28T00:00:00Z

Everybody loves fast websites, and everyone despises slow ones even more. Site speed significantly contributes to the overall user experience (UX), determining whether it feels positive or negative. To ensure the fastest possible page load times, it’s crucial to design with performance in mind. However, performance optimization is an art form in itself. While implementing straightforward techniques like file compression or proper cache headers is relatively easy, achieving deeper optimizations can quickly become complex.

But what if, instead of solely trying to accelerate the loading process, we triggered it earlier—without the user noticing?

One way to achieve this is by prefetching pages the user might navigate to next using <link rel="prefetch"> tags. These tags are typically embedded in your HTML, but they can also be generated dynamically via JavaScript, based on a heuristic of your choice. Alternatively, you can send them as an HTTP Link header if you lack access to the HTML code but can modify the server configuration. Browsers will take note of the prefetch directives and fetch the referenced pages as needed.

In addition to <link rel="prefetch">, Chromium-based browsers support <link rel="prerender">. This tag is essentially a supercharged version of <link rel="prefetch">. Known as "NoState Prefetch," it not only prefetches an HTML page but also scans it for subresources—stylesheets, JavaScript files, images, and fonts referenced via a <link rel="preload" as="font" crossorigin> — loading them as well.

The Speculation Rules API #

A relatively new addition to Chromium browsers is the Speculation Rules API, which offers enhanced prefetching and enables actual prerendering of webpages. It introduces a JSON-based syntax for precisely defining the conditions under which preprocessing should occur.

Here’s a simple example of how to use it:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

The above list-rule specifies that the browser should prerender the URLs next.html and next2.html so they are ready for instant navigation. The keyword prerender means more than fetching the HTML and subresources—it instructs the browser to fully render the pages in hidden tabs, ready to replace the current page instantly when needed. This makes navigation to these pages feel seamless.

Prerendered pages also typically score excellent Core Web Vital metrics. Layout shifts and image loading occur during the hidden prerendering phase, and JavaScript execution happens upfront, ensuring a smooth experience when the user first sees the page.

Instead of listing specific URLs, the API also allows for pattern matching using where and href_matches keys:

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/*" }
  }]
}
</script>

For more precise targeting, CSS selectors can be used with the selector_matches key:

<script type="speculationrules">
{
  "prerender": [{
    "where": { "selector_matches": ".navigation__link" }
  }]
}
</script>

These rules, called document-rules, act on link elements as soon as the user triggers a pointerdown or touchstart event, giving the referenced pages a few milliseconds' head start before the actual navigation.

If you want the preprocessing to begin even earlier, you can adjust the eagerness setting:

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/*" },
    "eagerness": "moderate"
  }]
}
</script>

Eagerness values:

immediate: Executes immediately.
eager: Currently behaves like immediate but may be refined to sit between immediate and moderate.
moderate: Executes after a 200ms hover or on pointerdown for mobile devices.
conservative (default): Speculates based on pointer or touch interaction.

For even greater flexibility, you can combine prerender and prefetch rules with different eagerness settings:

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/*" },
    "eagerness": "conservative"
  }],
  "prefetch": [{
    "where": { "href_matches": "/*" },
    "eagerness": "moderate"
  }]
}
</script>

Limitations and Challenges #

While the Speculation Rules API is powerful, it comes with some limitations:

Browser support: Only Chromium-based browsers support it. Other browsers lack this capability, so treat it as a progressive enhancement.
Bandwidth concerns: Over-aggressive settings could waste user bandwidth. Chromium imposes limits to mitigate this: a maximum of 10 prerendered and 50 prefetched pages with immediate or eager eagerness.
Server strain: Poorly optimized servers (e.g., no caching, heavy database dependencies) may experience significant load increases due to excessive speculative requests.
Compatibility: Prefetching won’t work if a Service Worker is active, though prerendering remains unaffected. Cross-origin prerendering requires explicit opt-in by the target page.

Despite these caveats, the Speculation Rules API offers a powerful toolset to significantly enhance perceived performance and improve UX. So go ahead and try them out!

I would like to express a big thank you to the Webperf community for always being ready to help with great tips and expertise. For this article, I would like to thank Barry Pollard, Andy Davies, and Noam Rosenthal in particular for providing very valuable background information. ❤️

This post was first published on Manuel Matuzović's HTMHell Advent Calendar.

Rethinking Find-in-Page Accessibility: Making Hidden Text Work for Everyone

2025-02-16T00:00:00Z

I regularly attend UX Graz (Meetup / LinkedIn), a meetup covering diverse UX-related topics, alternating between in-person and remote events. At one recent event, a blind speaker demonstrated how they navigate websites (on LinkedIn). It wasn't my first time seeing someone blind use assistive technology for web navigation, but this experience stood out. Instead of relying on semantic elements like landmarks, headings, lists, or links, the speaker primarily used the browser's find-in-page functionality to navigate.

This approach surprised me at first. As frontend developers, we've been taught to focus on semantic HTML to aid navigation for assistive technology users. But the more I thought about it, the more it made sense: find-in-page can be a much faster and more efficient way to locate content, especially when semantic structures are missing or are poorly implemented. However, this technique isn't foolproof. It falters when text is hidden using attributes like aria-label, title, or alt, or when visible text is styled with font-size: 0 - a method I often use for icon-only buttons.

The event left a lasting impression and plenty to think about.

Fast forward to last week: my podcast co-host, Vanessa, messaged me about our Slack community. She needed the invite link, knew it was on our homepage, and hit Cmd + F to search for "Slack." Yet, nothing came up.

The issue? Once again, the text label for the Slack link was hidden using font-size: 0, as shown in this snippet:

<a href="https://draft.community" style="font-size: 0">
  <svg.../> Slack
</a>

Vanessa asked:

"Is it possible to solve this on the frontend so that the icon gets focused when you use Cmd+F to search for a specific term?"

This reminded me of the meetup speaker's navigation pattern. When I told her about it, this is what she replied:

"Honestly, I use websites exactly the same way."

The Solution: `hidden="until-found"` #

I had an idea to fix this problem using a relatively new HTML feature: the hidden="until-found" attribute. Added to the HTML standard in March 2022, it was shipped in Chrome 102 (May 2022).

The hidden="until-found" attribute works similarly to display: none, preventing the element from rendering or taking up space. However, unlike display: none, the content remains in the accessibility tree, can be found via find-in-page, and is also targetable via anchor links. When a matching search or anchor link is triggered, the hidden attribute is removed, and the element becomes visible.

Here's how I updated our icon-only buttons:

<a href="https://draft.community">
  <svg.../>
  <span class="hidden-until-found" hidden="until-found">Slack</span>
</a>

Now, the text label is searchable. If matched during a search, it appears dynamically. For a more pleasing user experience, I added a tooltip-like rendering for the revealed text using CSS:

.hidden-until-found:not([hidden="until-found"]) {
  position: absolute;
  transform: translateX(calc(-50% - (var(--icon-width) / 2)));
  margin-top: -0.25rem;
  padding: 0 0.2rem 0.05rem 0.2rem;
  background-color: var(--brand-color);
  color: #fff;
  border-radius: 0.1rem;
  font-size: 1rem;
  filter: drop-shadow(0 0 3px rgba(0, 0, 0, 0.5));
}

/* little pointer at the bottom */
.hidden-until-found::after {
  content: '';
  position: absolute;
  z-index: -1;
  left: 50%;
  bottom: -0.2rem;
  width: 1rem;
  height: 1rem;
  transform: translateX(-50%) rotate(45deg);
  background-color: inherit;
}

The result 😍:

Browser Compatibility and Accessibility #

Currently, hidden="until-found" is only supported in Chromium-based browsers. In Firefox and Safari, the element behaves like a standard hidden attribute, meaning it isn't accessible via assistive technology, searchable, or linkable. While the latter two are tolerable (since they match the previous behavior), losing assistive tech accessibility is a problem.

To address this, I added an aria-label to ensure assistive technology still recognizes the link:

<a href="https://draft.community" aria-label="Slack">
  <svg.../>
  <span class="hidden-until-found" hidden="until-found">Slack</span>
</a>

Thankfully, hidden="until-found" is part of this year's Interop project, representing one puzzle piece amongst many to align all browsers on the <details> element. If end of 2025 appears too late for you, consider weighing in on the WebKit and Mozilla bug trackers.

Remaining Challenges #

Persistent Text Visibility: Once text is revealed via find-in-page, it remains visible even after closing the search or starting a new one. Unfortunately, there's no native way to hide it again. A potential workaround is to listen for the beforematch event and reapply hidden="until-found" after a certain delay.
Styling Search Matches: It's currently impossible to style matched text directly. However, future CSS pseudo-elements like ::search-text and ::search-text:current could allow fine-grained control over search result styling.

This episode taught me the importance of accommodating diverse navigation patterns and highlighted (once more) how evolving standards can improve accessibility for everyone. But while hidden="until-found" is a good step forward, there's still work to be done to make find-in-page truly universal.

Turning a CSS Carousel into a Theme Switcher

2026-02-20T00:00:00Z

Sometimes the web gives you an excuse to play.

When Vasilis van Gemert and the team at CMD Amsterdam University of Applied Sciences announced their free community event The Web You Want, they not only asked for talks, workshops and contributions - they also invited people to submit CSS themes for the event website. Very much in the spirit of CSS Zen Garden: style the page however you want, but don’t touch the HTML.

That constraint is exactly my kind of challenge!

Painting the web a bit warmer #

I wanted something optimistic. Nature-inspired. Maybe a bit solarpunk.

The event’s theme felt forward-looking and constructive, so a warm spring landscape seemed like a fitting visual metaphor. I bought a vector illustration of a bright landscape from Shutterstock, picked up the wonderfully playful Leafy font for the main heading, and paired it with Barlow for the body text.

The vector graphic came as a single EPS file, so I opened it in Illustrator and sliced it into layers - hills, sky, clouds, foreground elements - exporting each piece as SVG. That gave me two important affordances:

responsiveness (individual pieces can reposition and scale)
depth (layering elements with content creates a subtle depth illusion)

After a few hours of nudging values and fighting stacking contexts, the scheme felt coherent - and surprisingly robust across browsers.

Respecting user preferences #

One of the design goals was to behave like a good web citizen:

respect font size preferences
respect reduced motion
respect color scheme

The first two are fairly straightforward these days. Color scheme, however, sparked an idea.

If light mode shows a sunny spring landscape… could dark mode show the same scene at night?

With a handful of color tweaks and quite a lot of CSS filters, I created a nighttime variant that still reads as the same place - just under moonlight.

Initially, this was wired up through the usual prefers-color-scheme media query. Done. Ship it.

Except… it felt very much… buried.

Making the theme discoverable #

If a theme contains two carefully crafted schemes, shouldn’t visitors be encouraged to explore them?

A visible light/dark switch would help. But the rules were clear:

no HTML changes
no JavaScript

Classic CSS toggling tricks need some kind of state holder - a checkbox, a fragment target, anything interactive. None existed.

Then I remembered the Chrome team’s CSS-only carousel work.

That (Chromium-only) proposal introduces pseudo-elements such as scroll buttons and scroll markers that behave very much like navigation controls - focusable, keyboard-operable, grouped. In other words: interactive UI created entirely by CSS.

So the question became:

Could I create a fake scroller and use its scroll position as a state machine?

Turning `<head>` into a UI #

First I needed an element with children that's present on every page, to safely play with the approach. There is exactly one element that satisfies that requirement: <head>.

It isn’t rendered by default, but CSS can make it appear. So I did, and I also turned it into a horizontal scroller and instructed the browser to generate a dot navigation for it via scroll-marker-group: after:

head {    
  display: block;    
  overflow-x: scroll;    
  scroll-snap-type: x mandatory;    
  scroll-timeline-name: --head-timeline;    
  scroll-timeline-axis: inline;    
  scroll-marker-group: after;    
  white-space: nowrap;  
}

The first three <meta>-elements became the scroll items:

meta:nth-of-type(1),  
meta:nth-of-type(2),  
meta:nth-of-type(3) {    
  display: inline-block;    
  width: 100vw;    
  height: 1px;    
  scroll-snap-align: center;  
}

The generated dot navigation is exposed as pseudo element ::scroll-marker-group. I positioned it at the top of the page and turned the markers into buttons with accessible names:

head::scroll-marker-group {
  position: fixed;
  z-index: 5;
  top: 1rem;
  left: 50%;
  display: flex;
  gap: 0.25rem;
  transform: translateX(-50%);
}

meta:nth-of-type(1)::scroll-marker {    
  content: url("auto-mode.svg") / "automatic light or dark mode";  
} 

meta:nth-of-type(2)::scroll-marker {    
  content: url("light-mode.svg") / "light mode";  
}  

meta:nth-of-type(3)::scroll-marker {    
  content: url("dark-mode.svg") / "dark mode";  
}

I now had a theme switcher.

Without HTML. Without JavaScript. Just CSS.

Reading state without state #

Buttons alone aren’t enough - the stylesheet needs to know which one is active.

I first thought of :has(), but it cannot inspect pseudo-elements like ::scroll-marker, by design.

However, clicking those buttons scrolls the scroller. And scroll position can drive animations. Enter scroll-driven animations!

I turned the scroller into an animation timeline source:

head {
  scroll-timeline: --head-timeline x;
}

I then exposed the timeline globally via timeline-scope on the <html> - and started using it right there:

html { 
  timeline-scope: --head-timeline;
  animation: set-scheme 1ms steps(3); 
  animation-timeline: --head-timeline;
}

The animation named set-scheme “animates” a custom property:

@keyframes set-scheme {    
  from, 50% { --scheme: light; }    
  to { --scheme: dark; }  
}

A second animation handles the case where system dark mode is preferred so that “auto” actually behaves like auto:

@keyframes set-scheme-dark-preferred { 
  50% { --scheme: light } 
  from, to { --scheme: dark } 
}

html { 
  @media (prefers-color-scheme: dark) { 
    animation-name: set-scheme-dark-preferred; 
  } 
}

At that point, the scroll position had become the theme state.

Reacting to it with style queries #

Now the final piece: consuming that state.

CSS style queries make that possible:

background-color: var(--color-light);

@container style(--scheme: dark) {
  background-color: var(--color-dark);
}

Light scene. Night scene. Same markup!

And a tiny row of buttons that exists only because CSS decided it should. ✨

👉 Have a look (Chromium only) :)

A small disclaimer #

I tried to make the interaction as accessible as possible - the controls are focusable, labelled, and keyboard-operable.

But it is a creative misuse of functionality designed for a different purpose. The underlying semantics still resemble a tablist/scroll navigation rather than a theme switcher, and you can’t completely remove that conceptual mismatch.

So I wouldn’t ship this pattern blindly to production at scale.

What I would ship is the learning.

Because this experiment made something very clear: modern CSS is no longer just about presentation. It increasingly allows us to explore interaction, state, and progressive enhancement in places that used to be JavaScript territory.

And sometimes, that’s exactly the kind of constraint that makes building for the web fun again.

Once more, many thanks go out to Stefan Judis, who was so kind to proofread this post 👊🏻❤️

Der Schepp

Effects for the Web!

The status quo #

SVG to the rescue #

SVG Filters in HTML via CSS #

CSS Masks – How To Use Masking In CSS Now

CSS Masks #

Emulating a simple -webkit-mask-image cross browser #

The modern browsers #

The Internet Explorers #

Linear Gradient Masks #

Radial Gradient Masks #

Final Words #

Dealing with Ads in 2020

Ads suck! #

Ads & Responsiveness #

Lazy Loading Ads for better performance #

Politely bowing out when the user's connection is constrained #

Bringing stability back to layout #

Winning the z-Index Wars #

Shielding our Users #

Closing Notes #

A CSS-only Carousel

Here are a few things to note: #

Today, the Trident Era Ends

The Era of the Trident Engine #

The Forgotten Parts #

MHTML #

Page Transition Filters #

Object Transition Filters #

Effects Filters #

Gradient Filter #

Custom Scrollbar Styling #

Box-Sizing #

CSS Expressions #

Fonts #

HTML Components: Attached Behaviors, Element Behaviors & Default Behaviors #

Attached Behaviors #

Element Behaviors #

Default Behaviors #

Triggering a Download #

Persisting Data #

Client Capabilities #

Animating via Timed Interactive Multimedia Extensions #

Vector Markup Language #

Data Binding #

2-way Data Binding #

Data Grids #

Property Change Event #

Resize Events for DOM Elements #

JavaScript Preloading #

Finding the currently executing script #

So what led to IE's downfall? #

Fixing Smooth Scrolling & Page Search (updated!)

Page Search #

The Solution #

On leaving out the alt Attribute

Gradient Multiline Padded Text

Running WebKit on Windows

Chaining Declarations via Animation Composition

Individual Transforms: the Good, the Bad, and the Ugly #

The Good #

The Bad #

Solutions? #

Enters Animation Composition! #

But is it available in all browsers? #

Restore your Followings from Twitter/X in Bluesky

Reinstating your Twitter/X followings on Bluesky #

Boost Website Speed with Prefetching and the Speculation Rules API

The Speculation Rules API #

Limitations and Challenges #

Rethinking Find-in-Page Accessibility: Making Hidden Text Work for Everyone

The Solution: hidden="until-found" #

Browser Compatibility and Accessibility #

Remaining Challenges #

Turning a CSS Carousel into a Theme Switcher

Painting the web a bit warmer #

Respecting user preferences #

Making the theme discoverable #

Turning <head> into a UI #

Emulating a simple `-webkit-mask-image` cross browser #

The Solution: `hidden="until-found"` #

Turning `<head>` into a UI #