FEATURED STORY
Elegant Outlines with SVG paint-order
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, z-index
and 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.
Blocked!
Will content-blocking change the Web?
“No one ever turns off JavaScript any more.” I remember when I first believed that, probably around 2007. The growth of Ajax had meant that more people were actually losing content if they turned off JavaScript. From what I could tell, most of the few folks still blocking JavaScript surrendered pretty quickly.
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.
Read more…
Building APIs with Swagger
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.
Learning the Web
Finding a gentle entry to a big space
The Web welcomes, but it’s awfully big. While HTML, CSS, and JavaScript may all be appropriate entry points for newcomers who want to create, finding a solid starting point can be complicated. Social media has minimized the level of HTML and Web knowledge people need to start contributing, but when it’s time to make the jump, the Web offers perhaps too many options.
Part of the challenge is that HTML, CSS, and JavaScript may be the marquee technologies, but they’re not actually what hosts a website or app. Setting up a site requires an additional set of technologies, from domain names to hosting to web server choices. Setting up a site – long before you get to packaging an app! – requires mastering an additional technical toolset and vocabulary that will help you navigate where you need to put your projects. Our free report, Getting Started with the Web, provides the core foundations beginners need.
Those aren’t the only barriers, though. Read more…
Renaming isomorphic JavaScript?
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.”
Since Node.js was first released in 2009, many developers have started discussing and implementing ways to share JavaScript code between the web application server and the browser. This sharing of JavaScript code allows for assembling web pages on either the client or server, with the benefits of faster initial page load times and improved search engine optimization. The name of this approach was coined by Charlie Robbins and later popularized by Spike Brehm as “isomorphic” JavaScript. Such applications are isomorphic in the sense that they take on equal (ἴσος: isos) form or shape (μορφή: morphe) regardless of which environment they are running on, be it the browser or the server.