Front End Web Development

Design Tooling is Still Figuring Itself Out

Css Tricks - Thu, 09/14/2017 - 1:20pm

It probably always will be, to be fair.

At the moment, there are all kinds of things that design software is struggling to address. The term "screen design" is common, referring to the fact that many of us are designing very specifically for screens, not print or any other application and screens have challenges unique to them. We have different workflows these days than in the past. We have different collaboration needs. We have different technological and economic needs.

Let's take a peak at all this weirdness.

Design tooling is still figuring out Responsive Design

It's almost taken for granted these days that any given new web project (or redesign) will be responsive design. Responsive design is the answer for screens of different sizes and different capabilities. So we can't just design a 1280px wide version and call it a day.

Software like Sketch has made multiple artboards of arbitrary sizes a first class citizen to help with this.

This doesn't completely solve the idea that we're designing for screens that can be of wildly different sizes, dimensions, and densities, but it certainly helps communicate a lot more than just one size does.

But how do you create all the different artboards you want to create? Copy and paste, resize stuff, and drag stuff around? You could, but design tooling is starting to figure itself out here a little. Here's a Sketch plugin called Constraints that is trying to make this easier:

Figma has this idea of constraints built right in:

Webflow is a unique design tool in that you aren't quite dragging things around as totally arbitrarily as you would in something like Sketch or Illustrator. Instead, you're manipulating things that are actually 1-to-1 representations of real web layout properties like margin, padding, and even things like flexbox and grid. They've made working with the Webflow editor naturally responsive, and you can see it immediately as you work.

Design tooling is still figuring out Collaboration

Imagine you do your designing with Photoshop. You have `.psd` files that are your designs. How do you deliver them? Email? Maybe, but that's a little messy for teams. Perhaps you have a shared Dropbox folder?

Adobe knows design teams need this. They have "Creative Cloud", which does everything from managing the actual software you have access to, to getting you access to design assets like fonts and stock photography, to helping you share files:

Sure, but that doesn't do anything besides giving everyone access to those files. There is even merge conflict danger, if multiple people are working on the same file.

The files themselves are only part of the story of collaboration. What about version history? What about notes and feedback? What about approval?

Invision is a big player in design tooling, and I would guess mostly because of the collaborative features. You don't create your designs in InVision, for the most part, you just upload them there and then do more with them, like talk about them:

Talking about designs overtop the designs themselves in Invision.

What if there wasn't really "files" at all to deal with? When your design software is a web app, the design documents aren't really documents you need to deal with yourself, they just kinda exist within the app. Figma is like this:

Plus, Figma offers teams, meaning collaboration amongst a team is just a matter of logging in and having shared access to everything.

Taking collaboration even further, Figma has realtime designing features. As in, Google-docs (or CodePen Collab Mode) style editing-at-the-same-time action:

Image from here.

As a testament to design tooling still figuring itself out, I don't think Figma pushes this feature very heavily anymore, marketing-wise. I think they have found that despite it being a showy feature, actual design teams don't really like it. Who knew.

This is an interesting read by Meng To comparing Figma and Sketch.

Design tooling is still figuring out Assets and Versions

Design can be more than screen mockups. A design team might need access to an icon set, a branding system, a color palette, a set of flat graphics...

Take a look at Lingo, which is an app explicitly for this. Collaboration is a key feature, but its team collaboration is based on assets.

I can imagine a tool like that not only making the sharing of assets easier but keeping the version of assets everyone is using up to date. As in, preventing people from keeping a "folder full of icons" on their local machine and having it go stale.

And speaking of versions... I'm sure we've all experienced (and heard the jokes) about files named things like:


Developers don't really have this problem thanks to version control. Where is version control for designers? Apps like Abstract are trying to help with that.

Abstract doesn't only help with collaboration, but version management as well.

Everything is saved. Nothing is lost. Version control you can trust.

Design tooling is still figuring out Design Systems

As I recently said:

We're not building pages, we're building systems. Style guides. Design systems. Pattern libraries. These things are becoming a standard part of the process for web projects. They will probably become the main deliverable.

We've seen design software slowly start to accommodate this kind of thinking over the years. Even things as simple as type styles took their sweet time making their way from places like InDesign (where they couldn't be lived without) over to Illustrator and Photoshop. They are so clearly needed that newer design tools always seem to have them.

Yet, if type is specifically what you are doing, there are tooling options specifically for that. Tools like Typecast are for that:

Or TypeNugget, which we've covered here:

One web app design tool, UX Pin, is focusing heavily on being a design tool for design systems.

We've covered that before, and you can see more about what they mean here:

Design tooling is still figuring out Interactivity

As much advancement as we're seeing with design tooling, we're also seeing that it's very hard for single tools to do it all. Interaction design is a great example of this.

Hover states! Swiping and gestures! Page transitions! Animations! Tap feedback!

As good as Sketch is at certain things, there is next to nothing there for handling interactivity. One one hand, it's a shame. Screen design is loaded with interactivity. It's definitely on designers minds and a must for their job. On the other hand, I might worry about bloat and lack of focus if all design tools tried to pack in interactivity tools.

Check out Framer, who are tackling interaction design head-on:

Framer is a visual design tool, with all the familiar styling tools (including some interesting constraint-based responsive stuff), but approach the interactive stuff literally through coding within the tool:

Design tooling is still figuring out Platforms

I feel just a smidge guilty every time I talk about Sketch, because I know it's macOS only. That excludes a huge chunk of people who work on websites. They don't even plan on it. Familiar players like Adobe generally make their products cross-platform, but even that is limited compared to the web-based tools, which work on any platform. I'd say web based tools like Figma and UX Pin have a strong advantage with the inherent collaboration and sharing abilities along with the cross-platform ability.

But desktop machines, regardless of platform, aren't the only story here. Certainly Apple had designers in mind with the iPad Pro:

What kind of design software is available on that? Affinity Designer seems to be working on it:

It's quiet in the office today and I'm feeling mischievous... Who fancies a bit of #affinitydesigner #ipad #shakycam teaser? 🐱

— Matt Priestley (@mattp4478) July 12, 2017

And tools like Graphic:

Design tooling is still figuring out Trends

You can fill a box with noise in Sketch:

I'm not entirely sure why, but I imagine it might influence designers to use noise in a design. There is no one-click option to fill an area with tiny beetles, but I imagine if there was we'd see more divs filled with tiny beetles.

Adobe Experience Design has a "background blur" feature, no doubt inspired by recent Apple designs.

