In this week’s roundup of platform news, Chrome introduces a new attribute for loading, accessibility specifications for web developers, and the BBC moves visualizations to the Shadow DOM.
Chrome ships the loading attribute
The HTML loading attribute for lazy-loading images and iframes is now supported in Chrome. You can add loading="lazy" to defer the loading of images and iframes that are below the viewport until the user scrolls near them.
Google suggests either treating this feature as a progressive enhancement or using it on top of your existing JavaScript-based lazy-loading solution.
This feature has not yet been added to the HTML Standard (but there is an open pull request), and multiple links to Google’s documentation are listed on its Chrome Status page.
Provides practical advice on how to use ARIA in HTML, with an emphasis on dynamic content and advanced UI controls (the “five rules of ARIA use” are defined here)
The BBC has moved from to Shadow DOM for the embedded interactive visualizations on its website. This has resulted in significant improvements in load performance (“more than 25% faster”).
The available Shadow DOM polyfills didn’t reliably prevent styles from leaking across the Shadow DOM boundary, so they decided to instead fall back to in browsers that don’t support Shadow DOM.
Shadow DOM […] can deliver content in a similar way to iframes in terms of encapsulation but without the negative overheads […] We want encapsulation of an element whose content will appear seamlessly as part of the page. Shadow DOM gives us that without any need for a custom element.
One major drawback of this new approach is that CSS media queries can no longer be used to conditionally apply styles based on the content’s width (since the content no longer loads in a separate, embedded document).
With iframes, media queries would give us the width of our content; with Shadow DOM, media queries give us the width of the device itself. This is a huge challenge for us. We now have no way of knowing how big our content is when it’s served.
The next version of Chrome will introduce the Largest Contentful Paint performance metric; this new metric is a more accurate replacement for First Meaningful Paint, and it measures when the largest element is rendered in the viewport (usually, the largest image or paragraph of text) (via Phil Walton)
Microsoft has created a prototype of a new tool for viewing a web page’s DOM in 3D; this tool is now experimentally available in the preview version of Edge (via Edge DevTools)
Tracking prevention has been enabled by default in the preview versions of Edge; it is set to balanced by default, which “blocks malicious trackers and some third-party trackers” (via Techdows)
Read more news in my new, weekly Sunday issue. Visit webplatform.news for more information.
It’s the first thing your eyes look for when you’re switching tabs.
That’s one way of explaining what a favicon is. The tab area is a much more precious screen real-estate than what most assume. If done right, besides being a label with icon, it can be the perfect billboard to represent what’s in or what’s happening on a web page.
The CSS-Tricks Favicon
Favicons are actually at their most useful when you’re not active on a tab. Here’s an example:
Imagine you’re backing up photos from your recent summer vacation to a cloud service. While they are uploading, you’ve opened a new tab to gather details about the places you went on vacation to later annotate those photos. One thing led to the other, and now you’re watching Casey Neistat on the seventh tab. But you can’t continue your YouTube marathon without the anxious intervals of checking back on the cloud service page to see if the photos have been uploaded.
It’s this type of situation where we can get creative! What if we could dynamically change the pixels in that favicon and display the upload progress? That’s exactly what we’ll do in this article.
In supported browsers, we can display a loading/progress animation as a favicon with the help of JavaScript, HTML and some centuries-old geometry.
Jumping straight in, we’ll start with the easiest part: adding the icon and canvas elements to the HTML.
In practical use, you would want to hide the on the page, and one way of doing that is with the HTML hidden attribute.
<canvas hidden width=32 height=32></canvas>
I’m going to leave the visible on the page for you to see both the favicon and canvas images animate together.
Both the favicon and the canvas are given a standard favicon size: 32 square pixels.
For demo purposes, in order to trigger the loading animation, I’m adding a button to the page which will start the animation when clicked. This also goes in the HTML:
<button>Load</button>
Now let’s set up the JavaScript. First, a check for canvas support:
onload = ()=> {
canvas = document.querySelector('canvas'),
context = canvas.getContext('2d');
if (!!context) {
/* if canvas is supported */
}
};
Next, adding the button click event handler that will prompt the animation in the canvas.
button = document.querySelector('button');
button.addEventListener('click', function() {
/* A variable to track the drawing intervals */
n = 0,
/* Interval speed for the animation */
loadingInterval = setInterval(drawLoader, 60);
});
drawLoader will be the function doing the drawing at intervals of 60 milliseconds each, but before we code it, I want to define the style of the lines of the square to be drawn. Let’s do a gradient.
/* Style of the lines of the square that'll be drawn */
let gradient = context.createLinearGradient(0, 0, 32, 32);
gradient.addColorStop(0, '#c7f0fe');
gradient.addColorStop(1, '#56d3c9');
context.strokeStyle = gradient;
context.lineWidth = 8;
In drawLoader, we’ll draw the lines percent-wise: during the first 25 intervals, the top line will be incrementally drawn; in second quarter, the right line will be drawn; and so forth.
The animation effect is achieved by erasing the in each interval before redrawing the line(s) from previous interval a little longer.
During each interval, once the drawing is done in the canvas, it’s quickly translated to a PNG image to be assigned as the favicon.
function drawLoader() {
with(context) {
clearRect(0, 0, 32, 32);
beginPath();
/* Up to 25% */
if (n<=25){
/*
(0,0)-----(32,0)
*/
// code to draw the top line, incrementally
}
/* Between 25 to 50 percent */
else if(n>25 && n<=50){
/*
(0,0)-----(32,0)
|
|
(32,32)
*/
// code to draw the top and right lines.
}
/* Between 50 to 75 percent */
else if(n>50 && n<= 75){
/*
(0,0)-----(32,0)
|
|
(0,32)----(32,32)
*/
// code to draw the top, right and bottom lines.
}
/* Between 75 to 100 percent */
else if(n>75 && n<=100){
/*
(0,0)-----(32,0)
| |
| |
(0,32)----(32,32)
*/
// code to draw all four lines of the square.
}
stroke();
}
// Convert the Canvas drawing to PNG and assign it to the favicon
favicon.href = canvas.toDataURL('image/png');
/* When finished drawing */
if (n === 100) {
clearInterval(loadingInterval);
return;
}
// Increment the variable used to keep track of the drawing intervals
n++;
}
Now to the math and the code for drawing the lines.
Here’s how we incrementally draw the top line at each interval during the first 25 intervals:
n = current interval,
x = x-coordinate of the line's end point at a given interval.
(y-coordinate of the end point is 0 and start point of the line is 0,0)
At the completion of all 25 intervals, the value of x is 32 (the size of the favicon and canvas.)
So…
x/n = 32/25
x = (32/25) * n
The code to apply this math and draw the line is:
moveTo(0, 0); lineTo((32/25)*n, 0);
For the next 25 intervals (right line), we target the y coordinate similarly.
I’m so excited to be heading to Zürich, Switzerland for Front Conference (Love that name and URL!). I’ve never been to Switzerland before, so I’m excited about that, but of course, the web nerd in me is excited to be at the conference with lots of fellow webfolk. Some old friends, but mostly new people I’ve never met before but admire their work. Yessssss.
I cracked open DevTools on their speaker page and re-arranged the layout so I could take some screenshots of the incredible lineup:
If you’re able to make it, come! As you know I’m bullish on conferences and their ability to get you thinking and feeling more connected to the web design and development community.
I’ll be there
I’ll be opening the conference as the first talk on the first day (after the workshops on Wednesday). I’ve been thinking a lot about what has been happening to front-end development and what it is to be a front-end developer so I’ll be talking about all that. I hope it’s a nice broad start to a whole conference dedicated to the topic.
Can’t go but want to watch it live?
Good idea! Perhaps you could schedule a bit of a brown bag at work?
Follow @frontzurich on Twitter and they’ll be announcing how to watch the livestream the days of the conference (Thursday August 29th and Friday August 30th).
It has been 8 months since Gutenberg was launched as the default content editor in WordPress. Depending who you ask, you may hear that Gutenberg is the worst or the best thing that has happened to WordPress (or anything in between). But something that most people seem to agree with, is that Gutenberg has been steadily improving. At the current pace of development, it’s only a matter of time until its most outstanding issues have been dealt with and the user experience becomes truly pleasant.
Gutenberg is an ongoing work in progress. While using it, I experience maddening nuisances, such as floating options that I can’t click on because the block placed below gets selected instead, unintuitive grouping of blocks, columns with so much gap that make them useless, and the “+” element calling for my attention all over the page. However, the problems I encounter are still relatively manageable (which is an improvement from the previous versions) and, moreover, Gutenberg has started making its potential benefits become a reality: Many of its most pressing bugs have been ironed out, its accessibility issues are being solved, and new and exciting features are continuously being made available. What we have so far is pretty decent, and it will only get better and better.
Let’s review the new developments which have taken place since Gutenberg’s launch, and where it is heading to.
Gutenberg arrived just in time to kick-start the rejuvenation of WordPress, to attempt to make WordPress appealing to developers once again (and reverse its current status of being the most dreaded platform). WordPress had stopped looking attractive because of its focus on not breaking backwards compatibility, which prevented WordPress from incorporating modern code, making it look pale in comparison with newer, shinier frameworks.
Many people argue that WordPress was in no peril of dying (after all, it powers more than 1/3rd of the web), so that Gutenberg was not really needed, and they may be right. However, even if WordPress was in no immediate danger, by being disconnected from modern development trends it was headed towards obsolescence, possibly not in the short-term but certainly in the mid to long-term. Let’s review how Gutenberg improves the experience for different WordPress stakeholders: developers, website admins, and website users.
Developers have recently embraced building websites through JavaScript libraries Vue and React because (among other reasons) of the power and convenience of components, which translates into a satisfying developer-experience. By jumping into the bandwagon and adopting this technique, Gutenberg enables WordPress to attract developers once again, allowing them to code in a manner they find gratifying.
Website admins can manage their content more easily, improve their productivity, and achieve things that couldn’t be done before. For instance, placing a Youtube video through a block is easier than through the TinyMCE Textarea, blocks can serve optimal images (compressed, resized according to the device, converted to a different format, and so on) removing the need to do it manually, and the WYSIWYG (What You See Is What You Get) capabilities are decent enough to provide a real-time preview of how the content will look like in the website.
By giving them access to powerful functionality, website users will have a higher satisfaction when browsing our sites, as experienced when using highly-dynamic, user-friendly web applications such as Facebook or Twitter.
In addition, Gutenberg is slowly but surely modernizing the whole process of creating the website. While currently it can be used only as the content editor, some time in the future it will become a full-fledged site builder, allowing to place components (called blocks) anywhere on a page, including the header, footer, sidebar, etc. (Automattic, the company behind WordPress.com, has already started work on a plugin adding full site editing capabilities for its commercial site, from which it could be adapted for the open-source WordPress software.) Through the site-building feature, non-techy users will be able to add very powerful functionality to their sites very easily, so WordPress will keep welcoming the greater community of people working on the web (and not just developers).
Fast Pace Of Development
One of the reasons why Gutenberg has seen such a fast pace of development is because it is hosted on GitHub, which simplifies the management of code, issues and communication as compared to Trac (which handles WordPress core), and which makes it easy for first-time contributors to become involved since they may already have experience working with Git.
Being decoupled from WordPress core, Gutenberg can benefit from rapid iteration. Even though a new version of WordPress is released every 3 months or so, Gutenberg is also available as a standalone plugin, which sees a new release every two weeks (while the latest release of WordPress contains Gutenberg version 5.5, the latest plugin version is 6.2). Having access to powerful new functionality for our sites every two weeks is very impressive indeed, and it enables to unlock further functionality from the broader ecosystem (for instance, the AMP plugin requires Gutenberg 5.8+ for several features).
Headless WordPress To Power Multiple Stacks
One of the side effects of Gutenberg is that WordPress has increasingly become “headless”, further decoupling the rendering of the application from the management of the content. This is because Gutenberg is a front-end client that interacts with the WordPress back-end through APIs (the WP REST API), and the development of Gutenberg has demanded a consistent expansion of the available APIs. These APIs are not restricted to Gutenberg; they can be used together with any client-side framework, to render the site using any stack.
An example of a stack we can leverage for our WordPress application is the JAMstack, which champions an architecture based on static sites augmented through 3rd party services (APIs) to become dynamic (indeed, Smashing Magazine is a JAMstack site!). This way, we can host our content in WordPress (leveraging it as a Content Management System, which is what it is truly good at), build an application that accesses the content through APIs, generate a static site, and deploy it on a Content Delivery Network, providing for lower costs and greater access speed.
New Functionality
Let’s play with Gutenberg (the plugin, not the one included in WordPress core, which is available here) and see what functionality has been added in the last few months.
Block Manager
Through the block manager, we can decide what blocks will be available on the content editor; all others will be disabled. Removing access to unwanted blocks can be useful in several situations, such as:
Many plugins are bundles of blocks; when installing such a plugin, all their blocks will be added to the content editor, even if we need only one
As many as 40 embed providers are implemented in WordPress core, yet we may need just a few of them for the application, such as Vimeo and Youtube
Having a large amount of blocks available can overwhelm us, impairing our workflow by adding extra layers that the user needs to navigate, leading to suboptimal use of the time; hence, temporarily disabling unneeded blocks can help us be more effective
Similarly, having only the blocks we need avoids potential errors caused by using the wrong blocks; in particular, establishing which blocks are needed can be done in a top-down manner, with the website admin analyzing all available blocks and deciding which ones to use, and imposing the decision on the content managers, who are then relieved from this task and can concentrate on their own duties.
Enabling/disabling blocks through the manager (Large preview)
Cover Block With Nesting Elements
The cover block (which allows us to add a title over a background image, generally useful for creating hero headers) now defines its inner elements (i.e. the heading and buttons, which can be added for creating a call to action) as nested elements, allowing us to modify its properties in a uniform way across blocks (for instance, we can make the heading bold and add a link to it, place one or more buttons and change their background color, and others).
The cover block accepts nested elements (Large preview)
Block Grouping And Nesting
Please beware: These features are still buggy! However, plenty of time and energy is being devoted to them, so we can expect them to work smoothly soon.
Block grouping allows to group several blocks together, so when moving them up or down on the page, all of them move together. Block nesting means placing a block inside of a block, and there is no limit to the nesting depth, so we can have blocks inside of blocks inside of blocks inside of… (you’ve got me by now). Block nesting is especially useful for adding columns on the layout, through a column block, and then each column can contain inside any kind of block, such as images, text, videos, etc.
Blocks can be grouped together, and nested inside each other (Large preview)
Migration Of Pre-Existing Widgets
Whereas in the past there were several methods for adding content on the page (TinyMCE content, shortcodes, widgets, menus, etc.), the blocks attempt to unify all of them into a single method. Currently, newly-considered legacy code, such as widgets, is being migrated to the block format.
Recently, the “Latest Posts” widget has been re-implemented as a block, supporting real-time preview of how the layout looks when configuring it (changing the number of words to display, showing an excerpt or the full post, displaying the date or not, etc).
The “Latest posts” widget includes several options to customize its appearance (Large preview)
Motion Animation
Moving blocks up or down the page used to involve an abrupt transition, sometimes making it difficult to understand how blocks were re-ordered. Since Gutenberg 6.1, a new feature of motion animation solves this problem by adding a realistic movement to block changes, such as when creating, removing or reordering a block, giving a greatly improved visual cue of the actions taken to re-order blocks. In addition, the overall concept of motion animation can be applied throughout Gutenberg to express change and thus improve the user experience and provide better accessibility support.
Blocks have a smooth effect when being re-ordered. (Large preview)
Functionality (Hopefully) Coming Soon
According to WordPress founder Matt Mullenweg, only 10% of Gutenberg’s complete roadmap has been implemented by now, so there is plenty of exciting new stuff in store for us. Work on the new features listed below has either already started, or the team is currently experimenting with them.
Block directory
A new top-level item in wp-admin which will provide block discovery. This way, blocks can be independently installed, without having to ship them through a plugin.
Navigation blocks
Currently, navigation menus must be created through their own interface. However, soon we will be able to create these through blocks and place them anywhere on the page.
Inline installation of blocks
Being able to discover blocks, the next logical step is to be able to install a new block on-the-fly, where is needed the most: On the post editor. We will be able to install a block while writing a post, use the new block to generate its HTML, save its output on the post, and remove the block, all without ever browsing to a different admin page.
Snap to grid when resizing images
When we place several images on our post, resizing them to the same width or height can prove to be a painful process of trying and failing repeatedly until getting it right, which is far from ideal. Soon, it will be possible to snap the image to a virtual grid layer which appears on the background as the image is being resized.
WordPress Is Becoming Attractive (Once Again)
Several reasons support the idea that WordPress will soon become an attractive platform to code for, as it used to be once upon a time. Let’s see a couple of them.
PHP Modernization
WordPress’s quest to modernize does not end with incorporating modern JavaScript libraries and tooling (React, webpack, Babel): It also extends to the server-side language: PHP. WordPress’s minimum version of PHP was recently bumped up to 5.6, and should be bumped to version 7.0 as early as December 2019. PHP 7 offers remarkable advantages over PHP 5, most notably it more than doubles its speed, and later versions of PHP (7.1, 7.2 and 7.3) have each become even faster.
Even though there seems to be no official plans to further upgrade from PHP 7.0 to its later versions, once the momentum is there it is easier to keep it going. And PHP is itself being improved relentlessly too. The upcoming PHP 7.4, to be released in November 2019, will include plenty of new improvements, including arrow functions and the spread operator inside of arrays (as used for modern JavaScript), and a mechanism to preload libraries and frameworks into the OPCache to further boost performance, among several other exciting features.
Reusability Of Code Across Platforms
A great side effect of Gutenberg being decoupled from WordPress is that it can be integrated with other frameworks too. And that is exactly what has happened! Gutenberg is now available for Drupal, and Laraberg (for Laravel) will soon be officially released (currently testing the release candidate). The beauty of this phenomenon is that, through Gutenberg, all these different frameworks can now share/reuse code!
Conclusion
There has never been a better time to be a web developer. The pace of development for all concerned languages and technologies (JavaScript, CSS, image optimization, variable fonts, cloud services, etc) is staggering. Until recently, WordPress was looking at this development trend from the outside, and developers may have felt that they were missing the modernization train. But now, through Gutenberg, WordPress is riding the train too, and keeping up with its history of steering the web in a positive direction.
Gutenberg may not be fully functional yet, since it has plenty of issues to resolve, and it may still be some time until it truly delivers on its promises. However, so far it is looking good, and it looks better and better with each new release: Gutenberg is steadily bringing new possibilities to WordPress. As such, this is a great time to reconsider giving Gutenberg a try (that is, if you haven’t done so yet). Anyone somehow dealing with WordPress (website admins, developers, content managers, website users) can benefit from this new normal. I’d say this is something to be excited about, wouldn’t you?
Cool cool. But what if you had several list items, and you wanted them all to move on hover, but each one offset with staggered timing?
The trick lies within transition-delay and applying a slightly different delay to each item. Let’s select each list item individually and apply different delays. In this case, we’ll select an internal span just for fun.
This might be a little finicky for your taste. Say your lists starts to grow, perhaps to seven or more items. The staggering suddenly isn’t working on the new ones because this doesn’t account for that many list items.
You could pass in the delay from the HTML if you wanted:
@media (hover: hover) {
.list li a span {
transform: translateY(100px);
transition: 0.2s;
}
.list:hover span {
transform: translateY(0);
transition-delay: var(--delay); /* comes from HTML */
}
}
Or if you’re Sass-inclined, you could create a loop with more items than you need at the moment (knowing the extra code will gzip away pretty efficiently):
@media (hover: hover) {
/* base hover styles from above */
@for $i from 0 through 20 {
.list li:nth-child(#{$i + 1}) span {
transition-delay: 0.05s * $i;
}
}
}
That might be useful whether or not you choose to loop for more than you need.
In CSS, we have the ability to access currentColor which is tremendously useful. Sadly, we do not have access to anything like currentBackgroundColor, and the color-mod() function is still a ways away.
With that said, I am sure I am not alone when I say I’d like to style some links based on the context, and invert colors when the link is hovered or in focus. With CSS custom properties and a few, simple utility classes, we can achieve a pretty powerful result, thanks to the cascading nature of our styles:
To achieve this, we’ll need to specify our text and background colors with utility classes (containing our custom properties). We’ll then use these to define the color of our underline, which will expand to become a full background when hovered.
Let’s start with our markup:
<section class="u-bg--green">
<p class="u-color--dark">
Lorem ipsum dolor sit amet, consectetur adipiscing elit, <a href="#">sed do eiusmod tempor incididunt</a> ut labore et dolore magna aliqua. Aliquam sem fringilla ut morbi tincidunt. Maecenas accumsan lacus vel facilisis. Posuere sollicitudin aliquam ultrices sagittis orci a scelerisque purus semper.
</p>
</section>
This gives us a block containing a paragraph, which has a link. Let’s set up our utility classes. I’ll be defining four colors that I found on Color Hunt. We’ll create a class for the color property, and a class for the background-color property, which will each have a variable to assign the color value (--c and --bg, respectively). So, if we were to define our green color, we’d have the following:
If you are a Sass user, you can automate this process with a map and loop over the values to create the color and background classes automatically. Note that this is not required, it’s merely a way to create many color-related utility classes automatically. This can be very useful, but keep track of your usage so that you don’t, for example, create seven background classes that are never used on your site. With that said, here is the Sass code to generate our classes:
$colors: ( // Define a named list of our colors
'green': #08ffc8,
'light': #fff7f7,
'grey': #dadada,
'dark': #204969
);
@each $n, $c in $colors { // $n is the key, $c is the value
.u-color--#{$n} {
--c: #{$c};
color: #{$c};
}
.u-bg--#{$n} {
--bg: #{$c};
background-color: #{$c};
}
}
What happens if we forget to apply a utility class in your markup, though? The --c variable would naturally use currentColor… and so would --bg! Let’s define a top-level default to avoid this:
html {
--c: #000000;
--bg: #ffffff;
}
Cool! Now all we need is to style our link. We will be styling all links with our trusty element in this article, but you could just as easily add a class like .fancy-link.
Additionally, as you may know, links should be styled in the “LoVe-HAte” order: :link, :visited, :hover (and :focus!), and :active. We could use :any-link, but browser support isn’t as great as CSS custom properties. (Had it been the other way around, it wouldn’t have been much of an issue.)
We can start declaring the styles for our links by providing an acceptable experience for older browsers, then checking for custom property support:
/* Styles for older browsers */
a {
color: inherit;
text-decoration: underline;
}
a:hover,
a:focus,
a:active {
text-decoration: none;
outline: .0625em solid currentColor;
outline-offset: .0625em;
}
a:active {
outline-width: .125em;
}
@supports (--a: b) { /* Check for CSS variable support */
/* Default variable values */
html {
--c: #000000;
--bg: #ffffff;
}
a {
/*
* Basic link styles go here...
*/
}
}
Let’s then create the basic link styles. We’ll be making use of custom properties to make our styles as DRY as possible.
First, we need to set up our variables. We want to define a --space variable that will be used on various properties to add a bit of room around the text. The link’s color will also be defined in a variable with --link-color, with a default of currentColor. The fake underline will be generated using a background image, whose size will be adjusted depending on the state with --bg-size, set to use the --space value by default. Finally, to add a bit of fun to this, we’ll also fake a border around the link when it’s :active using box-shadow, so we’ll define its size in --shadow-size, set to 0 in it’s inactive state. This gives us:
We’ll first need to adjust for the fallback styles. We’ll set our color to make use of our custom property, and remove the default underline:
color: var(--link-color);
text-decoration: none;
Let’s next create our fake underline. The image will be a linear-gradient with two identical start and end points: the text’s color --c. We make sure it only repeats horizontally with background-repeat: repeat-x;, and place it at the bottom of our element with background-position: 0 100%;. Finally, we give it its size, which is 100% horizontally, and the value of --bg-size vertically. We end up with this:
For the sake of our :active state, let’s also define the box shadow, which will be non-existent, but with our variable, it’ll be able to come to life: box-shadow: 0 0 0 var(--shadow-size, 0) var(--c);
That’s the bulk of the basic styles. Now, what we need to do is assign new values to our variables depending on the link state.
The :link and :visited are what our users will see when the link is “idle.” Since we already set up everything, this is a short ruleset. While we technically could skip this step and declare the --c variable in the initial assignment of --link-color, I’m assigning this here to make every step of our styles crystal clear:
a:link,
a:visited {
--link-color: var(--c);
}
The link now looks pretty cool, but if we interact with it, nothing happens… Let’s create those styles next. Two things need to happen: the background must take up all available height (aka 100%), and the text color must change to be that of the background, since the background is the text color (confusing, right?). The first one is simple enough: --bg-size: 100%;. For the text color, we assign the --bg variable, like so: --link-color: var(--bg);. Along with our pseudo-class selectors, we end up with:
Look at that underline become a full-on background when hovered or focused! As a bonus, we can add a faked border when the link is clicked by increasing the --shadow-size, for which our --space variable will come in handy once more:
a:active {
--shadow-size: var(--space);
}
We’re now pretty much done! However, it looks a bit too generic, so let’s add a transition, some padding and rounded corners, and let’s also make sure it looks nice if the link spans multiple lines!
For the transitions, we only need to animate color, background-size and box-shadow. The duration is up to you, but given links are generally around 20 pixels in height, we can put a small duration. Finally, to make this look smoother, let’s use ease-in-out easing. This sums up to:
transition-property: color, background-size, box-shadow;
transition-duration: 150ms;
transition-timing-function: ease-in-out;
will-change: color, background-size, box-shadow; /* lets the browser know which properties are about to be manipulated. */
We’ll next assign our --space variable to padding and border-radius, but don’t worry about the former — since we haven’t defined it as an inline-block, the padding won’t mess up the vertical rhythm of our block of text. This means you can adjust the height of your background without worrying about line-spacing! (just make sure to test your values)
Finally, to ensure the styles applies properly on multiple lines, we just need to add box-decoration-break: clone; (and prefixes, if you so desire), and that’s it.
When you’re done, we should have these styles:
/* Styles for older browsers */
a {
color: inherit;
text-decoration: underline;
}
a:hover,
a:focus,
a:active {
text-decoration: none;
outline: .0625em solid currentColor;
outline-offset: .0625em;
}
a:active {
outline-width: .125em;
}
/* Basic link styles for modern browsers */
@supports (--a: b) {
/* Default variable values */
html {
--c: #000000;
--bg: #ffffff;
}
a {
/* Variables */
--space: .125em;
--link-color: currentColor;
--bg-size: var(--space);
--shadow-size: 0;
/* Layout */
padding: var(--space); /* Inline elements won't affect vertical rhythm, so we don't need to specify each direction */
/* Text styles */
color: var(--link-color);/* Use the variable for our color */
text-decoration: none; /* Remove the default underline */
/* Box styles */
border-radius: var(--space); /* Make it a tiny bit fancier ✨ */
background-image: linear-gradient(var(--c, currentColor), var(--c, currentColor));
background-repeat: repeat-x;
background-position: 0 100%;
background-size: 100% var(--bg-size);
box-shadow: 0 0 0 var(--shadow-size, 0) var(--c, currentColor); /* Used in the :active state */
box-decoration-break: clone; /* Ensure the styles repeat on links spanning multiple lines */
/* Transition declarations */
transition-property: color, background-size, box-shadow;
transition-duration: 150ms;
transition-timing-function: ease-in-out;
will-change: color, background-size, box-shadow;
}
/* Idle states */
a:link,
a:visited {
--link-color: var(--c, currentColor); /* Use --c, or fallback to currentColor */
}
/* Interacted-with states */
a:hover,
a:focus,
a:active {
--bg-size: 100%;
--link-color: var(--bg);
}
/* Active state */
a:active {
--shadow-size: var(--space); /* Define the box-shadow size */
}
}
Sure, it’s a bit more convoluted that just having an underline, but used hand-in-hand with utility classes that allow you to always access the text and background colors, it’s a quite nice progressive enhancement.
It’s up to you to enhance this using three variables for each color, either rgb or hsl format to adjust opacity and such. You can also add a text-shadow to simulate text-decoration-skip-ink!
Truth be told, there’s a lot of value that comes from doing design sprints. However, it’s not as simple as adopting Google Vision’s original system and instantly being able to create better digital products or getting greater consumer buy-in.
Let’s take a look at what design sprints are, why they can be valuable, but why you also might need to steer clear of them.
What Is a Design Sprint?
In basic terms, the design process looks like this:
A design sprint, looks like this instead:
Essentially, it removes the build and launch phases of the typical design workflow, so that design teams can get to a validated concept more quickly.
That said, the design sprint process is anything but quick and simple.
How Does a Design Sprint Actually Work?
It’s a heavily structured, multi-day process that enables design teams to:
Research the problem, opportunity, and/or market. (This depends on what you’re trying to build – e.g. website, app, new feature for an existing product, etc.);
Formulate a hypothesis;
Visualize the concept through storyboarding;
Prototype the solution;
Test it with real users.
Teams is the operative word here. A design sprint is a highly involved process that normally takes place over an entire week — and it’s the collaboration of each team member that allows the process to be successful in the end.
A design sprint team can include anywhere between four and eight people, though it’s suggested that the ideal team include the following:
Facilitator: the person who organizes and manages the sprint;
Decisionmaker: the CEO or other executive who makes the final call;
Designer: the person who builds the prototype and product;
Marketer: the marketing director or coordinator who’s in charge of selling the product or feature to the public;
Cost manager: the financial lead who keeps track of the budget and projections;
Customer service lead: the person who knows the target audience and their pains best.
At the end of the sprint, this team should come up with:
Answers to the core questions they started the process with;
A robust set of findings, including storyboards, user flows and journey maps, notes, etc;
A prototype;
A report that details findings from user testing;
Validation of the hypothesis and prototype;
A plan for implementation or a decision to return to the drawing board.
Because it’s such a strict system, there’s little leeway for flexibility here. But if followed to a T, sprints are expected to produce amazing results.
What Are the Benefits of Design Sprints?
Are you wondering what the big deal is? After all, you probably already have a web design workflow that works well and that clients have been pleased with the results of, right?
There are a number of reasons why design teams are willing to dedicate five days to a design sprint:
You save time and money since you test a solution with prototypes rather than create a full product or feature.
You reduce the chance of failure as you only pursue problems with viable solutions that are then validated by users.
It allows for greater innovation as you have a team of contributors working towards the same goal as opposed to working on their portions in isolation.
Real users get their hands on the prototype and can provide valuable data not just for this product, but for the brand as a whole as well as for future concepts.
Because the team is fully involved and accountable to the sprint, they feel more invested in the product and motivated to go above and beyond in developing the perfect solution.
It’s easier to get approval from decision-makers as they’re involved in the sprint.
All in all, a design sprint enables teams to more confidently build digital solutions that both clients and users are happy about in the end. That said, a design sprint isn’t a cure-all for web designers and agencies.
Why a Design Sprint Might Not Be a Good Idea
Okay, so you’ve seen all of the good that the structure and five-day commitment can do for you. But does that mean a design sprint is right for your next project?
Here are some things that might keep this seemingly flawless system from producing positive results:
1. You Have No Data To Start With
A design sprint cannot start on an assumption or a complete shot in the dark. It’s a huge commitment that you and your team are going to make, and it’s not one that you want to gamble with on a hunch.
2. You Already Know The Answer To The Problem
The whole point of a design sprint is to systematically define a problem, hypothesize a solution, and then test the validity of it. But if you already know the answer to the problem, there’s no reason to waste your time with this problem-solving process.
3. The Problem is Too Small/Big
In this case, size matters very much. Five days might seem like enough time to tackle any problem — especially if you’re not working on anything else that week — but it can lead to major waste or exceeded scope if you don’t plot the timeline accordingly.
4. You Don’t Have Enough Team Members
Since design sprints need to have between four and eight team members to work, it’s not feasible for solo freelance designers or small design teams to run design sprints. You’ll especially feel that pressure when it comes time to recruit test users and analyze the results.
5. It’s Costly
Unless you work for a bustling design agency that can afford to take that many people off of active projects for a week, the design sprint process will be too costly. You might be able to produce amazing results for that one click, but that’s an entire week without other paid work getting done.
6. It’s Too Difficult To Commit To
Let’s say you’re in a position to do design sprints. Is everyone on your team fully committed to the five-day process or is it going to be a struggle to get everyone in the same room and off of their mobile devices (which aren’t allowed)? This especially goes for the top-level executive who calls the final shot, but whose life is usually full of conflicting commitments and distractions.
7. There Are Too Many Decision-Makers
The problem with bringing together so many talented people from different areas of the company is the matter of hierarchy. If they’re used to being the decision-maker when it comes to things like marketing and finance, who’s to say they’re going to enter this new process and be okay relinquishing that role to the ultimate decision-maker? Unless you have a facilitator who’s confident enough to wrangle all the egos and keep order, this could be a big problem.
Wrap-Up
As a designer, you take a lot of pride in your work, which is why the idea of adopting a process that promises positive results is appealing.
The only thing is, design sprints weren’t really built for freelancers or small businesses. They were built for large agencies that have the time, money, and resources to commit to such a huge undertaking. That’s not to say you can’t adopt the best practices used within the process now or start working towards integrating design sprints into your business. But design sprints aren’t a magic bullet, and they don’t scale well.
Smashing TV has been working with our friends over at Mozilla to bring you content from their upcoming View Source conference in Amsterdam. We’re really excited about the event that they are putting together.
Here on Smashing Magazine, we often feature articles that explain a little bit about how web technologies are created. I’m a CSS Working Group member, and I enjoy sharing the things that we’ve been discussing in our meetings, such as my post on “Designing An Aspect Ratio Unit For CSS”. Earlier this year, we published an article by Amy Dickens, “Web Standards: The What, The Why, And The How” in which Amy explained what we mean by web standards and how standards groups work. We’ve also shared with you how browser vendors such as Mozilla are making web platform features easier for us to use in our work, such as this post by Chen Hui Jing, “Debugging CSS Grid Layouts With Firefox Grid Inspector”.
If you enjoy articles like these, then you will love View Source, and the chance to spend two days with people who are involved with specifying the web, and implementing it in our browsers. It’s a very special View Source because friends from Google, Microsoft, Samsung, and the W3C are joining Mozilla to bring the best of the web to developers and designers this year. I’ll be there too, wearing my CSS Working Group hat, as part of a discussion corner on how CSS gets into browsers.
Our own Vitaly Friedman has been interviewing some of the speakers from the upcoming event, and you can watch the first of those interviews now.
Enjoy this conversation with Kenji Baheux, a Product Manager at Google, working on Chrome/Web Platform, about the web in different parts of the world, differences between usage of the web, and what we need to be aware of when expanding to an unfamiliar market in India or Southeast Asia.
Mozilla’s View Source Amsterdam event is happening on Monday and Tuesday, Sept 30th and October 1st at Theater Amsterdam. Get your tickets here. You can save 25% with the code Smashing_VS, or use a direct link to check out. I look forward to meeting you there!
An Interview With Kenji Baheux
Vitaly: Hello and welcome to one of those interviews on view source speakers, live sessions with a few behind-the-scenes about the speakers and the sessions and the talks and the interesting topics. And I’m very happy and honored to have Kenji Baheux with us today, from Google, currently living in Tokyo, Japan. How’re you doing today, Kenji?
Kenji Baheux: I’m doing pretty good, thank you.
Vitaly: Fantastic. I have questions. You know, I always do, I have too many questions I believe, but I’m really curious because you know, I know that you’ve spent quite a bit of time and you know, the session you’re going to present today, you’re going to present that in view source which is all about multicultural web thing, right? It’s like the web beyond the scope of what we’re used to, and very often when we think about designing a building for the web, we’re thinking about designing and building for our web. You know, for wonderful screens and wonderful devices and wonderful connections and powerful devices, and all of that. But when we think about designing for Indonesia, when you think about designing for Southeast Asia or India or kind of all places where we’re are not familiar with, we have stereotypes, right? We tend to believe slow devices, unreliable connections, bad screens, you know, horrible, horrible conditions. Almost the opposite of what we’re used to, is it the true web outside of the comfortable bubble that we live in? Tell us.
Kenji Baheux: So, unfortunately, there is some truth to that, and the interesting thing is that the market in India and Indonesia they have like a common aspect, but there are differences — especially around connectivity, for instance. It used to be the case that connectivity in India was very expensive, and so people like wanted to save like data and so they, you know, they didn’t want to use the web too much. For instance, today, it has become a lot more affordable and so people are not concerned too much about data consumption. It is still true that maybe in the newer kind of like user segment, it might still be quite expensive, but it’s getting better quite fast. So I think like in term of like data usage, it’s not so much a concern anymore, but at the same time like 4G is available over there, but if you look at the speed and the like readability of the collection, it’s more kind of like a 3G connection than a 4G connection.
Kenji Baheux: And so you need to be careful about like your assumption about, “Oh, 4G is affordable and therefore the connectivity is going to be the same than what I experience in my own country.” Like there are some stats but like, for instance, I think India is actually at the bottom in terms of speed for 4G and it’s about a 10x slower than what it should be compared to like the top one, for instance. So there is some nuance there and also because there are a lot of users in India depending on the time of the day, the speed will like fluctuate and also sometimes like depending on the bandwidth the [inaudible] will keep up.
Kenji Baheux: And so you might lose connection. You might be on the go. There are a lot of dot points, like not enough antennas and things like that. So you need to be careful about speed and also like this idea that not always on connectivity is not always what user experience is over there. And if you contrast that with Indonesia, Indonesia is doing a bit better in terms of speed, like 4G over there is more kind of like 4G, and there are some reasons to that. The country is much smaller, urbanization is much higher, and so it does help, right? The user, they can reach out in Indonesia tend to have better infrastructure. So that’s one aspect. You mentioned also the devices, so on that, like it’s still very true that the devices tend to be on the lower end of the spectrum. And so like iPhone for instance, are a very tiny market share mostly because those devices are too expensive. And so most of the people can’t afford like high-premium devices.
Kenji Baheux: It used to be the case also that the memory that devices have was very low and this has become better, but it doesn’t mean that the device is cracked, right. I think the OEMs understood what the user cares about. Like does it have a great camera, does it have enough RAM, what about the storage? But then they want to keep the price low and so they are going to find ways to make the device cheap, right? And so it means like slow CPU, slow storage, and things like that. So you need to be careful about the connectivity, but also how much JavaScript you send because it’s going to make your page go slow, right?
Vitaly: It’s, you know, you spend quite a bit of time thinking about performance and also now because you’re working at the Chrome team and you kind of want to work on the instant loading team — if I’m correct, right? It means for me, personally, it means that you have very different challenges at times as well because probably now living in Japan or living in Indonesia kind of have to really look into the types of devices people are using, the habits that they have, the cultural ways of how the web is different. You know, if you look into Africa, for example, I’m sure as you probably know, of course, many people that Africa will be using kind of totally bypassing credit cards altogether, sending money by SMS and having a different kind of web applications, right? So that makes me think as well, when it comes to performance, obviously we want to make things fast and all that, would you say that progressive web apps as a model has become or is becoming more and more established just because it’s kind of an easier way in to get to better performance in India, in Southeast Asian, and so on?
Kenji Baheux: Yeah, we’ve seen a trend of success with PWA in those markets, for the reasons that I’ve outlined, right? If you build a PWA right, it’s going to minimize the amount of data that you fetch, right? You can use the storage and API to make sure that you don’t over-fetch. You can also deliver a very fast-like experience by showing at least a bit of like a piece of UX and then fetching the new content, right? You can minimize the amount of content you need to fetch in order to show the letters like data. So it’s, I think it’s a great fit. It does help a lot of like partners over there.
Vitaly: Many companies that they kind of work with and some of my colleagues are working with, they have a very difficult time moving kind of exploring new markets, moving their architecture, their application, the the way they built up their app or the website really on these markets kind of trying to gather that market share. And it’s very often not very clear why is that? Is it just because the architecture that we’re used to with this mountain of JavaScript that we are pushing with, you know, the Western World that say it’s just totally unacceptable for Southeast Asia? And again, I don’t know, China’s a difficult story anyway, and India. So in many ways, many of these companies see as one of the paths to get to those markets is just built something entirely different. So when you see, if you see, let’s say somebody who had maybe watching this session later trying to get through those markets, would you recommend to adapt the existing architecture, try to kind of make it work for those markets, or would you say it’s better to start from scratch and use something like an assistant ecosystem that’s already there?
Kenji Baheux: Yeah, I think it’s usually better to start from scratch because you might be tempted to try to keep around different features because maybe you’ve seen them doing well in your market and so you, you think those will be like super important to have. And so it’s going to be hard to make some trade off. And so it might be better to start from scratch and like really find, okay, what are the keys— what is the goal of this product? What are we trying to achieve? And keep it to the essential and start from there and see if you really like your product too, it’s bare minimum, like how fast can it float on the connectivity that you can find in markets like that? Like, try to get a low-end device, it’s not too hard to get something that could feel relevant for the market that you are trying to target and just play with it.
Kenji Baheux: I think trying to create a product on your desktop computer or even looking at it like on an iPhone or like a high-end Android device is not going to give you a good idea of like what your experience is going to be. And so you need to really like put yourself in the the shoes of your customers and really like confirm for yourself that what you have is going to work. So yeah, start from something very simple like the bare minimum that your product is about, and see how far you can take it from there.
Vitaly:It’s interesting to also be talking about people, but also… most of the time when we have these conversations about performance, we think about devices. You know, when you start thinking about internationalization and localization and all those things that are actually just going to those markets, I start wondering about the habits of people. Maybe they use the web very differently. So this is exactly what you’re saying, right? We need to do some research to understand how people are used to certain things. What would work? Maybe a feature you spent two years on here in Germany somewhere is just not going to work at all in India, right? So because, I mean, I just have to ask you because I’m so curious, it’s maybe not on the technical side, but I’m just curious. So if you compare the web, how people use the web, but say in the Western World, and again, let’s say in Japan where you spent the last 20 years, I believe, how is it different? I mean, I’m sure that there are certain things that are just, just totally confusing for somebody who experiences, let’s say, the way people are using the web in Japan coming from very different culture, did you have any kind of cultural shocks or anything of that kind or do you see things differently?
Kenji Baheux: That’s an interesting one. I think one of the most surprising thing for me when I arrived in Japan, like 20 years ago, was the fact that the website were like very visual, to the point of like being very noisy. Like from a European viewpoint, it’s kind of like, oh, this is way too much in your face. Like, there was so much going on on that page, how can you even understand how to use it? But actually this is what like most users are actually here, like when it comes to user experience, they want to know more upfront about the product, and so you end up with this like long page detailing all the things about why this project is like the most amazing thing in the world. And then at the bottom of it, there is like finally a way to purchase that product, so that’s one typical user experience that I’ve seen a couple of times already.
Kenji Baheux: So yeah, so that’s very visual: Trying to put as much information upfront about what the product is about. So that’s for Japan. And then for countries like Indonesia and India, especially in India, there are a lot of difficulties around language. As you probably know, India has a lot of official languages and so you really need to understand which users you are trying to reach. Because if you don’t have the content in their language, it’s going to be very hard for them to understand how to use the website, and so on. For most, it’s the first time that they are getting online and there are still a lot like new users getting online every day, and so they don’t have any like notion of like what a tab is like background tab, all of these things that we take for granted, like a lot of users actually that’s the first time that they are online, and so it’s very hard for them to just know about the things we take for granted. And so be very careful about making sure that your product is like self-explaining, and that there is nothing that people need to know in advance, for instance.
Vitaly: I’m also wondering, very often when we’re building products or when we’re designing products, we tend to think that we are building this technology that’s almost neutral, but in the end, whenever we’re building something, we always reflect our identity somehow in the little snippets of JavaScript and CSS we’re writing, and so I think that, in many ways, as designers and developers, we also have certain stereotypes when it comes to designing for those markets or kind of adapting for those markets. So what do you see, I mean, I mentioned one of them in the very beginning, like everything is slow, everything is horrible, totally unreliable and all of that — what do you see maybe as other common misconceptions or myths surrounding global web from people who are designing and building in a Western World Web?
Kenji Baheux: Yeah, that’s an interesting one. I think one particular aspect is the local players tend to be much more successful for various reasons, but one of them is that, especially in Indonesia, they know that the population is very young in general, and so they opt for a more casual tone which is something that I guess most websites in the US and EU don’t tend to do a lot. And so if you’re in e-commerce, you might be tempted to be very serious because you want to present yourself as the company that people can trust, but it might actually be the [inaudible] to your brand image if you go to a market like Indonesia where people want to have a more fun experience maybe.
Vitaly: Right, and also if you look forward into how things are evolving or how they’ve changed, I mean, you’ve seen tremendous change on the web over the last 20 years, I’m sure, but I’m wondering also when we look forward, let’s say five years from now, and look into connectivity, it seems like there is this gap that we used to have. It’s kind of bridging, we have pretty much stable connectivity that’s coming, at least worldwide, it’s still a long way to go, but it’s, you know, it’s coming. How do you see the web — the World Wide Web as we intended it to be from the very first place — evolving? Will we breach all these gaps between the Western world and non-Western world, at least in terms of the web? Or are there going to be significant cultural differences still?
Kenji Baheux: Obviously, eventually, things will get in a similar place in terms of conductivity and, like, maybe even like devices. But I think it’s going to take a while because as I said, there is still a lot of like new users getting online for the first time, and for them it’s like the price of data and devices are getting in the affordable realm, and you see, especially in markets like India for instance, there is still a lot of like feature phone and it’s not the like the old-side feature phone. It’s kind of like a more fully-fledged feature phone. I believe that KaiOS is getting a lot of attraction — people should be aware of that brand. Go check it online, google for KaiOS devices, and you will see that it’s actually bringing the modern web into a feature phone from factor.
Kenji Baheux: And so the idea is that the lowest end of the smartphone is still too expensive for a lot of users, and so by bringing something that people can use and get connected to on a feature phone from factor, like carriers can lower the price points where a lot more users can get online. So I think this is still going to be the case for a long time, and so having to be mindful about low-end devices and slow connectivity because as more people get online, the infrastructure should keep up but it’s going to be very hard. All of these programs are still going to be a thing for a long time, I think.
Vitaly: When I was in Indonesia, by the way, I was surprised about one thing because it’s the first time when I experienced it, and it was the fact that I would go online and we’d get a SIM card and then there would be a Facebook Internet and everything else. Essentially, whenever I go through the gates of Facebook and I try to, you know, going to click on the links and all that, it’s free. But then as long as I want to type in anything else in my URL bar, I have to pay. So this is where I actually got to be hit almost by the role that net neutrality has and how it’s actually not respected really in those countries where you have to pay more for access in certain parts of the web. In terms of net neutrality, how do you see things there? Because I’ve only been to Indonesia where it happened to me. Is that a common thing that we have a Facebook Internet in many places around the world?
Kenji Baheux: So I believe this is part of something that was called Facebook Basics. I don’t know if it’s still the same name, but I’ve seen different countries where you can get online for free but you only have access to a few websites. And I’m just guessing that it’s a deal between those websites and the carrier. The stats that we have indicate that it only gets, like, a lot of people would just move away from that very soon, like quickly because as they get to hear from their friends and family about all the different things that they are able to do, they quickly realize that what they have is like very limited. And so as the purchasing power like grows, they do like pay a few additional like quota, not maybe for the full month, and eventually at some point they will be able to do so, but there is an appetite for getting beyond this like few websites sites that are available for free.
Vitaly: Yeah. And then maybe the final one, Kenji, and I will let you go, and free… So, if you look forward, let’s say in a few years from now, and maybe if you look back into that interview when I asked that question, what would you like to see changed in the next two years? Is there anything on the web that you desperately want to fix or something that kind of bothers you for quite a bit of time where you are spending all your time and efforts and you know, you’re in the nighttime when you can’t sleep, and just to solve that thing… If you had to, if you could solve just one thing for good on the web, what would it be?
Kenji Baheux: That’s a tough one. I feel that the web in general is still, like, we say that web is like very low friction and it is in a sense because everything is just like one link away. And so, and also there’s like no new install phase, it’s very safe and secure, right? But at the same time, on mobile, a lot of time it’s very frustrating because you have to wait and the pages load very slowly, the UX is not always great… So I hope that the work we do will eventually get us in a place where the web feels like instant, seamless, and delightful. And I’m wondering if there is something that is missing, which is some of the, like the native apps are on, you know, like do provide a better user experience cause I feel they have the incentive to do so to like things like ratings and reviews, right? There is a way to know where you are falling off the path, like what is wrong about my app? How can I fix it? And also you have the incentive to do it because there is like rankings and people can see what other people think about your app, and so I’m wondering if there is something on the web that is missing there where we could get more signals from users and help the web get better based on that, and so I would like to, to get some feedback on that and what people think about this idea.
Vitaly: Oh, that sounds exciting. So I guess that maybe that’s something you’ll bring up in your session on October 1st at View Source in Amsterdam, and I can’t wait to hear more insights about the web in different parts of the world because the web is much bigger than just us sitting here in fancy offices in front of wonderful displays. Alright, Kenji, thank you so much for being with us today, and thanks to everyone for watching as well. I’m looking forward to the next one and I’m looking forward to seeing you in Amsterdam.
Some people outright hate the idea of CSS-in-JS. Just that name is offensive. Hard no. Styling doesn’t belong in CSS, it belongs in CSS, a thing that already exists and that browsers are optimized to use. Separation of concerns. Anything else is a laughable misstep, a sign of not learning from the mistakes of the past (like the tag and such.)
Some people outright love the idea of CSS-in-JS. The co-location of templates and functionality, à la most JavaScript frameworks, has proven successful to them, so wrapping in styles seems like a natural fit. Vue’s single file components are an archetype here.
(Here’s a video on CSS-in-JS I did with Dustin Schau if you need a primer.)
What does CSS-in-JS not rid you of needing to understand:
How styles are applied to the DOM
How inheritance works
How CSS properties work
How CSS layout works
CSS-in-JS doesn’t absolve you of learning CSS. Mostly, anyway.
I’ve heard lots of pushback on CSS-in-JS in the vein of “you people are reaching for CSS-in-JS because you don’t understand CSS” or “You’re doing this because you’re afraid of the cascade. I already know how to scope CSS.” I find that stuff to be more poking across the isles that isn’t particularly helpful.
Laura buns has a wonderfully two-sided article titled “The web without the web” part of which is about React and CSS-in-JS:
I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole.
You don’t need to use CSS-in-JS just because you use React, but it is popular, and that’s a very interesting and fair criticism. If you scope everything, aren’t you putting yourself at higher risk of inconsistency?
I’ve been, so far, a fan of CSS modules in that it’s about as light as you get when it comes to CSS-in-JS, only handling scoping and co-location and that’s about it. I use it with Sass so we have access to mixins and variables that help consistency, but I could see how it could allow a slide into dangerous too-many-one-offs territory.
And yet, they would be disposable one-offs. Code-splittable one-offs. Everything exists in balance.
Laura goes on to say she likes CSS-in-JS approaches for some of the power and flexibility it offers:
I like the way CSS-in-JS gives you enough abstraction to still use tricks like blind owl selectors while also giving you the full power of using JS to do stuff like container queries.
Martin Hofmann created a site comparing BEM vs. Emotion that looks at one little “alert” component. I like how it’s an emotionless (literally, not referencing the library) comparison that looks at syntax. BEM has some advantages, notably, requiring no tooling and is easily sharable to any web project. But the Emotion approach is cleaner in many ways and looks easier to handle.
I’d like to see more emotionless comparisons of the technologies. Choice A does these three things well but is painful here and here, while choice B does these other things well and solves a few other pain points.
We recentlylinked up Scott Jehl’s post that looks into loading CSS asynchronously. Scott’s opening line:
One of the most impactful things we can do to improve page performance and resilience is to load CSS in a way that does not delay page rendering.
It’s notable that an all-in CSS-in-JS approach gets this ability naturally, as styling is bundled into JavaScript. It’s bundled at a cost. A cost to performance. But we get some of that cost back if we’re eliminating other render-blocking things. That’s interesting stuff worthy of more data, at least.
I might get my butt kicked for this, but I’m a bit less interested in conversations that try to blame CSS-in-JS for raising the barrier to entry in the industry. That’s a massive thing to consider, but we aren’t talking about shutting down CSS here and forcing everyone to some other language. We’re talking about niche libraries for certain types of projects at certain scales.
I think it’s worth taking a look at CSS-in-JS ideas if…
You’re working on a component-heavy JavaScript project anyway.
You’re already co-locating templates, functionality, and data queries.
You think you can leverage it without harming user experience, like gaining speed back elsewhere.
Your team is comfortable with the required tech, as in, you aren’t pushing away talent.
Max Stoiber is an unabashed fan, but his post on the topic talks about the confidence this style brings him and the time he saves in finding what he needs, both things I’ve found to be true. But he also thinks the approach is specifically for JavaScript framework apps.
If you are using a JavaScript framework to build a web app with components, CSS-in-JS is probably a good fit. Especially if you are part of a team where everybody understands basic JavaScript.
I’d love to hear y’all thoughts on this in the comments. Have you worked out your feelings on all this? Madly in love? Seething with dislike? I’d be most interested in hearing success stories or failure stories on real projects.
Looking to change your software development practices for the better? You already have the know-how and experience, and you always strive to improve your skills? But, if you feel you’ve hit a plateau, the tools you’re using could easily be the source of the problem.
Choosing the right tools and services is always a challenge, especially when more and more come on the market every year. Bridging the gap between development and operations has always been a challenge. That is one place where having the right tools can make your efforts much easier.
There are certain factors you need to consider when looking for a certain development tool. They are based on the type of the project involved. The products and services recommended in this article consider these factors.
Elementor has proven to be an extremely popular web design tool. So popular in fact that some of its users might not be aware that it this open source project was created with developers in mind. While it’s has most features designers love, it’s literally packed with features you’ll love if you’re a developer.
As is the case with many open-source solutions, great ideas come from a range of contributors that, along with the Elementor team, work tirelessly to build on its already full stack of solutions you can use to address your own problems and create your own solutions.
Elementor’s development solutions include CLI Integration, Custom CSS, CSS Optimization, Version Rollback Capabilities, and Request Parameters for data tracking across multiple pages. Elementor is also RTL ready.
The developer’s documents offer a great place to learn how to extend this extremely extensible development tool and get the most from its editor, live preview, its frontend features, and the extensive library of useful widgets.
If you’re spending lots of time invoicing it’s probably because your business is doing well, but it stops being good news when it takes too much time away from your core development work. AND.CO is a smart development app that tracks time, creates your invoices for you, and alerts you when they’ve been viewed or paid.
This nifty invoicing app syncs across all your devices, so you can stay on top of your cash flow and billings and even manage your invoicing while on the go. There’s no need to spend time manually inputting billable hours either, AND.CO does it for you. You can even use AND.CO to create proposals and use the information contained in them as the basis for invoicing.
One more thing: when you receive a payment, AND.CO automatically deposits it in your bank account.
As a developer, you naturally lean toward or rely entirely on flexible and extensible open source tools to get your work done. Atom is precisely such a tool. This open source desktop application runs on Electron, which enables it to help you build cross platform apps and use it on Windows, OS X, and Linux.
Atom also works with JavaScript, CSS, HTML, and Node.js integration, and the ability to choose among thousands of open source packages to work with makes it a super-extensible application. If you choose, you can build your own package from scratch, publish it, and share it with others.
Atom also promotes collaboration among developers. When developers work together and share knowledge as they do so, great things can happen. Collaborating with others on coding becomes no more difficult than coding on your own since Atom allows you to compare and edit code across files and view an entire project or multiple projects in a single window.
Is having to perform multiple tests on multiple applications starting to drag you down? Testim was developed to enable Agile teams author more tests while spending less time managing and maintaining them. This development tool allows you to run multiple tests on multiple browsers and receive the results in a matter of minutes.
With Testim, you can conduct testing in their cloud or your private cloud. Testim is a straightforward solution to the problem of being swamped by large-scale testing.
Whether outsourcing web development is an option or a necessity, doing so has many advantages. Outsourcing can save money, teams like TMS Outsource are experts at what they do, you can rely on on-time delivery, and you can focus on your core business activities.
TMS Outsource also relieves you of the challenge of having to search for a development team you can rely on; a team that adheres to SCRUM development methodologies in their work.
Sending out invoices with InvoiceBerry is as easy as it gets. Select a professionally designed Microsoft Word, Microsoft Excel, or Open Source template, add your logo, content, and the customer’s email address, and InvoiceBerry will do the rest.
Customers can pay via Stripe, PayPal, or WePay. Since unpaid invoices appear on your dashboard, you’ll always know who’s paid and who hasn’t. Try InvoiceBerry for free for 30 days.
What makes a good developer tool?
Problem talented, hard-working developers often face to determine which of the many tools on the market would make good choices.
The tools come in many shapes and flavors. Making the right choices often depends on the nature of the project being worked on.
There are tools for:
Skill Development and Data Science
Project Management and Issue Tracking
Frameworks and Cloud Management and Storage
An Integrated Development Environment
DevOps, Prototyping, and Notifications and
Unified Modeling Language
These tools should be useful, integrable, and appropriate to the project environment and have a reasonable learning curve.
To choose a “best” tool it’s important to look for one that’s extensible, has a large user base, and is easy to use. A good choice can contribute to improved workflows and more productive project outcomes.
Conclusion
5 development tools and services might not seem like a lot to choose from. But if you look carefully there are probably one or two that could significantly improve your project workflows as well as the end results.
Each of these tools and services is designed to make you more productive, add to your skillset, remove a burden from your shoulders, or all the above.
