Tag: from

Three Predictions From the State of CSS 2019 Survey

Running a developer survey like the State of CSS is a multi-stage process. First, you need to collect the data. Then, you process it into a usable shape. Finally, you come up with nifty ways to visualize it and release it to the world.

But then, once the dust settles and the traffic dies down comes my favorite part: actually thinking about the data. By taking a deeper look at our data, as well as observing how the community discussed our findings, three unexpected trends ended up coming into focus.

But first, some background for those not already familiar with the project.

I first started the State of JavaScript survey three years ago in 2016 as a way to answer my own uncertainties about the future of web development. At the time, JavaScript fatigue was running wild and I thought a comprehensive developer survey could prove itself the antidote.

The original State of JavaScript 2016 edition

Turns out I hit a nerve: that first survey turned out to be very popular, and our audience has grown each year since, along with the scope of the survey. (I was also joined by Raphael Benitte, creator of the Nivo.js dataviz library, to help me with data processing and visualization.) This year marks the first time we’re pivoting out into a new dimension, namely the not-so-simple world of CSS.

Taking on CSS

Prediction 1: CSS still has a lot of unexplored territory

One of the things we wanted to quantify with the survey was how much of CSS was still left “unexplored.” In other words, what CSS features are developers either unfamiliar with, or else hadn’t yet used. For that reason we decided early-on to focus our Features section on new CSS properties, like shapes, masking, or scroll-snap rather than “boring” floats or tables.

The resulting data paints an interesting picture: it turns out that when you look at it this way, CSS morphs from a familiar landscape to a wild, unexplored jungle.

A look at comparing Flexbox vs. CSS Grid provides a good illustration of this trend. While nearly everybody who’s heard of Flexbox has also used it, only 55% of developers who are aware of CSS Grid have actually tried it. That’s a big gap, especially for a technology as important as CSS Grid!

Layout Features

Or take CSS Shapes: 68% of developers are aware of them, only 31% of that group has actually used the feature.

CSS Shapes

This all points at a big gap between what we collectively want to learn and what we actually know. It’s that potential for growth that is exactly what makes CSS so exciting in 2019.

Prediction 2: Functional CSS will keep rising

If you’re old enough to remember the CSS Zen Garden — or to have actually learned CSS through it (in which case I know how you feel, my back hurts when I get up in the morning as well) — then this next trend might seem weird, or even downright wrong.

CSS Zen Garden: one page, many themes.

Functional CSS rejects the platonic ideal of pure, untainted markup free from any styling concerns and embraces “functional” (aka “atomic” or “utility”) classes. Think <div class="text-red text-medium border-1">...</div>.

Adopting this approach means you can’t magically update your stylesheet and change your entire design without modifying a single line of markup. But be honest, how often does this happen anyway? Compared to the often theoretical elegance of the Zen Garden philosophy, libraries like Tailwind and Tachyons provide tangible, real-world benefits, which explains why they’re so highly regarded. In fact, those take the #1 and #4 spots, respectively, in terms of satisfaction ratio in the CSS Framework category.

Awareness, interest, and satisfaction ratio rankings for CSS frameworks.

Tailwind especially seems to be picking up speed, at least judging by the Twitter engagement from its community in response to the survey results. Having just hit version 1.0, it’s definitely a project to keep an eye on!

Prediction 3: The battle for CSS has just begun

Looking at our data, I can’t help but wonder if “JavaScript fatigue” will soon be replaced by “CSS fatigue.”

When evaluating technologies, it’s important to look not just at raw usage numbers, but also at user satisfaction. After all, you don’t want to jump on the latest bandwagon just to find out its current occupants can’t wait to hop off it.

This scatterplot chart that’s divided into quadrants is perfect for this. It plots usage against satisfaction, making it easy to isolate popular, high-satisfaction tools into their own quadrant.

Usage vs. Satisfaction

What’s apparent in this chart is that the most densely populated area is the “Assess” quadrant. In other words, the low-usage, high-satisfaction technologies that are still battling it out for supremacy. This is exactly the state that the JavaScript ecosystem finds itself in as well. Many contenders, but few decisive winners as of today.

This is not necessarily a bad thing: yes, it does make the average developer’s life harder when it comes to picking the right tool, but hey, this is why we do what we do! Additionally, competition can only be good for the ecosystem as a whole. Once the dust settles, we’ll hopefully end up with the best possible options having survived!

CSS in 2019

Overall, the State of CSS survey shows that this is not your grandpa’s CSS anymore. For years, we developers have loved to complain about the inadequacies of CSS and its lack of powerful features. But in 2019, CSS is challenging us to put our money where our mouthes are: here’s all the features you’ve always wanted. Now what are you going to do about it?

I, for one, am very excited to dive even deeper into this new world of styling. And, of course, to tune back in 2020 to see what new trends we find then!

The post Three Predictions From the State of CSS 2019 Survey appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,

Snag Resources from An Event Apart Boston 2019 and Save on Washington D.C. Registration

(This is a sponsored post.)

Hey, so we talked a little bit about An Event Apart Boston 2019 leading up to the event and now there are a ton of resources available from it. I stopped counting the number of links after 50 because there’s way more than that. Seriously, there’s stuff in there on subgrid, working with CSS Regions, design systems, using prefers-reduced-motion… and much, much more, so check it out.

And, while you’re at it, you should consider attending the next installment of An Event Apart. It takes place in Washington D.C. and seating — as you might expect — is limited. Like Boston, you can expect to get a treasure trove of useful information, educational content, and valuable training on topics that will help you sharpen your front-end chops and grow your career. Plus, the best part is getting to meet the rest of the great folks at the event — that’s where your network grows and real conversations take place.

Register Today

Can’t make it to Washington D.C.? No worries, because An Event Apart is also slated to take place in Chicago (), Denver () and San Francisco (). Now’s the time to start planning your trip and begging your boss for a well-deserved self-investment in leveling up.

And if you’re wondering whether we have a discount code for you… of course we do! Enter the AEACP at checkout to knock $ 100 off the price. 🤑

Direct Link to ArticlePermalink

The post Snag Resources from An Event Apart Boston 2019 and Save on Washington D.C. Registration appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , , , , ,
[Top]

Making the Move from jQuery to Vue

As someone who has used jQuery for many. years and has recently become a Vue convert, I thought it would be an interesting topic to discuss the migration process of working with one to the other.

Before I begin though, I want to ensure one thing is crystal clear. I am not, in any way whatsoever, telling anyone to stop using jQuery. That’s been pretty fashionable lately, and heck, I wrote up something similar myself a few year ago (“How I’m (Not) Using jQuery”). If you get things done with jQuery and your end users are successfully using your site, then more power to you. Keep using what works for you.

This guide is more for people who may be coming from years of jQuery experience and want to see how things can be done with Vue. With that in mind, I’m going to focus on what I consider “core” jQuery use cases. I won’t cover every single possible feature but instead take a “I often did [X] with jQuery” approach that may be more relatable to people considering learning Vue. (As an aside, also note that how I write my examples are simply one way of performing a task. Both jQuery and Vue give provide multiple ways to accomplish the same goal and that’s a great thing!)

With that in mind, let’s consider some high level things we might turn to jQuery for:

  • Finding something in the DOM (with the idea of doing something with it later)
  • Changing something in the DOM (e.g. the text of a paragraph or the class of a button)
  • Reading and setting form values
  • Form validation (which is really just a combination of the items above)
  • Ajax calls and handling the results
  • Event handling (e.g. on button click, do something)
  • Measuring or changing the styles of an element

There’s more to jQuery, of course, but these uses (at least in my opinion), cover the most common use cases. Also note there’s a lot of cross pollination in the list above. So, should we start with a simple one-to-one comparison of each? Nope, not so fast. Let’s begin by covering the major difference in Vue applications.

Defining where Vue “works”

When we drop jQuery onto a page, we are basically adding a Swiss Army knife to JavaScript code to handle common web development tasks. We can do any of the uses case we’re going to cover in whatever order we see fit. For example, a client may ask for form validation today, then in a month or so, ask to do an Ajax-based search form in the header of the site.

Vue has one significant difference in that respect. When starting a with Vue project, we start by defining an “area” in the DOM we want it to focus on. So, let’s consider a simple prototype web page:

<body>    <header>     Fancy header stuff here   </header>    <div id="sidebar">     Some sidebar doohicky here   </div>    <main>     <p>       Main site content here, super important stuff...     </p>     <div id="loginForm">       A login form of course     </div>   </main>  </body>

In a typical jQuery application, we may write code to work with the header, sidebar, and login form or something. No big whoop:

$  (document).ready(function() {    $  ('header') // something...    $  ('#sidebar') // something...    $  ('#loginForm') // something...   });

In a Vue application, we first specify what are we’re working with. Imagine our client first asked to add validation to the loginForm element. Our Vue code would specify that:

new Vue({   el: '#loginForm',   // Code here... });

This means that we’d typically end up adding a second Vue application if the client later decides to have us add something to the sidebar:

new Vue({   el:'#loginForm',   // Code here... });  new Vue({   el:'#sideBar',   // Code here... });

Is that a bad thing? Absolutely not. Right away, we get the benefit of encapsulation. If we accidentally use a variable with a generic name (we’ve all done that), we don’t have to worry about conflicts with other parts of your code. Later on when the client adds yet another request, having our unique, logical sets of Vue code separated out like this gives us some great peace of mind that things won’t step on each other.

So, yes, a good thing. But it absolutely caused me to stop a bit when I first began using Vue. Now, onto our use cases.

Finding Stuff in the DOM

Another aspect you’ll find interesting, or scary, is how to “find stuff in the DOM.” That’s a bit vague, but let’s consider a firm example. We have a button, and when it’s clicked, we something to happen. Here’s an abbreviated example of how this could look:

<button id="myButton">Click Me!</button> <!-- More stuff... --> <script> $  (document).ready(function() {    $  ('#myButton').click(function() {     alert(1);   });  }); </script>

Now let’s compare that to how it can be done with Vue:

<div id="app">   <button v-on:click="doSomething">Click Me!</button> </div>  <script> const app = new Vue({   el:'#app',   methods: {     doSomething: function() {       alert(1);     }   } }); </script>

The Vue application is a bit more verbose, but note how the markup has a direct connection between the action (“click”) and the function that will be called. Vue’s code doesn’t have a tie back to the DOM (outside of the el portion where we define where it needs to work). This was easily one of the things that sold me on Vue the most — it feels easier to tell what is going on. Also, I didn’t need to worry so much about the ID value and selectors. If I change the class or ID of the button, I don’t need to go back into my code and worry about updating selectors.

Let’s consider another example: finding and changing text in the DOM. Imagine that button, on click, now changes the text of another part of the DOM.

<button id="myButton">Click Me!</button> <span id="result"></span>  <!-- More stuff... -->  <script> $  (document).ready(function() {    $  ('#myButton').click(function() {     $  ('#result').text('You clicked me, thanks!');   });  }); </script>

I’ve added a new span and now, when the button is clicked, we use another selector to find it and use a jQuery utility method to change the text inside it. Now consider the Vue version:

<div id="app">   <button v-on:click="doSomething">Click Me!</button>   <!-- On click, change text in this span -->   <span>{{resultText}}</span> </div>  <script> const app = new Vue({   el: '#app',   data: {     resultText: ''   },   methods: {     doSomething: function() {       this.resultText = 'You clicked me, thanks!';     }   } }); </script>

In this example, we’re using Vue’s template language (the highlighted line) to specify that we want to render a variable inside the span, which is resultText in this case. Now, when the button is clicked, we change that value and the span’s inner text will change automatically.

As an aside, Vue supports a shorthand for the v-on attribute, so the button in the example could have been written with @click="doSomething" instead.

Reading and writing form variables

Working with forms is probably one of the most common — and useful — things that we can do with JavaScript. Even before JavaScript, most of my early “web development” was writing Perl script to handle form submissions. As the primary way of accepting user input, forms have always been critical to the web and that’s probably going to stay the same for quite some time. Let’s consider a simple jQuery example of reading a few form fields and setting another:

<form>   <input type="number" id="first"> +    <input type="number" id="second"> =   <input type="number" id="sum">    <button id="sumButton">Sum</button> </form>  <script> $  (document).ready(function() {   let $  first = $  ('#first');   let $  second = $  ('#second');   let $  sum = $  ('#sum');   let $  button = $  ('#sumButton');      $  button.on('click', function(e) {     e.preventDefault();     let total = parseInt($  first.val(),10) + parseInt($  second.val(),10);     $  sum.val(total);   }); }); </script>

This code demonstrates how jQuery can both read and write via the val() method. We end up getting four items from the DOM (all three form fields and the button) and use simple math to generate a result. Now consider the Vue version:

<form id="myForm">   <input type="number" v-model.number="first"> +    <input type="number" v-model.number="second"> =   <input type="number" v-model="sum">    <button @click.prevent="doSum">Sum</button> </form>  <script> new Vue({   el: '#myForm',   data: {     first: 0,     second: 0,     sum: 0   },   methods: {     doSum: function() {       this.sum = this.first + this.second;     }   } }) </script>

This introduces some interesting Vue shortcuts. First, v-model is how Vue creates two way data binding between values in the DOM and in JavaScript. The data block variables will automatically sync up with the form fields. Change the data, and the form updates. Change the form, and the data updates. The .number is a flag to Vue to treat the inherit string values of form fields as numbers. If we leave this off and do addition as we are, we’ll see string additions and not arithmetic. I’ve been working with JavaScript for nearly a century and still screw this up.

Another neat “trick” is @click.prevent. First, @click defines a click handler for the button, then the .prevent portion blocks the browser’s default behavior of submitting the form (the equivalent of event.preventDefault()).

The final bit is the addition of the doSum method that’s bound to that button. Note that it simply works with the data variables (which Vue makes available in the this scope).

While this is mostly my personal feeling here, I really love the lack of query selectors in the script when writing in Vue and how the HTML is much more clear about what it’s doing.

Finally, we could even get rid of the button completely:

<form id="myForm">   <input type="number" v-model.number="first"> +    <input type="number" v-model.number="second"> =   <input type="number" v-model="sum">  </form>  <script> new Vue({   el: '#myForm',   data: {     first: 0,     second: 0   },   computed: {     sum: function() {       return this.first + this.second;     }   } }) </script>

One of the cooler features of Vue is computed properties. They are virtual values that recognize when their derived values are updated. In the code above, as soon as any of the two form fields change, the sum will update. This works outside of form fields too. We could render the sum like so:

The total is {{sum}}.

Working with Ajax

It’s commendable how easy jQuery has made it to use Ajax. In fact, I can say I’ve done Ajax “the vanilla” way probably a grand total of one time. (If you’re curious, you can take a look at the spec for XMLHttpRequest and probably be happy you avoided it yourself.) jQuery’s simple $ .get(...) method worked in a large number of cases and when it’s needed for something more complex, $ .ajax() made it easy as well. Another thing jQuery did well is the way it handles JSONP requests. While mostly unnecessary now with CORS, JSONP was a way to handle making requests to APIs on different domains.

So, what does Vue do for you to make Ajax easier? Nothing!

OK, that sounds scary but it really isn’t. There are many options out there for working with HTTP requests, and Vue.js took a more agnostic route of letting us, the developers, decide how we want to handle it. So yes, that does mean a bit more work, but we’ve got some great options.

The first one to consider is Axios, this is a Promise-based library that is very popular among the Vue community. Here’s a simple example of it in action (taken from their README file):

axios.get('/user?ID=12345')   .then(function (response) {     // handle success     console.log(response);   })   .catch(function (error) {     // handle error     console.log(error);   })   .then(function () {     // always executed   });

Axios supports POST requests, of course, and lets us specify headers among many other options.

While Axios is very popular among Vue developers, it isn’t something that really clicked with me. (At least not yet.) Instead, I’ve been much more a fan of Fetch. Fetch is not an external library but is a web standard way of performing HTTP requests. Fetch has very good support at roughly 90% of browsers, though that means it isn’t completely safe to use, but we can always use a polyfill we need to.

While it’s totally out of the scope of what we’re discussing here, Kingsley Silas has written an excellent guide on using both Axios and Fetch with React.

Like Axios, Fetch is Promise-based and has a friendly API:

fetch('http://example.com/movies.json')   .then(function(response) {     return response.json();   })   .then(function(myJson) {     console.log(JSON.stringify(myJson));   });

Both Axios and Fetch cover all types of HTTP requests, so either will fit an any number of needs. Let’s look at a simple comparison. Here’s a simple jQuery demo that makes use of the Star Wars API.

<h1>Star Wars Films</h1> <ul id="films"> </ul>  <script> $  (document).ready(function() {   $  .get('https://swapi.co/api/films', function(res) {     let list = '';     res.results.forEach(function(r) {       list += `<li>$  {r.title}</li>`;     });     $  ('#films').html(list);   }); }); </script>

In the sample above, I use $ .get to hit the API and return a list of films. Then I generate a list of titles as li tag elements with that data and insert it all into a ul block.

Now, let’s consider an example of this using Vue:

<div id="app">   <h1>Star Wars Films</h1>   <ul>     <li v-for="film in films">{{film.title}}</li>   </ul>   </div>  <script> const app = new Vue({   el: '#app',   data: {     films: []   },    created() {      fetch('https://swapi.co/api/films')     .then(res => res.json())     .then(res => {       this.films = res.results;       });   } }) </script>

Probably the best part of this is the use of the v-for template. Notice how Vue isn’t concerned with the layout (well, at least the JavaScript). The data is fetched from the API. It’s assigned a variable. The layout handles displaying it. I’ve always hated having HTML in my JavaScript and, while solutions exist for that with jQuery, having it baked into Vue makes it a natural fit.

A full (if somewhat trivial) example

To bring it home a bit, let’s consider a more real world example. Our client has asked us to build a fancy Ajax-enabled front-end search interface to a product API. The feature list includes:

  • Support filtering by name and product category
  • Form validation such that we must supply a search term or a category
  • While the API is being hit, show a message to the user and disable the submit button
  • When done, handle reporting that no products were shown or list the matches

Let’s begin with the jQuery version. First, the HTML:

<form>   <p>     <label for="search">Search</label>     <input type="search" id="search">   </p>   <p>     <label for="category">Category</label>     <select id="category">       <option></option>       <option>Food</option>       <option>Games</option>     </select>   </p>    <button id="searchBtn">Search</button> </form>  <div id="status"></div> <div id="results"></div>

There’s a form with our two filters and two divs. One’s used as a temporary status when searching or reporting errors and one is used to render results. Now, check out the code.

const productAPI = 'https://wt-c2bde7d7dfc8623f121b0eb5a7102930-0.sandbox.auth0-extend.com/productSearch';  $  (document).ready(() => {   let $  search = $  ('#search');   let $  category = $  ('#category');   let $  searchBtn = $  ('#searchBtn');   let $  status = $  ('#status');   let $  results = $  ('#results');      $  searchBtn.on('click', e => {     e.preventDefault();          // First clear previous stuff     $  status.html('');     $  results.html('');      // OK, now validate form     let term = $  search.val();     let category = $  category.val();     if(term === '' && category === '') {       $  status.html('You must enter a term or select a category.');       return false;     }      $  searchBtn.attr('disabled','disabled');     $  status.html('Searching - please stand by...');          $  .post(productAPI, { name:term, category:category }, body => {       $  searchBtn.removeAttr('disabled');       $  status.html('');        if(body.results.length === 0) {         $  results.html('<p>Sorry, no results!</p>');         return;       }              let result = '<ul>';       body.results.forEach(r => {         result += `<li>$  {r.name}</li>`       });       result += '</ul>';       $  results.html(result);     });        }); });

The code begins by creating a set of variables for each of the DOM items we want to work with — the form fields, button, and divs. The core of the logic is within the click handler for the button. We do validation, and if everything is OK, do a POST request against the API. When it returns, we either render the results or show a message if nothing was matched.

You can work with a complete version of this demo using the CodePen below.

See the Pen
jQuery Full
by Raymond Camden (@cfjedimaster)
on CodePen.

Now let’s consider the Vue version. Again, let’s start with the layout:

<div id="app">   <form>     <p>       <label for="search">Search</label>       <input type="search" v-model="search">     </p>     <p>       <label for="category">Category</label>       <select v-model="category">         <option></option>         <option>Food</option>         <option>Games</option>       </select>     </p>     <button @click.prevent="searchProducts" :disabled="searchBtnDisabled">Search</button>   </form>      <div v-html="status"></div>     <ul v-if="results">       <li v-for="result in results">{{result.name}}</li>     </ul> </div>

From the top, the changes include:

  • Wrapping the layout in a div that can be used to let Vue know where to work.
  • Using v-model for the form fields to make it easy to work with the data.
  • Using @click.prevent to handle doing the main search operation.
  • Using :disabled to bind whether or not the button is disabled to a value in the Vue application (we’ll see that in action in a moment).
  • The status value is a bit different than earlier examples. While jQuery has a specific method to set text in a DOM item and another for HTML, Vue requires using v-html when assigning HTML to a value that’s going to be rendered. If we tried to do {{status}} with HTML, the tags would be escaped.
  • Finally, using v-if to conditionally render a list of results along with v-for to handle the iteration.

Now let’s look at the code.

const productAPI = 'https://wt-c2bde7d7dfc8623f121b0eb5a7102930-0.sandbox.auth0-extend.com/productSearch';  const app = new Vue({   el: '#app',   data: {     search: '',     category: '',     status: '',     results: null,     searchBtnDisabled: false   },   methods: {     searchProducts:function() {       this.results = null;       this.status = '';              if(this.search === '' && this.category === '') {         this.status = 'You must enter a term or select a category.';         return;       }        this.searchBtnDisabled = true;       this.status = 'Searching - please stand by...';              fetch(productAPI, {         method: 'POST',         headers: {           'Content-Type':'application/json'         },         body: JSON.stringify({name:this.search,category:this.category})       }).then(res => res.json())       .then(res => {         this.status = '';         this.searchBtnDisabled = false;         this.results = res.results;         if(this.results.length === 0) this.status = '<p>Sorry, no results!</p>';       });            }   } });

The first block worth calling out is the set of data fields. Some map to form fields and others to results, status messages, and the like. The searchProducts method handles much of the same stuff as the jQuery version but, in general, there’s much less code directly tied to the DOM. For example, even though we know the results are listed in an unordered list, the code itself doesn’t worry about that. It simply assigns the value and the markup handles rendering it. Overall, the JavaScript code is much more concerned about logic in comparison to the jQuery code which “feels” like a much nicer separation of concerns.

As before, I’ve got a CodePen for you to try this out yourself:

See the Pen
Vue Full
by Raymond Camden (@cfjedimaster)
on CodePen.

Death to jQuery! Long Live Vue!

OK, that’s a bit over the top. As I said in the beginning, I absolutely think that you shouldn’t change a thing if like working with jQuery and it’s working for you.

I can say, however, that Vue feels like a great “next step” for people who are used to working with jQuery. Vue supports complex applications and has a great command line tool for scaffolding and building projects. But for simpler tasks, Vue works as a great “modern jQuery” replacement that has become my tool of choice for development!

For another perspective on using Vue in place of jQuery, check out Sarah Drasner’s “Replacing jQuery With Vue.js: No Build Step Necessary” because it includes a handful of other super helpful examples.

The post Making the Move from jQuery to Vue appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Moving from Gulp to Parcel

Ben Frain just made some notes about the switch from Gulp to Parcel, a relatively new “web application bundler” which, from a quick look at things, is similar to webpack but without all the hassle of setting things up. One of the things I’ve always disliked about webpack is that you kinda have to teach it what CSS, HTML and JS are before making whatever modifications you want to those files. However, Parcel does a lot of the asset management and configuration stuff for us which is super neat — hence, Parcel claim that it requires “zero configuration.”

If you’d like to learn more about Parcel then there’s a great post by Indrek Lasn that details how to get started and even shows off a little bit about how Parcel is often faster than alternatives like webpack. We also just published a post by Kingsley Silas that explains how to use Parcel with React.

Direct Link to ArticlePermalink

The post Moving from Gulp to Parcel appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]

Creating a Custom Element from Scratch

In the last article, we got our hands dirty with Web Components by creating an HTML template that is in the document but not rendered until we need it.

Next up, we’re going to continue our quest to create a custom element version of the dialog component below which currently only uses HTMLTemplateElement:

See the Pen
Dialog with template with script
by Caleb Williams (@calebdwilliams)
on CodePen.

So let’s push ahead by creating a custom element that consumes our template#dialog-template element in real-time.

Article Series:

  1. An Introduction to Web Components
  2. Crafting Reusable HTML Templates
  3. Creating a Custom Element from Scratch (This post)
  4. Encapsulating Style and Structure with Shadow DOM (Coming soon!)
  5. Advanced Tooling for Web Components (Coming soon!)

Creating a custom element

The bread and butter of Web Components are custom elements. The customElements API gives us a path to define custom HTML tags that can be used in any document that contains the defining class.

Think of it like a React or Angular component (e.g. <MyCard />), but without the React or Angular dependency. Native custom elements look like this: <my-card></my-card>. More importantly, think of it as a standard element that can be used in your React, Angular, Vue, [insert-framework-you’re-interested-in-this-week] applications without much fuss.

Essentially, a custom element consists of two pieces: a tag name and a class that extends the built-in HTMLElement class. The most basic version of our custom element would look like this:

class OneDialog extends HTMLElement {   connectedCallback() {     this.innerHTML = `<h1>Hello, World!</h1>`;   } }  customElements.define('one-dialog', OneDialog);

Note: throughout a custom element, the this value is a reference to the custom element instance.

In the example above, we defined a new standards-compliant HTML element, <one-dialog></one-dialog>. It doesn’t do much… yet. For now, using the <one-dialog> tag in any HTML document will create a new element with an <h1> tag reading “Hello, World!”

We are definitely going to want something more robust, and we’re in luck. In the last article, we looked at creating a template for our dialog and, since we will have access to that template, let’s utilize it in our custom element. We added a script tag in that example to do some dialog magic. let’s remove that for now since we’ll be moving our logic from the HTML template to inside the custom element class.

class OneDialog extends HTMLElement {   connectedCallback() {     const template = document.getElementById('one-dialog');     const node = document.importNode(template.content, true);     this.appendChild(node);   } }

Now, our custom element (<one-dialog>) is defined and the browser is instructed to render the content contained in the HTML template where the custom element is called.

Our next step is to move our logic into our component class.

Custom element lifecycle methods

Like React or Angular, custom elements have lifecycle methods. You’ve already been passively introduced to connectedCallback, which is called when our element gets added to the DOM.

The connectedCallback is separate from the element’s constructor. Whereas the constructor is used to set up the bare bones of the element, the connectedCallback is typically used for adding content to the element, setting up event listeners or otherwise initializing the component.

In fact, the constructor can’t be used to modify or manipulate the element’s attributes by design. If we were to create a new instance of our dialog using document.createElement, the constructor would be called. A consumer of the element would expect a simple node with no attributes or content inserted.

The createElement function has no options for configuring the element that will be returned. It stands to reason, then, that the constructor shouldn’t have the ability to modify the element that it creates. That leaves us with the connectedCallback as the place to modify our element.

With standard built-in elements, the element’s state is typically reflected by what attributes are present on the element and the values of those attributes. For our example, we’re going to look at exactly one attribute: [open]. In order to do this, we’ll need to watch for changes to that attribute and we’ll need attributeChangedCallback to do that. This second lifecycle method is called whenever one of the element constructor’s observedAttributes are updated.

That might sound intimidating, but the syntax is pretty simple:

class OneDialog extends HTMLElement {   static get observedAttributes() {     return ['open'];   }      attributeChangedCallback(attrName, oldValue, newValue) {     if (newValue !== oldValue) {       this[attrName] = this.hasAttribute(attrName);     }   }      connectedCallback() {     const template = document.getElementById('one-dialog');     const node = document.importNode(template.content, true);     this.appendChild(node);   } }

In our case above, we only care if the attribute is set or not, we don’t care about a value (this is similar to the HTML5 required attribute on inputs). When this attribute is updated, we update the element’s open property. A property exists on a JavaScript object whereas an attribute exists on an HTMLElement, this lifecycle method helps us keep the two in sync.

We wrap the updater inside the attributeChangedCallback inside a conditional checking to see if the new value and old value are equal. We do this to prevent an infinite loop inside our program because later we are going to create a property getter and setter that will keep the property and attributes in sync by setting the element’s attribute when the element’s property gets updated. The attributeChangedCallback does the inverse: updates the property when the attribute changes.

Now, an author can consume our component and the presence of the open attribute will dictate whether or not the dialog will be open by default. To make that a bit more dynamic, we can add custom getters and setters to our element’s open property:

class OneDialog extends HTMLElement {   static get boundAttributes() {     return ['open'];   }      attributeChangedCallback(attrName, oldValue, newValue) {     this[attrName] = this.hasAttribute(attrName);   }      connectedCallback() {     const template = document.getElementById('one-dialog');     const node = document.importNode(template.content, true);     this.appendChild(node);   }      get open() {     return this.hasAttribute('open');   }      set open(isOpen) {     if (isOpen) {       this.setAttribute('open', true);     } else {       this.removeAttribute('open');     }   } }

Our getter and setter will keep the open attribute (on the HTML element) and property (on the DOM object) values in sync. Adding the open attribute will set element.open to true and setting element.open to true will add the open attribute. We do this to make sure that our element’s state is reflected by its properties. This isn’t technically required, but is considered a best practice for authoring custom elements.

This does inevitably lead to a bit of boilerplate, but creating an abstract class that keeps the these in sync is a fairly trivial task by looping over the observed attribute list and using Object.defineProperty.

Now that we know whether or not our dialog is open, let’s add some logic to actually do the showing and hiding:

class OneDialog extends HTMLElement {     /** Omitted */   constructor() {     super();     this.close = this.close.bind(this);   }      set open(isOpen) {     this.querySelector('.wrapper').classList.toggle('open', isOpen);     this.querySelector('.wrapper').setAttribute('aria-hidden', !isOpen);     if (isOpen) {       this._wasFocused = document.activeElement;       this.setAttribute('open', '');       document.addEventListener('keydown', this._watchEscape);       this.focus();       this.querySelector('button').focus();     } else {       this._wasFocused && this._wasFocused.focus && this._wasFocused.focus();       this.removeAttribute('open');       document.removeEventListener('keydown', this._watchEscape);       this.close();     }   }      close() {     if (this.open !== false) {       this.open = false;     }     const closeEvent = new CustomEvent('dialog-closed');     this.dispatchEvent(closeEvent);   }      _watchEscape(event) {     if (event.key === 'Escape') {         this.close();        }   } }

There’s a lot going on here, but let’s walk through it. The first thing we do is grab our wrapper and toggle the .open class based on isOpen. To keep our element accessible, we need to toggle the aria-hidden attribute as well.

If the dialog is open, then we want to save a reference to the previously-focused element. This is to account for accessibility standards. We also add a keydown listener to the document called watchEscape that we have bound to the element’s this in the constructor in a pattern similar to how React handles method calls in class components.

We do this not only to ensure the proper binding for this.close, but also because Function.prototype.bind returns an instance of the function with the bound call site. By saving a reference to the newly-bound method in the constructor, we’re able to then remove the event when the dialog is disconnected (more on that in a moment). We finish up by focusing on our element and setting setting the focus on the proper element in our shadow root.

We also create a nice little utility method for closing our dialog that dispatches a custom event alerting some listener that the dialog has been closed.

If the element is closed (i.e. !open), we check to make sure the this._wasFocused property is defined and has a focus method and call that to return the user’s focus back to the regular DOM. Then we remove our event listener to avoid any memory leaks.

Speaking of cleaning up after ourselves, that takes us to yet another lifecycle method: disconnectedCallback. The disconnectedCallback is the inverse of the connectedCallback in that the method is called once the element is removed from the DOM and allows us to clean up any event listeners or MutationObservers attached to our element.

It just so happens we have a few more event listeners to wire up:

class OneDialog extends HTMLElement {   /** Omitted */      connectedCallback() {         this.querySelector('button').addEventListener('click', this.close);     this.querySelector('.overlay').addEventListener('click', this.close);   }      disconnectedCallback() {     this.querySelector('button').removeEventListener('click', this.close);     this.querySelector('.overlay').removeEventListener('click', this.close);   }   }

Now we have a well-functioning, mostly accessible dialog element. There are a few bits of polish we can do, like capturing focus on the element, but that’s outside the scope of what we’re trying to learn here.

There is one more lifecycle method that doesn’t apply to our element, the adoptedCallback, which fires when the element is adopted into another part of the DOM.

In the following example, you will now see that our template element is being consumed by a standard <one-dialog> element.

See the Pen
Dialog example using template
by Caleb Williams (@calebdwilliams)
on CodePen.

Another thing: non-presentational components

The <one-template> we have created so far is a typical custom element in that it includes markup and behavior that gets inserted into the document when the element is included. However, not all elements need to render visually. In the React ecosystem, components are often used to manage application state or some other major functionality, like <Provider /> in react-redux.

Let’s imagine for a moment that our component is part of a series of dialogs in a workflow. As one dialog is closed, the next one should open. We could make a wrapper component that listens for our dialog-closed event and progresses through the workflow.

class DialogWorkflow extends HTMLElement {   connectedCallback() {     this._onDialogClosed = this._onDialogClosed.bind(this);     this.addEventListener('dialog-closed', this._onDialogClosed);   }    get dialogs() {     return Array.from(this.querySelectorAll('one-dialog'));   }    _onDialogClosed(event) {     const dialogClosed = event.target;     const nextIndex = this.dialogs.indexOf(dialogClosed);     if (nextIndex !== -1) {       this.dialogs[nextIndex].open = true;     }   } }

This element doesn’t have any presentational logic, but serves as a controller for application state. With a little effort, we could recreate a Redux-like state management system using nothing but a custom element that could manage an entire application’s state in the same one that React’s Redux wrapper does.

That’s a deeper look at custom elements

Now we have a pretty good understanding of custom elements and our dialog is starting to come together. But it still has some problems.

Notice that we’ve had to add some CSS to restyle the dialog button because our element’s styles are interfering with the rest of the page. While we could utilize naming strategies (like BEM) to ensure our styles won’t create conflicts with other components, there is a more friendly way of isolating styles. Spoiler! It’s shadow DOM and that’s what we’re going to look at in the next part of this series on Web Components.

Another thing we need to do is define a new template for every component or find some way to switch templates for our dialog. As it stands, there can only be one dialog type per page because the template that it uses must always be present. So either we need some way to inject dynamic content or a way to swap templates.

In the next article, we will look at ways to increase the usability of the <one-dialog> element we just created by incorporating style and content encapsulation using the shadow DOM.

Article Series:

  1. An Introduction to Web Components
  2. Crafting Reusable HTML Templates
  3. Creating a Custom Element from Scratch (This post)
  4. Encapsulating Style and Structure with Shadow DOM (Coming soon!)
  5. Advanced Tooling for Web Components (Coming soon!)

The post Creating a Custom Element from Scratch appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Little Things That Tickled My Brain from An Event Apart Seattle

I had so much fun at An Event Apart Seattle! There is something nice about sitting back and basking in the messages from a variety of such super smart people.

I didn’t take comprehensive notes of each talk, but I did jot down little moments that flickered my brain. I’ll post them here! Blogging is fun! Again, note that these moments weren’t necessarily the main point of the speaker’s presentation or reflective of the whole journey of the topic — they are little micro-memorable moments that stuck out to me.


Jeffrey Zeldman brought up the reading apps Instapaper (still around!) and Readability (not around… but the technology is what seeped into native browser tech). He called them a vanguard (cool word!) meaning they were warning us that our practices were pushing users away. This turned out to be rather true, as they still exist and are now joined by new technologies, like AMP and native reader mode, which are fighting the same problems.


Margot Bloomstein made a point about inconsistency eroding our ability to evaluate and build trust. Certainly applicable to websites, but also to a certain President of the United States.

President Flip Flops

Sarah Parmenter shared a powerful moment where she, through the power of email, reached out to Bloom and Wild, a flower mail delivery service, to tell them a certain type of email they were sending she found to be, however unintentionally, very insensitive. Sarah was going to use this as an example anyway, but the day before, Bloom and Wild actually took her advice and implemented a specialized opt-out system.

This not only made Sarah happy that a company could actually change their systems to be more sensitive to their customers, but it made a whole ton of people happy, as evidenced by an outpouring of positive tweets after it happened. Turns out your customers like it when you, ya know, think of them.


Eric Meyer covered one of the more inexplicable things about pseudo-elements: if you content: url(/icons/icon.png); you literally can’t control the width/height. There are ways around it, notably by using a background image instead, but it is a bit baffling that there is a way to add an image to a page with no possible way to resize it.

Literally, the entire talk was about pseudo-elements, which I found kinda awesome as I did that same thing eight years ago. If you’re looking for some nostalgia (and are OK with some cringe-y moments), here’s the PDF.

Eric also showed a demo that included a really neat effect that looks like a border going from thick to thin to thick again, which isn’t really something easily done on the web. He used a pseudo, but here it is as an <hr> element:

See the Pen
CSS Thick-Thin-Thick Line
by Chris Coyier (@chriscoyier)
on CodePen.


Rachel Andrew had an interesting way of talking about flexbox. To paraphrase:

Flexbox isn’t the layout method you think it is. Flexbox looks at some disparate things and returns some kind of reasonable layout. Now that grid is here it’s a lot more common to use that to be more much explict about what we are doing with layout. Not that flexbox isn’t extremely useful.

Rachel regularly pointed out that we don’t know how tall things are in web design, which is just so, so true. It’s always been true. The earlier we embrace that, the better off we’ll be. So much of our job is dealing with overflow.

Rachel brought up a concept that was new to me, in the sense that it has an official name. The concept is “data loss” through CSS. For example, aligning something a certain way might cause some content to become visually hidden and totally unreachable. Imagine some boxes like this, set in flexbox, with center alignment:

No “data loss” there because we can read everything. But let’s say we have more content in some of them. We can never know heights!

If that element was along the top of a page, for example, no scrollbar will be triggered because it’s opposite the scroll direction. We’d have “data loss” of that text:

We now alignment keywords that help with this. Like, we can still attempt to center, but we can save ourselves by using safe center (unsafe center being the default):

Rachel also mentioned overlapping as a thing that grid does better. Here’s a kinda bad recreation of what she showed:

See the Pen
Overlapping Figure with CSS Grid
by Chris Coyier (@chriscoyier)
on CodePen.

I was kinda hoping to be able to do that without being as explicit as I am being there, but that’s as close as I came.


Jen Simmons showed us a ton of different scenarios involving both grid and flexbox. She made a very clear point that a grid item can be a flexbox container (and vice versa).

Perhaps the most memorable part is how honest Jen was about how we arrive at the layouts were shooting for. It’s a ton of playing with the possible values and employing a little trial and error. Happy accidents abound! But there is a lot to know about the different sizing values and placement possibilties of grid, so the more you know the more you can play. While playing, the layout stuff in Firefox DevTools is your best bet.

Flexbox with gap is gonna be sweet.

There was a funny moment in Una Kravets’ talk about brainstorming the worst possible ideas.

The idea is that even though brainstorm sessions are supposed to be judgment-free, they never are. Bad ideas are meant to be bad, so the worst you can do is have a good idea. Even better, starting with good ideas is problematic in that it’s easy to get attached to an idea too early, whereas bad ideas allow more freedom to jump through ideation space and land on better ideas.


Scott Jehl mentioned a fascinating idea where you can get the benefits of inlining code and caching files at the same time. That’s useful for stuff we’ve gotten used to seeing inlined, like critical CSS. But you know what else is awesome to inline? SVG icon systems. Scott covered the idea in his talk, but I wanted to see if it I could give it a crack myself.

The idea is that a fresh page visit inlines the icons, but also tosses them in cache. Then other pages can <svg><use> them out of the cache.

Here’s my demo page. It’s not really production-ready. For example, you’d probably want to do another pass where you Ajax for the icons and inject them by replacing the <use> so that everywhere is actually using inline <svg> the same way. Plus, a server-side system would be ideal to display them either way depending on whether the cache is present or not.


Jeremy Keith mentioned the incredible prime number shitting bear, which is, as you might suspect, computationally expensive. He mentioned it in the context of web workers, which is essentially JavaScript that runs in a separate thread, so it won’t/can’t slow down the operation of the current page. I see that same idea has crossed other people’s minds.


I’m sad that I didn’t get to see every single talk because I know they were all amazing. There are plenty of upcoming shows with some of the same folks!

The post Little Things That Tickled My Brain from An Event Apart Seattle appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , ,
[Top]

The Process of Implementing A UI Design From Scratch

This is a fantastic post by Ahmad Shadeed. It digs into the practical construction of a header on a website — the kind of work that many of us regularly do. It looks like it’s going to be fairly easy to create the header at first, but it starts to get complicated as considerations for screen sizes, edge cases, interactions, and CSS layout possibilities enter the mix. This doesn’t even get into cross-browser concerns, which have been somewhat less of a struggle lately, but is always there.

It’s sometimes hard to explain the interesting and tricky situations that define our work in front-end development, and this article does a good job of showcasing that.

These two illustrations set the scene really well:

That’s not to dunk on designers. I’ve done this to myself plenty of times. Plus, any designer worth their salt thinks about these things right off the bat. The reality is that the implementation weirdness largely falls to the front-end developer and the designer can help when big choices need to be made or the solutions need to be clarified.

Direct Link to ArticlePermalink

The post The Process of Implementing A UI Design From Scratch appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Extracting Text from Content Using HTML Slot, HTML Template and Shadow DOM

Chapter names in books, quotes from a speech, keywords in an article, stats on a report — these are all types of content that could be helpful to isolate and turn into a high-level summary of what’s important.

For example, have you seen the way Business Insider provides an article’s key points before getting into the content?

That’s the sort of thing we’re going to do, but try to extract the high points directly from the article using HTML Slot, HTML Template and Shadow DOM.

These three titular specifications are typically used as part of Web Components — fully functioning custom element modules meant to be reused in webpages.

Now, what we aim to do, i.e. text extraction, doesn’t need custom elements, but it can make use of those three technologies.

There is a more rudimentary approach to do this. For example, we could extract text and show the extracted text on a page with some basic script without utilizing slot and template. So why use them if we can go with something more familiar?

The reason is that using these technologies permits us a preset markup code (also optionally, style or script) for our extracted text in HTML. We’ll see that as we proceed with this article.

Now, as a very watered-down definition of the technologies we’ll be using, I’d say:

  • A template is a set of markup that can be reused in a page.
  • A slot is a placeholder spot for a designated element from the page.
  • A shadow DOM is a DOM tree that doesn’t really exist on the page till we add it using script.

We’ll see them in a little more depth once we get into coding. For now, what we’re going to make is an article that follows with a list of key points from the text. And, you probably guessed it, those key points are extracted from the article text and compiled into the key points section.

See the Pen
Text Extraction with HTML Slot and HTML Template
by Preethi Sam (@rpsthecoder)
on CodePen.

The key points are displayed as a list with a design in between the points. So, let’s first create a template for that list and designate a place for the list to go.

<article><!-- Article content --></article>  <!-- Section where the extracted keypoints will be displayed --> <section id='keyPointsSection'>   <h2>Key Points:</h2>   <ul><!-- Extracted key points will go in here --></ul> </section>  <!-- Template for the key points list --> <template id='keyPointsTemplate'>   <li><slot name='keyPoints'></slot></li>   <li style="text-align: center;">&#x2919;&mdash;&#x291a;</li> </template>

What we’ve got is a semantic <section> with a <ul> where the list of key points will go. Then we have a <template> for the list items that has two <li> elements: one with a <slot> placeholder for the key points from the article and another with a centered design.

The layout is arbitrary. What’s important is placing a <slot> where the extracted key points will go. Whatever’s inside the <template> will not be rendered on the page until we add it to the page using script.

Further, the markup inside <template> can be styled using inline styles, or CSS enclosed by <style>:

<template id='keyPointsTemplate'>     <li><slot name='keyPoints'></slot></li>     <li style="text-align: center;">&#x2919;&mdash;&#x291a;</li>     <style>         li{/* Some style */}     </style> </template>

The fun part! Let’s pick the key points from the article. Notice the value of the name attribute for the <slot> inside the <template> (keyPoints) because we’ll need that.

<article>   <h1>Bears</h1>   <p>Bears are carnivoran mammals of the family Ursidae. <span><span slot='keyPoints'>They are classified as caniforms, or doglike carnivorans</span></span>. Although only eight species of bears <!-- more content --> and partially in the Southern Hemisphere. <span><span slot='keyPoints'>Bears are found on the continents of North America, South America, Europe, and Asia</span></span>.<!-- more content --></p>   <p>While the polar bear is mostly carnivorous, <!-- more content -->. Bears use shelters, such as caves and logs, as their dens; <span><span slot='keyPoints'>Most species occupy their dens during the winter for a long period of hibernation</span></span>, up to 100 days.</p>   <!-- More paragraphs -->  </article>

The key points are wrapped in a <span> carrying a slot attribute value (“keyPoints“) matching the name of the <slot> placeholder inside the <template>.

Notice, too, that I’ve added another outer <span> wrapping the key points.

The reason is that slot names are usually unique and are not repeated, because one <slot> matches one element using one slot name. If there’re more than one element with the same slot name, the <slot> placeholder will be replaced by all those elements consecutively, ending in the last element being the final content at the placeholder.

So, if we matched that one single <slot> inside the <template> against all of the <span> elements with the same slot attribute value (our key points) in a paragraph or the whole article, we’d end up with only the last key point present in the paragraph or the article in place of the <slot>.

That’s not what we need. We need to show all the key points. So, we’re wrapping the key points with an outer <span> to match each of those individual key points separately with the <slot>. This is much more obvious by looking at the script, so let’s do that.

const keyPointsTemplate = document.querySelector('#keyPointsTemplate').content; const keyPointsSection = document.querySelector('#keyPointsSection > ul'); /* Loop through elements with 'slot' attribute */ document.querySelectorAll('[slot]').forEach((slot)=>{   let span = slot.parentNode.cloneNode(true);   span.attachShadow({  mode: 'closed' }).appendChild(keyPointsTemplate.cloneNode(true));   keyPointsSection.appendChild(span); });

First, we loop through every <span> with a slot attribute and get a copy of its parent (the outer <span>). Note that we could also loop through the outer <span> directly if we’d like, by giving them a common class value.

The outer <span> copy is then attached with a shadow tree (span.attachShadow) made up of a clone of the template’s content (keyPointsTemplate.cloneNode(true)).

This “attachment” causes the <slot> inside the template’s list item in the shadow tree to absorb the inner <span> carrying its matching slot name, i.e. our key point.

The slotted key point is then added to the key points section at the end of the page (keyPointsSection.appendChild(span)).

This happens with all the key points in the course of the loop.

That’s really about it. We’ve snagged all of the key points in the article, made copies of them, then dropped the copies into the list template so that all of the key points are grouped together providing a nice little CliffsNotes-like summary of the article.

Here’s that demo once again:

See the Pen
Text Extraction with HTML Slot and HTML Template
by Preethi Sam (@rpsthecoder)
on CodePen.

What do you think of this technique? Is it something that would be useful in long-form content, like blog posts, news articles, or even Wikipedia entries? What other use cases can you think of?

The post Extracting Text from Content Using HTML Slot, HTML Template and Shadow DOM appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , , ,
[Top]

What We Want from Grid

We felt spoiled with CSS grid for a minute there. It arrived hot and fast in all the major browsers all at once. Now that we’re seeing a lot more usage, we’re seeing people want more from grid.

Michelle Barker lists hers wants (and I’ll put my commentary after):

  • Styling row and column gaps. I’ve also heard requested styling grid cells directly, rather than needing to place an element there and style that element.
  • Multiple gap values. I wanted this just the other week, and I was told to use an empty column or row instead of a gap. The size of that column can be controlled, and things are placed accordingly to treat it like a gap. Sort of OK, except that isn’t particularly friendly to implicit grids.
  • Autoflow patterns. This is clever. Check out Michelle’s use case and proposal.
  • calc() with the fr unit. This is a mindbender. I can see wanting to do something like calc(1fr - 100px), but then isn’t the leftover space 100px short and 1fr recalcuated to fill that space? Seems infinite loopy.
  • Aspect ratio grid cells. I suspect, if we get this, it’ll be a generic aspect ratio solution that will work on any element, including elements placed onto a grid.

Subgrid is also starting to be hotly requested, and I can see why. While building the last page layout I did using grid, I found myself strongly wishing I could share the overall page grid lines within sub-elements.

Rachel Andrew talked about its status about six months ago in CSS Grid Level 2: Here Comes Subgrid. I’m not sure where it’s at now, but I don’t think any browser is supporting it quite yet. (I’m not even sure if the spec is technically done.)

Brad put a point on the desire here:

And Ken Bellows writes:

  • If we combine subgrid with grid-template-areas within the cards (read my last post if you don’t know about Grid Areas, it’ll blow your mind), complex responsive card-based layouts become trivial.
  • The prospect of a subgrid on both axes gives us a way to sort of accomplish relative grid positioning, at least for semantically grouped items, like I wished I had above! Group your stuff in a container, position your container on the grid, make that container a subgrid on both axes, and declare your tracks relative to the subgrid element’s grid position!
  • Between Flexbox, Grid, display: contents, and subgrids, we will finally have everything we need to write very slim, clean, semantic markup with basically no fluff or purely structural elements. It will be a huge boon for accessibility, SEO, and just developers trying to understand your markup!

Eric Meyer called subgrid an essential feature three years ago:

This is why I’ve come to the same conclusion other grid experts (like Rachel) already have: subgrids are a major component of grid layout, and should be a part of any grid layout implementation when it emerges from developer-preview status.  If that means delaying the emergence of grids, I think it’s worth it.

And of course, everybody still wants native masonry. 😉

The post What We Want from Grid appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Sass Techniques from the Trenches

Having been in the web development industry for more than 14 years, I’ve seen and written my fair share of good and bad CSS. When I began at Ramsey Solutions five years ago, I was introduced to Sass. It blew my mind how useful it was! I dove right in and wanted to learn everything I could about it. Over the past five years, I’ve utilized a number of different Sass techniques and patterns and fell in love with some that, to steal Apple’s phrase, just work.

In this article, I’ll explore a wide range of topics:

In my experience, finding the balance between simple and complex is the crucial component to making great software. Software should not only be easy for people to use, but for you and other developers to maintain in the future. I’d consider these techniques to be advanced, but not necessarily clever or complex, on purpose!

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”

—The Elements of Programming and Style (2nd Edition), Chapter 2

With that in mind, let’s first look at Sass’ ampersand.


The power of the ampersand

There are many different naming conventions you can use to organize your CSS. The one I enjoy using the most is SUIT, a variation of BEM (which is short for Block, Element, Modifier). If you’re unfamiliar with SUIT or BEM, I’d recommend taking a peek at one or both of them before moving on. I’ll be using the SUIT convention throughout the rest of this article.

Whatever naming convention you choose, the base idea is that every styled element gets its own class name, prepended with the component name. This idea is important for how some of the following organization works. Also, this article is descriptive, not prescriptive. Every project is different. You need to do what works best for your project and your team.

The ampersand is the main reason I like to use SUIT, BEM, and conventions like them. It allows me to use nesting and scoping without either biting back with specificity. Here’s an example. Without using the ampersand, I would need to create separate selectors to create -title and -content elements.

.MyComponent {   .MyComponent-title {} }  .MyComponent-content {}  // Compiles to .MyComponent .MyComponent-title {} // Not what we want. Unnecessary specificity! .MyComponent-content {} // Desired result

When using SUIT, I want the second result for -content to be how I write all my selectors. To do so, I would need to repeat the name of the component throughout. This increases my chance to mistype the name of the component as I write new styles. It’s also very noisy as it ends up ignoring the beginning of many selectors which can lead to glossing over obvious errors.

.MyComponent {} .MyComponent-title {} .MyComponent-content {} .MyComponent-author {} // Etc.

If this were normal CSS, we’d be stuck writing the above. Since we’re using Sass, there’s a much better approach using the ampersand. The ampersand is amazing because it contains a reference to the current selector along with any parents.

.A {   // & = '.A'   .B {     // & = '.A .B'     .C {       // & = '.A .B .C'     }   } }

You can see in the above example how the ampersand references each selector in the chain as it goes deeper into the nested code. By utilizing this feature, we can create new selectors without having to rewrite the name of the component each and every time.

.MyComponent {   &-title {}      &-content {} }  // Compiles to .MyComponent {} .MyComponent-title {} .MyComponent-content {}

This is great because we can take advantage of the ampersand to write the name of the component one time and simply reference the component name throughout. This decreases the chance that the component name is mistyped. Plus, the document as a whole becomes easier to read without .MyComponent repeated all over the code.


There are times when the component needs a variant or modifier, as they’re called in SUIT and BEM. Using the ampersand pattern makes it easier to create modifiers.

<div class="MyComponent MyComponent--xmasTheme"></div>
.MyComponent {   &--xmasTheme {} }  // Compiles to .MyComponent {} .MyComponent--xmasTheme {}

“But, what about modifying the child elements?” you might ask. “How are those selectors created? The modifier isn’t needed on every element, right?”

This is where variables can help!

Variables and scoping

In the past, I’ve created modifiers a few different ways. Most of the time, I’d rewrite the special theme name I want to apply when modifying the element.

.MyComponent {   &-title {     .MyComponent--xmasTheme & {     }   }      &-content {     .MyComponent--xmasTheme & {     }   } }  // Compiles to .MyComponent-title {} .MyComponent--xmasTheme .MyComponent-title {} .MyComponent-content {} .MyComponent--xmasTheme .MyComponent-content {}

This gets the job done, but I’m back to rewriting the component name in multiple places, not to mention the modifier name. There’s definitely a better way to do this. Enter Sass variables.

Before we explore Sass variables with selectors, we need to understand how they’re scoped. Sass variables have scope, just like they would in JavaScript, Ruby, or any other programming language. If declared outside of a selector, the variable is available to every selector in the document after its declaration.

$ fontSize: 1.4rem;  .a { font-size: $ fontSize; } .b { font-size: $ fontSize; }

Variables declared inside a selector are scoped only to that selector and its children.

$ fontSize: 1.4rem;  .MyComponent {    $ fontWeight: 600;   font-size: $ fontSize;       &-title {     font-weight: $ fontWeight; // Works!   } }  .MyComponent2 {    font-size: $ fontSize;       &-title {     font-weight: $ fontWeight; // produces an "undefined variable" error   } }

We know variables can store font names, integers, colors, etc. Did you know it can also store selectors? Using string interpolation, we can create new selectors with the variable.

// Sass string interpolation syntax is #{VARIABLE}  $ block: ".MyComponent";  #{$ block} {   &-title {     #{$ block}--xmasTheme & {     }   } }  // Compiles to .MyComponent {} .MyComponent-title {} .MyComponent--xmasTheme .MyComponent-title {}

That’s cool, but the variable is globally scoped. We can fix that by creating the $ block variable inside the component declaration, which would scope it to that component. Then we can re-use the $ block variable in other components. This helps DRY up the theme modifier.

.MyComponent {   $ block: '.MyComponent';      &-title {     #{$ block}--xmasTheme & {     }   }      &-content {     #{$ block}--xmasTheme & {     }   } }  // Compiles to .MyComponent {} .MyComponent-title {} .MyComponent--xmasTheme .MyComponent-title {} .MyComponent-content {} .MyComponent--xmasTheme .MyComponent-content {}

This is closer, but again, we have to write the theme name over and over. Let’s store that in a variable too!

.MyComponent {   $ block: '.MyComponent';   $ xmasTheme: '.MyComponent--xmasTheme';      &-title {     #{$ xmasTheme} & {     }   } }

This is much better! However, we can improve this even further. Variables can also store the value of the ampersand!

.MyComponent {   $ block: &;   $ xmasTheme: #{&}--xmasTheme;      &-title {     #{$ xmasTheme} & {     }   } }  // Still compiles to .MyComponent {} .MyComponent-title {} .MyComponent--xmasTheme .MyComponent-title {}

Now that’s what I’m talking about! “Caching” the selector with ampersand allows us to create our modifiers at the top and keep the theme modifications with the element it’s modifying.

“Sure, that works at the top level,” you say. “But what if you are nested really deep, like eight levels in?” You ask great questions.

No matter how deep the nest, this pattern always works because the main component name is never attached to any of the children, thanks to the SUIT naming convention and ampersand combo.

.MyComponent {    $ block: &;   $ xmasTheme: #{&}--xmasTheme;      &-content {     font-size: 1.5rem;     color: blue;          ul {       li {         strong {           span {             &::before {               background-color: blue;                              #{$ xmasTheme} & {                 background-color: red;               }             }           }         }       }     }   } }  // Compiles to  .MyComponent-content {   font-size: 1.5rem;   color: blue; }  .MyComponent-content ul li strong span::before {   background-color: blue; }  /* * The theme is still appended to the beginning of the selector! * Now, we never need to write deeply nested Sass that's hard to maintain and  * extremely brittle: https://css-tricks.com/sass-selector-combining/ */ .MyComponent--xmasTheme .MyComponent-content ul li strong span::before {   background-color: red; }

Code organization is the main reason I like to use this pattern.

  • It’s relatively DRY
  • It supports the “opt-in” approach, which keeps modifiers with the elements they modify
  • Naming stuff is hard but this enables us to reuse common element names like “title” and “content”
  • It’s low-lift to add a modifier to a component by placing the modifier class on the parent component

“Hhhmmmmm… doesn’t that get hard to read though after you create a bunch of different components? How do you know where you’re at when everything is named &-title and &-content?”

You continue to ask great questions. Who said the source Sass had to be in one file? We can import those components, so let’s turn to that topic!

The importance of imports

Credit: @Julien_He

One of Sass’ best features is @import. We can create separate Sass files (partials) and import them into other Sass files that compile together with the imported file located at the spot it’s imported. This makes it easy to package up related styles for components, utilities, etc. and pull them into a single file. Without @import, we’d need to link to separate CSS files (creating numerous network requests, which is badong) or write everything in a single stylesheet (which is tough to navigate and maintain).

.Component1 {   &-title {}   &-content {}   &-author {} }  .Component2 {   &-title {}   &-content {}   &-author {} }  .Component3 {   &-title {}   &-content {}   &-author {} }  .Component4 {   &-title {}   &-content {}   &-author {} }  .Component5 {   &-title {}   &-content {}   &-author {} }  // A couple hundred lines later...  .Component7384 {   &-title {}   &-content {}   &-author {} }  // WHERE AM I?

One of the more popular methodologies for organizing Sass files is the 7-1 Pattern. That’s seven distinct folders containing Sass files that are imported into a single Sass file.

Those folders are:

  • abstracts
  • base
  • components
  • layout
  • pages
  • themes
  • vendor

Use @import to pull each Sass file in those folder into a main Sass file. We want to import them in the following order to maintain good scope and avoid conflicts during compilation:

  1. abstracts
  2. vendor
  3. base
  4. layout
  5. components
  6. pages
  7. themes
@import 'abstracts/variables'; @import 'abstracts/functions'; @import 'abstracts/mixins';  @import 'vendors/some-third-party-component';  @import 'base/normalize';  @import 'layout/navigation'; @import 'layout/header'; @import 'layout/footer'; @import 'layout/sidebar'; @import 'layout/forms';  @import 'components/buttons'; @import 'components/hero'; @import 'components/pull-quote';  @import 'pages/home'; @import 'pages/contact';  @import 'themes/default'; @import 'themes/admin';

You may or may not want to use all of these folders (I personally don’t use the theme folder since I keep themes with their components), but the idea of separating all of styles into distinct files makes it easier to maintain and find code.

More of the benefits of using this approach:

  • Small components are easier to read and understand
  • Debugging becomes simpler
  • It’s clearer to determine when a new component should be created — like when a single component file gets to be too long, or the selector chain is too complex
  • This emphasizes re-usage — for example, it might make sense to generalize three component files that essentially do the same thing into one component

Speaking of re-usage, there are eventually patterns that get used often. That’s when we can reach for mixins.

Mixin’ it up

Mixins are a great way to reuse styles throughout a project. Let’s walk through creating a simple mixin and then give it a little bit of intelligence.

The designer I work with on a regular basis always sets font-size, font-weight, and line-height to specific values. I found myself typing all three out every time I needed to adjust the fonts for a component or element, so I created a mixin to quickly set those values. It’s like a little function I can use to define those properties without having to write them in full.

@mixin text($ size, $ lineHeight, $ weight) {   font-size: $ size;   line-height: $ lineHeight;   font-weight: $ weight; }

At this point, the mixin is pretty simple—it resembles something like a function in JavaScript. There’s the name of the mixin (text) and it takes in three arguments. Each argument is tied to a CSS property. When the mixin is called, Sass will copy the properties and the pass in the argument values.

.MyComponent {   @include text(18px, 27px, 500); }  // Compiles to .MyComponent {   font-size: 18px;   line-height: 27px;   font-weight: 500; }

While it’s a good demonstration, this particular mixin is a little limited. It assumes we always want to use the font-size, line-height, and font-weight properties when it’s called. So let’s use Sass’ if statement to help control the output.

@mixin text($ size, $ lineHeight, $ weight) {   // If the $ size argument is not empty, then output the argument   @if $ size != null {     font-size: $ size;   }      // If the $ lineHeight argument is not empty, then output the argument   @if $ lineHeight != null {     line-height: $ lineHeight;   }      // If the $ weight argument is not empty, then output the argument   @if $ weight != null {     font-weight: $ weight;   } }  .MyComponent {   @include text(12px, null, 300); }  // Compiles to .MyComponent {   font-size: 12px;   font-weight: 300; }

That’s better, but not quite there. If I try to use the mixin without using null as a parameter on the values I don’t want to use or provide, Sass will generate an error:

.MyComponent {   @include text(12px, null); // left off $ weight }  // Compiles to an error: // "Mixin text is missing argument $ weight."

To get around this, we can add default values to the parameters, allowing us to leave them off the function call. All optional parameters have to be declared after any required parameters.

// We define `null` as the default value for each argument @mixin text($ size: null, $ lineHeight: null, $ weight: null) {   @if $ size != null {     font-size: $ size;   }      @if $ lineHeight != null {     line-height: $ lineHeight;   }      @if $ weight != null {     font-weight: $ weight;   } }  .MyComponent {   &-title {     @include text(16px, 19px, 600);   }      &-author {     @include text($ weight: 800, $ size: 12px);   } }  // Compiles to .MyComponent-title {   font-size: 16px;   line-height: 19px;   font-weight: 600; }  .MyComponent-author {   font-size: 12px;   font-weight: 800; }

Not only do default argument values make the mixin easier to use, but we also gain the ability to name parameters and give them values that may be commonly used. On Line 21 above, the mixin is being called with the arguments out of order, but since the values are being called out as well, the mixin knows how to apply them.


There’s a particular mixin that I use on a daily basis: min-width. I prefer to create all my sites mobile first, or basically with the smallest viewport in mind. As the viewport grows wider, I define breakpoints to adjust the layout and the code for it. This is where I reach for the min-width mixin.

// Let's name this "min-width" and take a single argument we can // use to define the viewport width in a media query. @mixin min-width($ threshold) {   // We're calling another function (scut-rem) to convert pixels to rem units.   // We'll cover that in the next section.   @media screen and (min-width: scut-rem($ threshold)) {     @content;   } }  .MyComponent {   display: block;      // Call the min-width mixin and pass 768 as the argument.   // min-width passes 768 and scut-rem converts the unit.   @include min-width(768) {     display: flex;   } }  // Compiles to  .MyComponent {   display: block; }  @media screen and (min-width: 48rem) {   .MyComponent {     display: flex;   } }

There are a couple of new ideas here. The mixin has a nested function called @content. So, in the .MyComponent class, we’re no longer calling the mixin alone, but also a block of code that gets output inside the media query that’s generated. The resulting code will compile where @content is called. This allows the mixin to take care of the @media declaration and still accept custom code for that particular breakpoint.

I also am including the mixin within the .MyComponent declaration. Some people advocate keeping all responsive calls in a separate stylesheet to reduce the amount of times @media is written out in a stylesheet. Personally, I prefer to keep all variations and changes that a component can go through with that component’s declaration. It tends to make it easier to keep track of what’s going on and help debug the component if something doesn’t go right, rather than sifting through multiple files.

Did you notice the scut-rem function in there? That is a Sass function taken from a Sass library called Scut, created by David The Clark. Let’s take a look at how that works.

Getting functional

A function differs from a mixin in that mixins are meant to output common groups of properties, while a function modifies properties based on arguments that return a new result. In this case, scut-rem takes a pixel value and converts it to a rem value. This allows us to think in pixels, while working with rem units behind the scenes to avoid all that math.

I’ve simplified scut-rem in this example because it has a few extra features that utilize loops and lists, which are out of the scope of what we’re covering here. Let’s look at the function in its entirety, then break it down step-by-step.

// Simplified from the original source $ scut-rem-base: 16 !default;  @function scut-strip-unit ($ num) {   @return $ num / ($ num * 0 + 1); }  @function scut-rem ($ pixels) {   @return scut-strip-unit($ pixels) / $ scut-rem-base * 1rem; }  .MyComponent {   font-size: scut-rem(18px);   }  // Compiles to .MyComponent {   font-size: 1.125rem; }

The first thing to note is the declaration on Line 2. It’s using !default when declaring a variable, which tells Sass to set the value to 16 unless this variable is already defined. So if a variable is declared earlier in the stylesheet with a different value, it won’t be overridden here.

$ fontSize: 16px; $ fontSize: 12px !default;  .MyComponent {   font-size: $ fontSize; }  // Compiles to .MyComponent {   font-size: 16px; }

The next piece of the puzzle is scut-strip-unit. This function takes a px, rem, percent or other suffixed value and removes the unit label. Calling scut-strip-unit(12px) returns 12 instead of 12px. How does that work? In Sass, a unit divided by another unit of the same type will strip the unit and return the digit.

12px / 1px = 12

Now that we know that, let’s look at the scut-strip-unit function again.

@function scut-strip-unit ($ num) {   @return $ num / ($ num * 0 + 1); }

The function takes in a unit and divides it by 1 of the same unit. So if we pass in 12px, the function would look like: @return 12px / (12px * 0 + 1). Following the order of operations, Sass evaluates what’s in the parentheses first. Sass smartly ignores the px label, evaluates the expression, and tacks px back on once it’s done: 12 * 0 + 1 = 1px. The equation is now 12px / 1px which we know returns 12.

Why is this important to scut-rem? Looks look at it again.

$ scut-rem-base: 16 !default;  @function scut-rem ($ pixels) {   @return scut-strip-unit($ pixels) / $ scut-rem-base * 1rem; }  .MyComponent {   font-size: scut-rem(18px);   }

On Line 4, the scut-strip-unit function removes px from the argument and returns 18. The base variable is equal to 16 which turns the equation into: 18 / 16 * 1rem. Remember, Sass ignores any unit until the end of the equation, so 18 / 16 = 1.125. That result multiplied by 1rem gives us 1.125rem. Since Scut strips the unit off of the argument, we can call scut-rem with unit-less values, like scut-rem(18).

I don’t write that many functions because I try to keep the stuff I create as simple as possible. Being able to do some complex conversions using something like scut-rem is helpful though.

The selector order that placeholders mess up

End up where I think it did, that CSS?

I really don’t like to use placeholders and @extend in my code. I find it easy to get in trouble with them for a couple different reasons.

Be careful what is extended

I tried writing out some examples to demonstrate why using @extend can be problematic, but I have used them so little that I can’t create any decent examples. When I first learned Sass, I was surrounded by teammates who’ve already gone through the trials and tribulations. My friend Jon Bebee wrote an extremely excellent article on how @extend can get you into trouble. It’s a quick read and worth the time, so I’ll wait.

About those placeholders…

Jon proposes using placeholders as a solution to the problem he outlines: Placeholders don’t output any code until they’re used with @extend.

// % denotes an extended block %item {   display: block;   width: 50%;   margin: 0 auto; }  .MyComponent {   @extend %item;   color: blue; }  // Compiles to .MyComponent {   display: block;   width: 50%;   margin: 0 auto; }  .MyComponent {   color: blue; }

OK, wait. So it output .MyComponent twice? Why didn’t it simply combine the selectors?

These are the questions I had when I first started using placeholders (and then subsequently stopped). The clue is the name itself. Placeholders simply hold a reference to the place in the stylesheet they were declared. While a mixin copies the properties to the location it is used, placeholders copy the selector to the place where the placeholder was defined. As a result, it copies the .MyComponent selector and places it where %item is declared. Consider the following example:

%flexy {   display: flex; }  .A {   color: blue; }  .B {   @extend: %flexy;   color: green; }  .C {   @extend: %flexy;   color: red; }  // Compiles to .B, .C {   display: flex; }  .A {   color: blue; }  .B {   color: green; }  .C {   color: red; }

Even though B and C are declared further down in the stylesheet, the placeholder places the extended properties tall the way up to where it was originally declared. That’s not a big deal in this example because it’s really close to the source where it’s used. However, if we’re adhering to something like the 7-1 Pattern we covered earlier, then placeholders would be defined in a partial in the abstracts folder, which is one of the first imported files. That puts a lot of style between where the extend is intended and where it’s actually used. That can be hard to maintain as well as hard to debug.

Sass Guidelines (of course) does a great job covering placeholders and extend and I would recommend reading it. It not only explains the extend feature, but at the end, advocates against using it:

Opinions seem to be extremely divided regarding the benefits and problems from @extend to the point where many developers including myself have been advocating against it, […]


There are many other features of Sass I didn’t cover here, like loops and lists, but I’ve honestly haven’t relied on those features as much as the ones we did cover in this article. Take a look through the Sass documentation, if for nothing else, to see what things do. You may not find a use for everything right away, but a situation may come up and having that knowledge in your back pocket is priceless.

Let me know if I missed something or got something wrong! I’m always open to new ideas and would love to discuss it with you!

Further Reading

The post Sass Techniques from the Trenches appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]