Heck, I can distort and object by "Polar Coordinates" in Photoshop.

Design tools influence design, and design influences design tooling. Whatever the default opacity settings are will influence design. Whatever the default gradient colors are. Whatever the default easing values are.

Design tooling is still figuring out Data

I imagine you've heard some full throated arguments both for and against lorem ipsum text. "It doesn't reflect real design!", you might hear. Whatever you think, it sure is interesting to see design tooling try to take on designing with real data.

Adobe Experience Design has some interesting features along these lines. Take their Repeat Grid tool, which is an interesting prototyping tool in it's own right, and can also help fill in real text and images:

Webflow helps with designing with data quite a bit too. They've said:

Designing with real data gives us a deeper understanding of how a page will function. In part because it surfaces all the “problems” designers strive to avoid in their mockups, such as long headlines, low-quality images, etc.

Designing with real content gives both writers and designers better insight into what they need to do.

They have an in-built CMS to store structured data, then design tools to help get that data onto designs:

Design tooling is still figuring out Pricing Models

I bet many of you remember when Adobe software was an (expensive) one-off cost. Now the transformation is complete and we're looking at anywhere from 10 to 50 dollars monthly to use the software, which I suppose makes it more accessible to some and less accessible to some.

Web apps are almost always a monthly cost. Figma is $12/month/user for teams. Business wise, for the creators of software, that seems to be the smart move. My own experience echoes that. But I can see how that can be a turn off for a native software product. Sketch is a flat $99, which I admit feels nice.

This will never shake out, surely, and it's not just one-off cost vs. monthly. There are free trials, freemium models, in-app purchases, and add-on models that all could and are being experimented with across the tooling landscape.

Wrapping Up

There is so much more to this, and I'm hardly the person to cover it.

For instance, I didn't talk too much about designing in the browser, but there is certainly tooling there. Aside from those few typography-focused apps, we didn't focus on the proliferation of tiny single-feature apps out there. Coolors is an example of that that I quite like. Not to mention the loads of design resource sites. We also didn't talk about wild crossover projects like React-Sketchapp.

Let's end with an interesting related article. Colm Tuite recently wrote "Design tools are running out of track. Here’s how we can fix them." Here's one of his points that I think is salient:

Why can’t designers just design the actual product?! Ultimately, all mockups are disposable, yet designers spend months tweaking them to perfection. That time would be much better spent tweaking the actual product.

Design Tooling is Still Figuring Itself Out is a post from CSS-Tricks

?Deliver exceptional customer experiences in your product

Css Tricks - Thu, 09/14/2017 - 6:12am

(This is a sponsored post.)

Pendo delivers the only complete platform for Product Teams that helps companies create great products. The Pendo Product Experience Platform enables Product Teams to understand product usage, collect user feedback, measure NPS, assist users in their apps and promote new features in product - all without requiring any engineering resources. This unique combination of capabilities is all built on a common infrastructure of product data and results in improved customer satisfaction, reduced churn, and increased revenue.

Pendo is the proven choice of innovative product leaders at Salesforce, Proofpoint, Optimizely, Citrix, BMC and many more leading companies.

Request a demo of Pendo today.

Direct Link to ArticlePermalink

?Deliver exceptional customer experiences in your product is a post from CSS-Tricks

Is there any value in people who cannot write JavaScript?

Css Tricks - Thu, 09/14/2017 - 6:07am

Mandy Michael:

If all you do in your job is write JS, that is fantastic and you are awesome, just like all the people that write CSS or have a focus in a particular area like accessibility, SVG, animation etc.

What I am very concerned about is that many still don’t see value in being skilled in CSS & HTML. This attitude is something I just don’t understand. All of us working together provide value in our industry.

+1 on all Mandy's points.

I suspect HTML and CSS skill will swing back higher in desirability a bit as design trends swing toward more complicated looks. More interesting layouts being one of those things. I tend to find those developers who only dabble in HTML/CSS fall over quickly when it comes to from-scratch work that involves layout. There is a lot of gray area here too. For example, I write Ruby code, but I fall over quickly when it comes to even moderately complex things.

I also suspect this conversation is rooted in the fact that HTML, CSS, and JavaScript are so intertwined, it tickles some people the wrong way to see other people stop at the first two.

Direct Link to ArticlePermalink

Is there any value in people who cannot write JavaScript? is a post from CSS-Tricks

Join us for the Type@Cooper West Fall Lecture Series

Nice Web Type - Wed, 09/13/2017 - 10:03am

The final section of Type@Cooper West’s 2017 lecture series begins Tuesday, September 19 with Aaron Marcus’s talk “The Past 100 Years of the Future.”

After Aaron’s talk, three more speakers will take the stage this fall. These lectures are all free and open to the public, but it’s never too soon to grab a seat — they do fill up!

We’re pleased to sponsor this series, which takes place at the Koret Auditorium at the San Francisco Public Library Main Branch, 100 Larkin Street. All talks begin at 6 p.m. You can watch videos of the past lectures here.

Type@Cooper West Workshops

Looking for to immerse yourself further in typographic learning? Consider one of the many workshops Type@Cooper West are presenting this autumn:

Design Resource Sites

Css Tricks - Wed, 09/13/2017 - 6:34am

Sometimes when you're designing something, you need little helping hands. Perhaps a nice stock photo. Perhaps a happy little color palette. Perhaps a bleep or bloop sound. Perhaps the perfect icon.

There are tons and tons of sites that do those things. There are fewer sites that curate these design resource sites into manageable, high-quality groups. So allow me to abstract that yet another step and provide a selected list of those types of sites.

The Stocks

This is the one I was trying to remember the other day that spurred the idea for this little post. I quite like how you can just hang out on this site and click around to what you need by the type of resource, and the resource sites themselves just come up iframed.

Sans Francisco

Sans Francisco is a colorful and organize list of design resources by Robinson Greig.

Design Resources (.party!)

The winner of the best-named and best-TLD goes to Jessica Paoli. Similar to Sans Francisco, it's a big long curated one-pager full or resources organized by type.


More of what we're looking for!

A hand-picked directory of the best free resources for creatives.


I suspect this is the one that inspired The Stocks, as it also does the iframe thing. You click the site you want along the persistent left sidebar, and it loads the resource site on the right.

Design Resource Sites is a post from CSS-Tricks

Say Bonjour to the Typekit Team at ATypI Montréal

Nice Web Type - Tue, 09/12/2017 - 7:30am

