The theme this week is SVG: How to make them fast and performant, what's up with including them in WordPress, and useful tips to use them on a day-to-day basis.

From the blog

✻ Sarah Drasner has some excellent advice on how to make SVGs as performant as humanly possible. This pro tip is particularly worth remembering:

…drawing something on paper and then tracing it in Illustrator will come with a lot of junky path data and should never be used as-is. Simple shapes and pen drawing paths are preferred. Very complex objects can become large very quickly, so the less points the path has to draw, the better for performance.

✻ Last week we mentioned that Chris wrote a book called Practical SVG but earlier this week he wrote a more in-depth post about it:

It all started with my interest being peaked in SVG years ago. Peaked for rather obvious reasons: it’s a fascinating technology. Vector graphics on the web! It just makes sense! As I learned about it, as I do, I started writing articles here on CSS-Tricks about it. More and more and more.

Then I started doing conference talks about it. Throughout 2014 and 2015 I did a dozen or so talks like “SVG is for Everybody” and “The Wonderful World of SVG”, including at conferences like An Event Apart. With all that research and writing in hand, it felt like a natural extension to convert it into a book.

Jason Witt wrote a guest post on how to go about Organizing Your Grunt Tasks:

The idea of breaking up your code into smaller bite sized chunks creates an environment that is easy to work in and maintain. That’s often thought of as module design, and is a standard for web development these days. I’m going to show you a way you can use module design to better organize your Grunt tasks.

Chris also wrote about Precedence in CSS, or when the order of CSS matters. There’s lots to consider here for projects of any size: specificity in one stylesheet vs multiple files, asynchronous and critical CSS, and preprocessor @extends.

Nobody wants to think about this. Winning style with specificity is way easier. But knowing about it is a good idea, because unnecessary specificity bloat is a bummer too.

What we’ve been reading, listening and watching

Did you know about the CSS writing-mode property? As Ahmad Shadeed describes, it lets developers set the reading position of a block of text, kinda like this:

Which doesn't look particularly useful in that English screenshot - it's mostly for vertically written languages. But it can be exploited in English for vertical headers!

* * *

JavaScript Promises 101 by Ire Aderinokun is excellent. She digs into the basics of requesting resources from an API and then performing actions depending on whether the request is successful or not.

* * *

Bjørn Johansen explains how to enable SVG in WordPress and why you have to go through that process in the first place:

WordPress is an excellent CMS “out of the box”, very easy to use and “just works” for the large majority of users. So why aren’t SVGs allowed in the first place? Why do we have to jump through hoops to make SVGs work?

Short answer: SVG files are extremely unsecure.

* * *

Martin Falkus gives us some of the possible reasons to use viewport units. Like: headings that always fill up the whole viewport, a simple video wrapper, infinite lines, full screen hero images and positioning elements in the center of the window.

* * *

Jeremy Keith had some interesting thoughts concerning extensible web components and he asks what use they have for the end user:

Compare Service Workers to web components.

First of all, ask the question “who benefits from this technology?” In the case of Service Workers, it’s the end users. They get faster websites that handle network failure better. In the case of web components, there are no direct end-user benefits. Web components exist to make developers lives easier. That’s absolutely fine, but any developer convenience gained by the use of web components can’t come at the expense of the user—that price is too high.

* * *

A while back the team at CloudFour announced Drizzle:

Drizzle is Cloud Four’s tool for generating pattern libraries and style guides. It started as a fork of Fabricator, incorporating features based on our team’s recent project needs and other style guides we admired. It uses Node, Gulp and Handlebars to generate static HTML you can host anywhere. Out of the box, it includes our Gulp tasks and Handlebars helpers to make prototyping and pattern-building fast and fun.

* * *

Matthew Ström wrote about how to design better data tables:

After being the bread and butter of the web for most of its early history, tables were cast aside by many designers for newer, trendier layouts. But while they might be making fewer appearances on the web these days, data tables still collect and organize much of the information we interact with on a day-to-day basis.

Matthew digs into tiny typographic details that make all the difference, too. Like the difference between various types of numerals that are available:

A note from the archives

Speaking of tables, a while back we published a guide to the table element that goes into great depth about how to use them: how to make them responsive for a number of different layouts and screen sizes, how to style them nicely and how to avoid key problems that designers bump into time and time again.

 A Complete Guide to the Table Element 

What have you learnt this week?

Robin Rendle: This week I’ve been struggling with collaborating on a large project with a new team. And I think the difficulty here lies in what the concept of what the word “work” means for many of our team members.

If that sounds confusing and/or patronising, hear me out.

For lots of designers and developers, “work” is often the act of creating something new. When we sit down we want to be iterating in Sketch or Figma or Photoshop, or perhaps we feel that “work” is complete when we’re writing code and building fresh, shiny new things. However, there is a delicate moment in the process of designing a large web app when adding new code and implementing new designs becomes a serious detriment to the overall process of design.

In fact, “work” must also be seen as subtracting design components, refactoring code and deleting pretty much everything that isn’t entirely necessary. This is because if we don’t continue to clean up behind us then we’re bound to have problems with efficiency.

In other words, the more code that’s in our app the more inefficient we are. And the more inefficient we are as designers and developers then the longer it takes to ship new features and improve the overall user experience.

In other other words, code bloat is directly related to the user experience.



Until next time!
Team CSS-Tricks
Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list