Elegant Outlines with SVG paint-order
Get fine-grained control over your design with an SVG 2 property implemented by many browsers.
by Amelia Bellamy-Royds |November 20, 2015
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.
Read more…
Blocked!
Will content-blocking change the Web?
by Simon St. Laurent | @simonstl | +Simon St. Laurent |November 11, 2015
“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 advertisem*nts, and more.
Read more…
Panels and panel sets
Common patterns emerge from a variety of components.
by Léonie Watson | @LeonieWatson | +Léonie Watson |November 5, 2015
Picture a modern web application. It almost certainly uses interactive controls, perhaps a carousel at the start, probably a set of tabs or an accordion, or maybe it is based on a coverflow or deck. These are common user interface metaphors: if you use these terms, designers know what you mean, and people recognize and know how to use them. At first glance these design patterns seem to have quite different characteristics, but we’d like to convince you that they really aren’t so different after all.
Ok, convince me!
The idea of a panel of content comes from the printing industry. In printing, a panel is a single page of a brochure, or one face of a folded leaflet. A print panel might be visually unique, like the cover of a leaflet, or be like other panels in a set, like the inner faces of the leaflet.
The concept of a panel has been applied to web design multiple times, generally becoming interactive along the way. Panels of content can be expanded or collapsed, removed completely, or presented in collections. Each of these design patterns has a common purpose: display a collection or set of things, generally one at a time to save on screen space. They may cycle vertically or horizontally, or peel off in layers, but these transition effects do not change the fundamental purpose of the thing – to navigate effectively through some pieces of content.
Read more…
Building APIs with Swagger
Designing and coding APIs in Node.js.
by Greg Brail | @gbrail |September 30, 2015
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.
Read more…
Learning the Web
Finding a gentle entry to a big space
by Simon St. Laurent | @simonstl | +Simon St. Laurent |September 24, 2015
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.
by Maxime Najim | @softwarecrafts |September 24, 2015
Abbott and Costello performing “Who’s on First?”
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.
Read more…
Older Posts >