Going to Quebec this week for the 61st annual ATypI Conference? Hopefully we will see you there!

On Wednesday night, Dan Rhatigan, Senior Manager of Adobe Type, presents “Marginalized Typography” at 6 p.m.

Hear a Progress report from the Adobe Typography Customer Advisory Board on Thursday at 9:40 a.m. from member Yves Peters.

Find us Saturday afternoon as Taro Yamamoto, Senior Manager of Japanese Typography, answers the question “Is harmony possible between East Asian and Western glyphs?” at 12:30 p.m.

All three talks take place at the UQAM, Cœur des sciences.

Finally, join us at Atypique After Dark to raise a glass to another successful conference. This Typekit sponsored event takes place at 8 Queen.

Do you put anything in your code specifically for “Find in Project”?

Css Tricks - Tue, 09/12/2017 - 4:07am

During a having a team meeting the other day, a code formatting idea came up that I thought was super interesting. It had to do with formatting code in a such a way that made it easier to find what you were looking for later with any code editors "Find in Project" feature.

Here's what it was.

When declaring a function in JavaScript, put a space after the function name and before the opening parenthesis, like...

function doSomething () { }

That space between doSomething and () is perfectly fine. Then when you call the function, don't use a space, like this:


It's just a syntax convention.

But now, "Find in Project" is more useful. If we want to quickly find where that function was defined, we can search for "doSomething ()", and if we want to find instances of where it is used, we can look for "doSomething()".

You could extend the idea to classes or whatever too:

class myThing { constructor () { } doThing () { } } let example = new myThing(); example.doThing();

I'd say that's worth doing.

It reminds me of when I need to where a Ruby method is definied, I can always search for "def foo" since that "def " is required for creating the method.

