Get fine-grained control over your design with an SVG 2 property implemented by many browsers.
SVG rendering uses a painter’s model to describe how graphics are rendered to the screen. Like layers of paint on a wall, content on top obscures content below. The SVG specifications define which content gets painted over which other content. The different parts of each shape — the stroke, fill, and markers — each create layers of paint. Those shapes are then layered one on top of the other, in the order they are defined in the document.
Two new properties introduced by the SVG 2 specification,
paint-order, allow you to change up the rendering rules.
Most web designers will be familiar with
z-index, which has been supported in CSS layout for years. Unfortunately, it is not yet supported in any major web browser for SVG content. At present, the only solution is to arrange your markup (or the DOM created by scripts) so that elements are listed in the order you want them to be painted.
In contrast, the
paint-order property has already been implemented in a number of web browsers. If you’re willing to make adjustments in your design according to browser support level, you can use the fine-tuned control in the latest browsers and replace it with a simpler effect in others. If you need the same appearance in all browsers, however, you can create something that looks like paint order control with SVG 1.1 code. This post describes why
paint-order is useful, how to use it in the latest browsers, and how to fake it in the others.
Will content-blocking change the Web?
I don’t believe that any more, though, thanks to advertising and the doors that blocking advertising has opened.
While a key part of the last decade’s Web conversation has been performance, the walled gardens are taking advantage of our failure to deliver performance to make their own promises. Facebook’s Instant Articles offer a way for publishers to use the (relative) certainty of Facebook delivery, while Apple took a more direct route for demanding performance: blocking advertisements, and more.
Designing and coding APIs in Node.js.
Getting an API design right demands far more than just figuring out which calls should do what. Public APIs — APIs meant to be used by people other than their creators — present a special set of challenges that can inform all API design. Even private APIs often find themselves with unexpected users, and can last far longer than was planned. Apigee faced the special challenge of creating a marquee API, an API for managing its APIs.
What comes first? The API or the code? Who is the API really for, and how important is the long-term maintenance of the API? Where does documentation fit? Answer these questions, and you can find the right approach.
Finding a gentle entry to a big space
Those aren’t the only barriers, though. Read more…
What you need to know to make an informed choice.
Abbott and Costello’s signature wordplay sketch “Who’s on First?” is one of the most renowned comedic routines of all time. Trying to describe the routine here will do it little justice, you’ll just have to watch it yourself. As funny as it may be, the sketch reveals a crucial fact: names are important. Good names should be self-explanatory, precise and reveal intent. Bad names leave people confused and aggravated and should be avoided at all cost. When we write code, we must always think about variable names, function names, file names, etc. But naming things is hard. Phil Karlton probably said it best: “There are only two hard things in Computer Science: cache invalidation and naming things.”