I can imagine a scenario where it might be useful to define base classes in CSS like .module { but then if it's a variation or nested or used again for any other reason... .module{.

Here's a classic:

// TODO: 😅

— Charlotte Dann (@charlotte_dann) September 10, 2017

Leaving TODO comments throughout your code base turns a "Find in Project" for "TODO" an instant list of things you need to work on. Surely that could be even more nuanced, incorporating things like priority levels and assignments. Perhaps even emoji's to help like Charlotte suggested!

Here's an interesting one:

Use long classes/variables, mark future refactor points with comments. What are you looking for?

— Chris Pauley (@ChrisPauley) September 10, 2017

I like the idea of "long names". I suppose the longer and more descriptively you name things, the easier they are to search for and get specific results (avoiding repetitive matches like you would with very simple names).

Comments are a great place to leave things to search for. I often use a convention where I put my own name in the comment if I want people to know it was me leaving the comment, but it's not necessarily for me.

.thing { overflow: hidden; /* [Chris]: ugkghk this fixed a layout thing but I didn't have time to figure out exactly why. */ }

A smattering of responses:

At top of each template I add "<!-- Start [name of template] -->", at bottom, same but "End." Helps FIP and in browser-rendered code.

— Dale Henry Geist (@dalehenrygeist) September 10, 2017

I use consistent and natural language to name things, so when documentation goes stale, at least the code itself is still easy to stab at.

— John James Jacoby (@JJJ) September 10, 2017

Not in the code itself but in Sublime settings folder_exclude_patterns you can pass in an array of folders to exclude from all searches

— Ian C Woodward (@IanCWoodward) September 10, 2017

// TODO &#x1f615;
// FIXME &#x1f632;
// WT* &#x1f624;&#x1f4a3;

— Kamran Ahmed (@kamranahmedse) September 10, 2017

ctags is a lifesaver.

— Harry Roberts (@csswizardry) September 10, 2017

Naming conventions mate! BEM-esque those classes up `--thing` is always easier to find than `thing`

— James Bosworth (@fltwhte) September 11, 2017

Do you put anything in your code specifically for “Find in Project”? is a post from CSS-Tricks

HTML Templates via JavaScript Template Literals

Css Tricks - Mon, 09/11/2017 - 4:43am

You know those super cool backticks-for-strings in new JavaScript?

let emotion = `happy`; let sentence = `Chris is feeling ${emotion}`;

Besides the variable interpolation in there being mighty handy, the do multi-line strings wonderfully, making them great for chunks of HTML:

const some_html = ` <div class="module"> <h2>${data.title}</h2> <p>${data.content}</p> </div> `;

That doesn't look overly different than JSX does it?! Maybe we'd do something like that as a React component:

class MyModule extends React.Component { render() { return <div class="module"> <h2>{this.props.title}</h2> <p>{this.props.content}</p> </div>; } }

But what if we don't really need React, or any other fairly-large-ish JavaScript framework?

What if the only thing we want is the ability to render HTML templates and also really efficiently re-render them when we need to, like React is known for?

As far as I understand it, that's what projects like lit-html are for. As I write, it's a pretty new library from Google and the Polymer folks.

It allows you to define an HTML template with regular template literals, like this:

import { html, render } from './lit-html.js'; const helloTemplate = (data) => html` <div class="module"> <h2>Hello ${}!</h2> <p>${data.content}</p> </div> `;

Then you call the render function, passing it that template, the data, and where you want it rendered:

let data = { name: "Chris", content: "Just trying to figure stuff out." } render(helloTemplate(data), document.body);

Then say the data changes... you call render again: = "Sammy"; render(helloTemplate(data), document.body);

And this is where lit-html shines. It's smart enough to only update the parts of the DOM it needs to.

Here's a little comparison where some data is changed, then the templates re-rendered. If we innerHTML the whole thing, well, the entire DOM is changed. With lit-html it just changes smaller inner parts.

Here's a little video where you can see the DOM-updating difference:

lit-html on the left, "regular" on the right. Demo project.

There is another project along these lines too. I don't know quite enough to judge, but it's a bit older and I believe it's a bit more robust. It's called HyperHTML.

HyperHTML also allows you to create templates and render them. And most importantly rerender them efficiently.

Here's a demo where the data comes from the Quotes on Design API and inserted into a template:

See the Pen Trying HyperHTML by Chris Coyier (@chriscoyier) on CodePen.

Kinda cool that these mini-libraries exist that do useful things for us, so when situations arise that we want a feature that a big library has, but don't want to use the whole big library, we got smaller options.

HTML Templates via JavaScript Template Literals is a post from CSS-Tricks

Css Tricks - Sun, 09/10/2017 - 10:34am

This little website pulls in all the main stories from CNN and strips almost everything from the design; styles, images, fonts, ads, colors. Nada, zilch, gone. At first it looks like nothing but hypertext and it feels like an extraordinary improvement but Sam Saccone made a thread about potential improvements that the team could use to make that experience even faster such as server side rendering and replacing the React framework with something smaller, like Preact.

Either way this approach to news design is refreshing. However, I can’t find anything more about the the motivations for building this version of besides the announcement on Twitter. It would certainly be fascinating to learn if CNN built this specifically for people caught in disastrous situations where battery life and load time might be a serious matter of life and death.

Direct Link to ArticlePermalink is a post from CSS-Tricks

Compilers are the New Frameworks

Css Tricks - Sat, 09/09/2017 - 11:33am

Tom Dale:

Increasingly, the bytes that get shipped to browsers will bear less and less resemblance to the source code that web developers write.

Indeed. I suspected the same:

Because performance matters so much and there is so much opportunity to get clever with performance, we'll see innovation in getting our code bases to production. Tools like webpack (tree shaking, code splitting) are already doing a lot here, but there is plenty of room to let automated tools work magic on how our code ultimately gets shipped to browsers.

Tom also says:

This is a loss in some ways (who else got their web development start with View Source?) but is a huge win for users, particularly in emerging markets.

It seems to me today's world of GitHub, StackOverflow, and the proliferation of learning resources more than make up for learning via our own website spelunking, not to mention how insightful today's DevTools are, even if what they are looking at isn't hand-authored.

Direct Link to ArticlePermalink

Compilers are the New Frameworks is a post from CSS-Tricks

6 Months of Working Remotely Taught Me a Thing or Ten

Css Tricks - Fri, 09/08/2017 - 1:08pm

Peter Anglea writes up his key takeaways after six months on the job with a new front-end position. His points ring true to me as a remote worker and the funny thing is that each one of the suggestions is actually applicable to anyone in almost any front-end job, whether it happens to be in-house or remote.

The full post is worth reading, though the list breaks down to:

  1. Be as available as possible
  2. Communicate clearly
  3. Go out of your way to be human
  4. Offer praise and positive sentiments early and often
  5. Create a comfortable space conducive to productivity
  6. Put your pants on
  7. Go outside
  8. Turn on your camera
  9. Work on more than one project at a time
  10. Take advantage of the perks… and be responsible

One item I would add to the list is to manage up in day-to-day conversations. In other words, give frequent and regular updates with examples of progress so that your client/boss/whomever has no doubt that you are being productive from afar. I suppose that goes along with "communicate clearly" but takes it one step further.

Direct Link to ArticlePermalink

6 Months of Working Remotely Taught Me a Thing or Ten is a post from CSS-Tricks

The average web page is 3MB. How much should we care?

Css Tricks - Fri, 09/08/2017 - 1:07pm

Tammy Everts with a deep dive into the average page size, which seems to grow year in and year out.

It's a little perplexing that the average page size trends up each year as performance has become a growing concern on the forefront of our minds, but Tammy has keen insights that are worth reading because she suggests that user experience isn't always about page size and that bloat is far from the only metric we should be concerned.

Correlating page size with user experience is like presenting someone with an entire buffet dinner and assuming that it represents what they actually ate. To properly measure user experience, we need to focus on the content – such as the navbar or hero product image – that users actually want to consume. The best performance metric for measuring user experience is one that measures how long the user waits before seeing this critical content.

Spot on. There is such a thing as making intentional use of file size, depending on whether or goal is super fast load times or communicating an idea. Not that the two are mutually exclusive, but the trade-off can certainly exist.

Direct Link to ArticlePermalink

The average web page is 3MB. How much should we care? is a post from CSS-Tricks

Screen Readers and CSS: Are We Going Out of Style (and into Content)?

Css Tricks - Thu, 09/07/2017 - 2:06pm

The big takeaway in this post is that screen readers do not always read content the way it is styled in CSS. Toss in the fact that not all screen readers speak or read markup the same way and that there are differences in how they render content in different browsers and the results become...well different. Kind of like cross-browser testing CSS, but with speech.

The key points:

  • Different screen reader/browser pairings behave differently
  • DOM order is everything
  • Containers are only visual

That first point is crucial. For example, beware of using <sup> to style prices in place of using a proper decimal point between dollars and cents because some screen readers will read that as a whole number. Wait, you mean, the price is $12.99 and not $1,299? Phew. &#x1f605;

Direct Link to ArticlePermalink

Screen Readers and CSS: Are We Going Out of Style (and into Content)? is a post from CSS-Tricks

Upgrade Your JavaScript Error Monitoring

Css Tricks - Thu, 09/07/2017 - 3:39am

(This is a sponsored post.)

Automatically detect and diagnose JavaScript errors impacting your users with Bugsnag. Get comprehensive diagnostic reports, know immediately which errors are worth fixing, and debug in a fraction of the time compared to traditional tools.

Bugsnag detects every single error and prioritizes errors with the greatest impact on your users. Get support for 50+ platforms and integrate with the development and productivity tools your team already uses.

Bugsnag is used by the world's top engineering teams including Airbnb, Pandora, MailChimp, Square, Shopify, Yelp, Lyft, Docker, and Cisco. Start your free trial today.

Direct Link to ArticlePermalink

Upgrade Your JavaScript Error Monitoring is a post from CSS-Tricks

So You Want To Be a Senior Developer?

Css Tricks - Thu, 09/07/2017 - 3:39am

Let me start with a classic caveat: I cannot bestow upon you the title of senior developer. I have no special insight into how companies these days are hiring and promoting people to senior developer roles.

What I can tell you is what qualities I think would make for a heck of a senior developer. I can tell you how I think about the distinction between senior developers and those who aren't quite there yet. Should I, one day, be in charge of a legion of developers where it was my call what level they were at, this is what I would think about.

A senior front end developer has experience.

There is no way around this one. You aren't going to roll into your first job a senior developer.

You probably won't roll into any new job a senior developer. Even if I was pretty sure a person was going to be a senior developer and previously has been, I'd probably wouldn't start them there, just because there is no guarantee they can be just as effective in a completely new environment. Even if the tech is the same, the people aren't.

A senior front-end developer has a track record of good judgment.

Development isn't only about writing code, it's about making choices. Good choices are researched, discussed, and influenced by instinct and experience. When you make a choice, you are demonstrating your judgement to everyone watching. If you make it clear that your judgement is informed, ethical, and as transparent as it can be, that's a good thing. If you do that over and over, that makes you senior.

A senior developer has positive impact beyond the code.

If the only thing you contribute to a team is coding chops, you probably aren't a particularly good candidate for a senior developer. Code isn't written in a bubble. Good code, anyway. Good code is a reflection of a team, a product of a cohesive vision, and a foundation for an organizations goals. To participiate in good code, and demonstrate your ability to be a senior developer, you don't isolate yourself, you sit at the middle of the table (metaphorically).

Soft skills are no joke. A senior developer can write clear emails, rope people in around ideas, lead meetings, and just clean the damn soup exlosion in the microwave before it turns into a productivity-draining war of passive agressive post it notes (metaphorically).

A senior developer is helpful, not all-knowing.

Say a co-worker comes up to you and asks you something, and you have no idea what the answer is. Does that mean you aren't ready to be a senior developer? Absolutely not. It's all about how you answer that question that makes you senior or not. Can you help suss out why they are asking to get more context and be more broadly helpful? Can you offer to help find the answer together? Will you do some research afterward and follow up with them?

Even if you do know the exact answer, just delivering it and spinning your chair back around to continue typing is a worse answer than digging into the question together with your co-worker.

Being a senior developer doesn't mean you have to know everything, it means you can help find out anything.

A senior front-end developer is a force multiplier.

This is my favorite one by far.

There are developers who are, on paper at least, multiple times as effective as others. Twice the commits, twice the lines of code written, twice the bugs closed. You can absolutely aspire to be a developer like that, but it doesn't automatically give you the senior card.

The best (and most senior) developer on a team is the one who multiplies the effectiveness of their fellow developers. Perhaps that amazing developer on your team is able to be that way because someone else is freeing up their day to make that possible. Because someone else has created a rock solid dev enviornment that fosters productivity. Because someone else taught them and gave them the keys to be that way.

A developer who is a force multiplier for the entire team is absolutely a senior developer.

I can't promise that doing these things will make you a senior developer.

I have no power to tell the chain of command at your office to think about these things and factor them in to their decision making. I can say that this would be my advice to them, should they be seeking it, on how to promote developers.

Are you in the position to promote developers? Have you? Share your thinking with us!

So You Want To Be a Senior Developer? is a post from CSS-Tricks

For the love of God, please tell me what your company does

Css Tricks - Wed, 09/06/2017 - 1:11pm

Kasper Kubica goes on a humorous rant about the way companies describe themselves on their websites:

More and more often, upon discovering a new company or product, I visit their website hoping to find out what it is they do, but instead get fed a mash of buzzwords about their “team” and “values”. And this isn’t a side dish?—?this is the main entrée of these sites, with a coherent explanation of the company’s products or services rarely occupying more than a footnote on the menu.

While many of the examples and points are funny at their core, there's clearly a level of frustration laced between the lines and it's easy to understand why:

At this point, I’ve given up. I’m back to Google, back to searching ... because even though I came to [the site] knowing exactly what I wanted, I have no idea what they offer.

While this isn't so much about front-end development, it is a good reminder about content's role in usability and user experience. We can have the cleanest, performant and accessible code ever committed but the site still has to communicate something and do it well for it to be useful to the end user.

Direct Link to ArticlePermalink

For the love of God, please tell me what your company does is a post from CSS-Tricks

Now in Early Access: Visual search on Typekit

Nice Web Type - Wed, 09/06/2017 - 5:00am

Today we’re rolling out a whole new way to search for fonts visually on Typekit. The first step is one many of you have already mastered: Look for neat type in the world around you.

Our new visual search feature allows you to upload a picture of type—photos of signage or posters, flat artwork, any image file that contains a line of text—and see a list of all the fonts in our inventory that are visually similar to it. We’re launching this as an Early Access feature for now, and we’d love for you to try it out and let us know what you think.

Once you flip on Early Access in your account settings, you’ll see a camera icon in the search field, which toggles open a file selection prompt. You can also drag and drop image files from your desktop onto any Typekit page to start a visual search.

You’ll also see a new Discover section on, which is a quick stop for all kinds of typographic inspiration: visual search, foundries, curated lists, and more.

Getting started with a visual search on Typekit

So let’s say you’ve found some nifty type or lettering on a sign out in the world, and now you’d like to find fonts that are similar to it.

Photo credit: Maria Freyenbacher on

Snap a photo of the sign. To start a visual search, turn on Early Access, then use the camera icon in the search bar to select a photo from your hard drive, or (if you’re on your desktop) drag the photo into your browser window.

First, we’ll ask you to select the region of the photo you want to scan for type. We’ll try to select one for you automatically, but you can also move or resize the box to tell us precisely which text to search on.

Next, we’ll try to recognize the text in the sample you uploaded. If we got it right, you can move on to the next step, or else you can update the text to correct it.

Then, finally, we’ll show you a list of similar fonts from Typekit’s inventory.

We don’t hang on to the photos you upload, so be sure to add any fonts you like to your Favorites or take a screenshot of the results page. Some styles will definitely have more relevant results than others, but we’re improving the engine all the time.

So what can’t it do?

At the moment, visual search has some limitations. Toggle on the Tips while working with photos to see a brief guide. Generally, you’ll get best results if you use these guidelines.

  • Type samples that are clear, crisp, and straight on flat backgrounds will yield better, more consistent results. Pictures of text that are skewed, blurry, or low in contrast will sometimes work, but also might confuse the engine and return poorer-quality results.
  • Visual search works with a single line of text. If your image contains multiple lines, use the crop tool to select just one line. We recommend picking a line that has the most distinctive characters, such as Q, R, or lowercase ‘a’.
  • Some letter shapes/styles work better than others. Sans-serif and serif type tend to return better, more consistent results than connected scripts or blackletter, and mixed-case text tends to work better than all-caps or small-caps.
  • Right now we’re only able to recognize and match Latin characters. We are hoping to add support for other scripts in the future.

Above all, this feature should be a lot of fun to try out, and we hope it connects even more people with the type they see around them every day.

Let us know what you think! Spend two minutes on our brief survey, and if you have a whole lot to say feel free to drop an email to — we’ll be grateful for your feedback.

Working with Schemas in WordPress

Css Tricks - Wed, 09/06/2017 - 3:34am

I polled a group of WordPress developers about schemas the other day and was surprised by the results. Even though almost all of them had heard of schemas and were aware of the potential benefits they provide, very few of them were actually using them on a project.

If you're unfamiliar with schemas, they are HTML attributes that help search engines understand the content structure and know how to display it correctly in search engine results. We've all worked on projects where SEO was a big ol' concern, so schemas can be a key deliverable to help optimize and delivering search performance.

We're going to dig into the concept of schemas a little more in this post and then walk through a real-life application of how to use them in a WordPress environment.

A Schema Overview

Schemas are a vocabulary of HTML attributes and values that describe the content of the document. The concept of this vocabulary was born out of a collaboration between members of Google, Microsoft, Yahoo and Yandex and has since become a project that is maintained by those founding organizations, in addition to members from the W3C and individuals in the community. In fact, you can view the Schema community's activity and connect with the group on their open community page.

You may see the term structured data tossed around when schemas are being discussed and that's because it's a good description for how schemas work. They provide a lexicon and hierarchy in the form of data that add structure and detail to HTML markup. That, in turn, makes the content of an HTML document much easier for search engines to crawl, read, index and interpret. If you see structured data somewhere, then we're really talking about schemas as well.

The Schema Format

Schema can be served in three different formats: Microdata, JSON-LD and RDFa. RDFa is one we aren't going to delve into in this post because Microdata and JSON-LD make up the vast majority of use cases. In fact, as we dive into a working example later in this post, we're going to shift our entire focus on JSON-LD.

Let's illustrate the difference between Microdata and JSON-LD with an example of a business listing website, where visitors can browse information about local businesses. Each business is going to be an item that has additional context, such as a business type, a business name, a description, and hours of operation. We want our search engines to read that data for the sake of being able to render that information cleanly when returning search results. You know, something like this:

Walgreens Pharmacy uses schema to display an address, contact information, operating hours, and even additional site links.

Here's how we would use Microdata to display business hours in a similar way:

<div itemscope itemtype=""> <h1 itemprop="name">Philippa's Pharmacy</h1> <p itemprop="description"> A superb collection of fine pharmaceuticals. </p> <p>Open: <span itemprop="openingHours" content="Mo,Tu,We,Th 09:00-12:00"> Monday-Thursday 9am-noon </span> </p> </div>

The same can be achieved via JSON-LD:

<script type="application/ld+json"> { "@context": "", "@type": "Pharmacy", "name": "Philippa's Pharmacy", "description": "A superb collection of fine pharmaceuticals.", "openingHours": "Mo,Tu,We,Th 09:00-12:00" } </script> How Schema Impacts SEO

The reason we're talking about schema at all is because we care about how our content is interpreted by search engines, so it's fair to wonder just how much impact schema has on a site's actual search engine ranking and performance.

Google's John Mueller participated in a video chat back in 2015 and gave a very clear indication of how important schemas are becoming in the field of search engine optimization. The fact that the schema project was founded and is maintained by giants in the search engine industry gives us a good idea that, if we want to rank and index well, then we'll consider schema as part of our SEO strategy.

While there may be other sites and posts out there that have better data to back up the importance of schema, the thing we ought to point to is the impact it has on user experience. If someone were to look up "Tom Petty Concert Tickets" in Google and get a list of results back, it's easy to assume that the result with upcoming dates nicely outlined in the results would be the one that stands out the most and is most identifiably useful, even if it is not the first result in the bunch.

Oh nice, one of those results has schema that displays concert dates near me!

Again, this is conjecture and other posts or sites may have data to support the impact that schema has on search result rankings, but having a little bit of influence on the way search engines read and display our content on their pages is a nice affordance for us as front-end developers and we'll take what we can get.

Deciding Which Format to Use

It really comes down to your flavor preference at the end of the day. That said, Google's schema documentation is nearly all centered around JSON-LD so, if you're looking for more potential impact in Google's results, that might be your starting point. Google even has a handy Webmasters tool that generates data in JSON-LD making it perhaps the lowest barrier to entry if you're getting started.

Knowing What Data Can Be Structured

Google's guide to structured data is the most exhaustive and comprehensive resource on the topic and gives the best indication of what data can be structured with examples of how to do it.

The bottom line is that schema wants to categorize content into "types" and these are the types that Google currently recognizes as of this writing:

  • Articles
  • Books
  • Courses
  • Datasets
  • Events
  • Fact Check
  • Job Postings
  • Local Businesses
  • Music
  • Podcasts
  • Products
  • Recipes
  • Reviews
  • TV & Movies
  • Videos

In addition to content type, Google will also look for structured data that serve as UI enhancements to the search results:

  • Breadcrumbs
  • Sitelinks Searchbox
  • Corporate Contact Information
  • Logos
  • Social Profile Links
  • Carousels

You can really start to see the opportunities we have to help influence search results as far as what is displayed and how it is displayed.

Managing Schema in WordPress

Alright, we've spent a good amount of time diving into the concept of schemas and how they can benefit a site's search engine optimization, but how the heck do we work with it? I find the best way to tackle this is with a real-life example, so that's what we're going to do.

In this example, we're using WordPress as our content management system and will put the popular Advanced Custom Fields (ACF) plugin to use. In the end, we will have a way to generate schema for our content on the fly using valid JSON-LD format.

Some readers may be tempted to stop me here and ask why we aren't using the built-in schema management tools of popular WordPress SEO plugins, like Yoast and Schema. There are actually a ton of WordPress plugins that help add structured data to a site and going with any of them is a legitimate option that you ought to consider. In my experience, these plugins do not provide the level of detail I am looking for in projects that require access and control over every content type I need, such as opening hours and contact information for a local business.

That's where ACF comes to my rescue! Not only can we create the exact fields we need to capture the data we want to generate and serve, but we can do it dynamically as part of our everyday content management in WordPress.

Let's use a local business (spoiler alert on the Content Type, am I right?!) website as an example. We're going to create a custom page in WordPress that contains custom fields that allow us to manage the structured data for the business.

Here's what that will look like:

I've put put all the working examples in this post together in a GitHub repo that you can use as a starting point or simply to follow along as we break down the steps to make it happen.

Download on GitHub

Step 1: Create the Custom Options Page

Setting up a custom admin page in WordPress can be done directly in our functions.php file:

// Create a General Options admin page // `options_page` is going to be the name of ACF group we use to set up the fields // We can use that as a conditional statement to create the page against if (function_exists('acf_add_options_page')) { acf_add_options_page(array( 'page_title' => 'General Options', 'menu_title' => 'General Options', 'menu_slug' => 'general-options', 'capability' => 'edit_posts', 'redirect' => false )); }

That snippet gives us a new link in the WordPress navigation called General Options, but only after hooking things up in ACF in the next step. Of course, you can call this whatever you'd like. The point is that we now have a method for creating a page and a way to access it.

Step 2: Create the Custom Fields

Well, our General Options page is useless if there's nothing in it. With Advanced Custom Fields installed and activated, we now need to head over there and set up the fields needed to capture and store our structured data.

Here is how our custom fields will be organized:

  • Company Logo
  • Company Address
  • Hours of Operation
  • Closed Days
  • Contact Information
  • Social Media Links
  • Schema Type

There are a lot of fields here and you can use the acf-export.json file from the GitHub repo to import the fields into ACF rather than manually creating them all yourself. Note that some of the fields are use a repeater functionality that is only currently supported with a paid ACF extension.

Step 3: Linking Custom Fields to General Options

Now that we have the custom fields set up in ACF, our next task is to map them our custom General Options page. Really, this step comes as the custom fields are bring created. ACF provides settings for each field group that allows you to specify whether the fields should be displayed on specific pages.

In other words, for each field group we've created, be sure to go back in and confirm that the General Options page is selected so that the fields only display there in WordPress:

Now our General Options page has an actual set of options we can manage!

Please Note:: The way the data is organized in the example files is how I've grown accustomed to managing scheme. You may find it easier to organize the fields in other ways, and that's totally cool. And, of course, if you are working with a different content type than this local business example, then you may not need all of the fields we are working with here or be required to use others.

Step 4: Enter Data

Alright, without data, our structured data would just be ... um, structured? Whatever that would be, let's enter the data.

  • Company Logo: Google specifies the ideal size to be 151px square. Google will use this image if it displays company information to the right of the search results. You can see this in action by searching a well-known company, like Google itself.
  • Building Photo: This can add some interest to the same company profile card where the Company Logo is displayed, but this field also impacts search results within maps. Google recommends a square 200px image.
  • Schema Type: Select the content type for the schema. In this example, we are dealing with a local business, so that is the content type.
  • Address: These are pretty straight-forward text fields and will be used both in search results and the same profile card as the Company Logo.
  • Openings: The specification for opening hours can be found on the website. The way we've set this up in the example is by using a repeater field that contains four sub-fields to specify the days of the week, the starting open time, the ending open time, and a toggle to distinguish between open and closed time ranges. This should cover all our bases, according to the schema documentation.
  • Special Days: These are holidays (e.g. Christmas) where the business might not be open during its regular operating hours. It's nice that schema provides this flexibility because it allows users to see those exceptions if they happen to be searching on those days.
  • Contact: There are a lot of settings available for contact data. We are putting three of them use here with this example, namely Type (which is used like a business Department, say, Sales or Customer Service), Phone (which is the number to call), and Option (which supports options for TollFree and HearingImpairedSupported
Step 5: Generate the the JSON-LD

This is where the rubber meets the road. If so far we have created a place to manage our data, made the fields for that data, and actually entered the data, then we now need to take that collected data and spit it out into a format that search engines can put to use. Again, the GitHub repo has the finished result of what we're dealing with, but let's dig into that code to see how that data is fetched from ACF and converted to JSON-LD.

To read all the values and create the JSON-LD tag, we need to go into the functions.php file and write a snippet that injects our JSON data to the site header. We're going to inject the content type, address, and some data about the site that already exists in WordPress, such as the site name and address:

// Using `wp_head` to inject to the document <head> add_action('wp_head', function() { $schema = array( // Tell search engines that this is structured data '@context' => "", // Tell search engines the content type it is looking at '@type' => get_field('schema_type', 'options'), // Provide search engines with the site name and address 'name' => get_bloginfo('name'), 'url' => get_home_url(), // Provide the company address 'telephone' => '+49' . get_field('company_phone', 'options'), //needs country code 'address' => array( '@type' => 'PostalAddress', 'streetAddress' => get_field('address_street', 'option'), 'postalCode' => get_field('address_postal', 'option'), 'addressLocality' => get_field('address_locality', 'option'), 'addressRegion' => get_field('address_region', 'option'), 'addressCountry' => get_field('address_country', 'option') ) ); }

The logo is not really a required bit of information, we we're going to check whether it exists, then fetch it if it does and add it to the mix:

// If there is a company logo... if (get_field('company_logo', 'option')) { // ...then add it to the schema array $schema['logo'] = get_field('company_logo', 'option'); }

Working with repeater fields in ACF requires a little extra consideration, so we're going to have to write a loop to fetch and add the social media links:

// Check for social media links if (have_rows('social_media', 'option')) { $schema['sameAs'] = array(); // For each instance... while (have_rows('social_media', 'option')) : the_row(); // ...add it to the schema array array_push($schema['sameAs'], get_sub_field('url')); endwhile; }

Adding the data from the Opening Hours fields is a little tricky, but only because we added that additional differentiation between open and closed time ranges. Basically, we need to check for the $closed variable we set up as part of the field then output the times so they fall in right group.

// Let's check for Opening Hours rows if (have_rows('opening_hours', 'option')) { // Then set up the array $schema['openingHoursSpecification'] = array(); // For each row... while (have_rows('opening_hours', 'option')) : the_row(); // ...check if it's marked "Closed"... $closed = get_sub_field('closed'); // ...then output the times $openings = array( '@type' => 'OpeningHoursSpecification', 'dayOfWeek' => get_sub_field('days'), 'opens' => $closed ? '00:00' : get_sub_field('from'), 'closes' => $closed ? '00:00' : get_sub_field('to') ); // Finally, push this array to the schema array array_push($schema['openingHoursSpecification'], $openings); endwhile; }

We can use almost the same snippet to output our Special Days data:

// Let's check for Special Days rows if (have_rows('special_days', 'option')) { // For each row... while (have_rows('special_days', 'option')) : the_row(); // ...check if it's marked "Closed"... $closed = get_sub_field('closed'); // ...then output the times $special_days = array( '@type' => 'OpeningHoursSpecification', 'validFrom' => get_sub_field('date_from'), 'validThrough' => get_sub_field('date_to'), 'opens' => $closed ? '00:00' : get_sub_field('time_from'), 'closes' => $closed ? '00:00' : get_sub_field('time_to') ); // Finally, push this array to the schema array array_push($schema['openingHoursSpecification'], $special_days); endwhile; }

The last piece is our Contact Information data. Again, we're working with a loop that creates and array that then gets injected into the schema array which, in turn gets injected into the document <head>.

Notice that the phone number needs the country code, which you can swap out for your own:

// Let's check for Contact Information rows if (get_field('contact', 'options')) { // Then create an array of the data, if it exists $schema['contactPoint'] = array(); // For each row of contact information... while (have_rows('contact', 'options')) : the_row(); // ...fetch the following fields $contacts = array( '@type' => 'ContactPoint', 'contactType' => get_sub_field('type'), 'telephone' => '+49' . get_sub_field('phone') ); // Let's not forget the Option field if (get_sub_field('option')) { $contacts['contactOption'] = get_sub_field('option'); } // Finally, push this array to the schema array array_push($schema['contactPoint'], $contacts); endwhile; } Let's Marvel at Out Work!

We now can encode our data in JSON and put into a script tag right before the closing of our add_action function.

echo '<script type="application/ld+json">' . json_encode($schema) . '</script>';

The final script might look something like like this:

<script type="application/ld+json"> { "@context": "", "@type": "Store", "name": "My Store", "url": "", "telephone": "+49 1234 567", "address": { "@type": "PostalAddress", "streetAddress": "Musterstraße", "postalCode": "13123", "addressLocality": "Berlin", "addressRegion": "Berlin", "addressCountry": "Deutschland" }, "sameAs": [""], "openingHoursSpecification": [{ "@type": "OpeningHoursSpecification", "dayOfWeek": ["Mo", "Tu", "We", "Th", "Fr"], "opens": "07:00", "closes": "20:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Sa", "Su"], "opens": "00:00", "closes": "00:00" }, { "@type": "OpeningHoursSpecification", "validFrom": "2017-08-12", "validThrough": "2017-08-12", "opens": "10:00", "closes": "12:00" }], "contactPoint": [{ "@type": "ContactPoint", "contactType": "customer support", "telephone": "+491527381923", "contactOption": ["HearingImpairedSupported"] }] } </script> Conclusion

Hey, look at that! Now we can enhance a website's search engine presence with optimized data that allows search engines to crawl and interpret information in an organized way that promotes better user experience.

Of course, this example was primarily focused on JSON-LD, Google's schema specifications and using WordPress as a vehicle for managing and generating data. If you have written up ways of managing and handling data on other formats, using different specs and other content management systems, please share it here in the comments and we can start to get a bigger picture for improving SEO all around.

Working with Schemas in WordPress is a post from CSS-Tricks

Breaking the Grid

Css Tricks - Tue, 09/05/2017 - 1:32pm

If you thought CSS Grid solves issues where overflowed content escaping the confines of a horizontal layout, then think again. Dave Rupert writes up two ways he unintentionally broke outside the grid and how he wrangled things back into place.

As a Front-End developer nothing bothers me more than seeing an unexpected horizontal scrollbar on a website. While building out a checkout layout with CSS Grid I was surprised to find something mysterious was breaking the container. I thought Grid sort of auto-solved sizing.

Eventually I found two ways to break CSS Grid. As it would happen, I was doing both in the same layout.

Turns out these special cases boil down to:

  • Using overflow-x on an grid element
  • Using grid on form controls (or, more specifically, replaced elements)

Dave's solution is a set of CSS rules affectionately named Fit Grid, which is a helper class that effectively removes and replaces the automated min-width: auto property assigned to grid items. This is a super helpful resource, though he admits it toes the line of "Clearfix 2.0" territory.

Direct Link to ArticlePermalink

Breaking the Grid is a post from CSS-Tricks

Improving your web font performance

Nice Web Type - Tue, 09/05/2017 - 9:14am

We work hard to deliver the best performance by continuously updating and improving our web font service. In the last few years, we’ve added support for asynchronous font loading, language based subsets, HTTP/2, and just last week CSS kits.

But there’s even more you can do on your end to improve performance, which is just one of the topics I get into in the Webfont Handbook — released earlier today with A Book Apart. If you aren’t sure where to begin with your own site, these three optimization tips are a great place to start. I’ll walk through these in a little detail today, but do check out the book for a whole lot more.

1. Review your font usage

The default JavaScript embed code will load all fonts and variations in a kit, even if you don’t use them. You can significantly reduce your kit size if you remove fonts and variations you don’t use.

While you’re in the kit editor, take the opportunity to take a look at your subsetting options. The “All Characters” subset delivers the entire font to your site and usually results in a large kit size. You can reduce the size of your kit by switching to the Default subset, or by using a language-based subset.

It’s worth pointing out that subsetting can also be very dangerous. If you accidentally remove characters that you actually need they’ll show up in a fallback font. When in doubt, the Default subset with OpenType Features checked is the right choice.

2. Load fonts and kits asynchronously

The default JavaScript embed code will load the JavaScript kit in a render-blocking way. However, once the JavaScript loads, the kit will load the fonts asynchronously. Why wait for the JavaScript to load? You’ll get better performance and the same behavior by switching to the advanced embed code; the advanced embed code will load both the fonts and JavaScript asynchronously.

One downside of loading fonts asynchronously is that you’ll need to manage the flash of unstyled text (FOUT) yourself. Typekit has excellent documentation on font events, and the Webfont Handbook goes into great detail on tricks to minimise FOUT.

3. Preload and preconnect

Web fonts are a critical component of your site’s performance; you want your content to appear as soon as possible and preferably in the correct font. You can help the browser prioritize resources by using preconnect and preload resource hints.

Preconnect is used to tell the browser that you’ll soon connect to a hostname. Once the browser sees the preconnect hint, it opens a connection in the background, so it’s ready to use.

Then by the time the browser comes across the Typekit embed code (you’re using the advanced embed code, right?), it can re-use the connection to Typekit’s font network. Doing this can easily save several seconds.

Preload is another resource hint, which not only creates a connection but actually downloads the resource as well so it’s right there when you need it. This can be useful to preload Typekit’s JavaScript or CSS file.

<link rel="preload" href="" as="script" crossorigin>

<link rel="preload" href="" as="style" crossorigin>

Preconnect and preload hints are especially useful when you’re using the advanced embed code or a CSS kit. The browser will create a connection, or fetch the kit JavaScript with high priority in the background without blocking rendering. You get the benefits of asynchronous loading and the performance of render-blocking resources.

The Webfont Handbook is packed with insights that came from several years of looking into and following these issues — not only web font performance, but also licensing, text rendering, CSS syntax, and more. If your work regularly involves type on the web, the Webfont Handbook just might be your new go-to guide.

Syndicate content
©2003 - Present Akamai Design & Development.