Tag: Modern

How You Might Build a Modern Day Webring

I’m sure different people picture different things when they think about webrings, so let me clarify what I picture. I see an element on a website that:

  1. Signifies this site is part of a webring
  2. Allows you to move to the next or previous site of the webring
  3. Maybe has other functionality like going to a “random” site or seeing the complete list

But then another major thing:

  1. Site owners don’t have to do much. They just plop (it?) on the site and a functional webring UI is there.

So like this:

A Calvin & Hobbes webring UI that comes up all the time when you search the web about webrings

How did it used to work? You know what? I have no idea. My guess is that it was an ancient <frameset><frame /></frameset> situation, but this stuff is before my time a bit. How might we do this today?

Well, we could use an <iframe>, I guess. That’s what sites like YouTube do when they give “embed code” as an HTML snippet. Sites like Twitter and CodePen give you a <div> (or whatever semantic HTML) and a <script>, so that there can be fallback content and the script enhances it into an <iframe>. An <iframe> might be fine, as it asks very little of the site owner, but they are known to be fairly bad for performance. It’s a whole document inside another document, after all. Plus, they don’t offer much by the way of customization. You get what you get.

Another problem with an iframe is that… how would it know what site it is currently embedded on? Maybe a URL parameter? Maybe a postMessage from the parent page? Not super clean if you ask me.

I think a Web Component might be the way to go here, as long as we’re thinking modern. We could make a custom element like <webring-*>. Let’s do that, and make it for CSS sites specifically. That’ll give us the opportunity to send in the current site with an attribute, like this:

<webring-css site="http://css-tricks.com">   This is gonna boot itself up into webring in a minute. </webring-css>

That solves the technology choice. Now we need to figure out the global place to store the data. Because, well, a webring needs to be able to be updated. Sites need to be able to be added and removed from the webring without the other sites on the webring needing to do anything.

For fairly simple data like this, a JSON file on GitHub seems to be a perfectly modern choice. Let’s do that.

Now everyone can see all the sites in the webring in a fairly readable fashion. Plus, they could submit Pull Requests against it to add/remove sites (feel free).

Getting that data from our web component is a fetch away:

fetch(`https://raw.githubusercontent.com/CSS-Tricks/css-webring/main/webring.json`)   .then((response) => response.json())   .then((sites) => {      // Got the data.   });

We’ll fire that off when our web component mounts. Let’s scaffold that…

const DATA_FOR_WEBRING = `https://raw.githubusercontent.com/CSS-Tricks/css-webring/main/webring.json`;  const template = document.createElement("template"); template.innerHTML = ` <style>   /* styles */ </style>  <div class="webring">   <!-- content --> </div>`;  class WebRing extends HTMLElement {   connectedCallback() {     this.attachShadow({ mode: "open" });     this.shadowRoot.appendChild(template.content.cloneNode(true));      fetch(DATA_FOR_WEBRING)       .then((response) => response.json())       .then((sites) => {         // update template with data       });   } }  window.customElements.define("webring-css", WebRing); 

The rest of this isn’t so terribly interesting that I feel like we need to go through it step by step. I’ll just blog-sketch it for you:

  1. Pull the attribute off the web component so we can see what the current site is
  2. Match the current site in the data
  3. Build out Next, Previous, and Random links from the data in a template
  4. Update the HTML in the template

And voilà!

Could you do a lot more with this, like error handling, better design, and better everything?

Yes.


The post How You Might Build a Modern Day Webring appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,

In Defense of Tables and Floats in Modern Day Development

Twenty-plus years ago, tables were the main way web pages were created in HTML. It gave web builders consistent control of constructing pages with some “design.” No longer did sites only have to be top-to-bottom in a linear manner — they could be set up with columns that align left-to-right and top-to-bottom. Back then, it was seen as a huge breakthrough.

Tables, however, were never designed to lay out pages and, in fact, have all sorts of problems when used that way today. It was a convenient hack, but at the time, a very welcome one, particularly for those trying to achieve a super-specific layout that previous ways couldn’t handle.

Fast-forward to modern days and it’s now obvious that were tons of issues with the table layout approach. Accessibility is a big one.<table>, <th>, <tr> and <td> elements aren’t exactly accessible, especially when they’re nested several levels deep. Screen readers — the devices that read web content and serve as a measure of accessibility compliance — struggle to parse them into cohesive blocks of content. That’s not to say tables are bad; they simply were never intended as a layout mechanism.

Check out this table layout. Feel free to run it through VoiceOver or whatever screen reading software you have access to.

Yes, that example looks very much like a typical website layout, but it’s crafted solely with a table. You can see how quickly it becomes bloated and inaccessible the very moment we start using it for anything other than tabular data.

So after more than 20 years of being put through the ringer, you might think we should avoid tables altogether. If you’ve never shipped a table-based layout, you’ve undoubtedly heard war stories from those of us who have, and those stories are never kind. It’s like we’ve sort of made tables the “Internet Explorer of HTML elements.”

But that’s not totally fair because tables do indeed fill a purpose on the web and they are indeed accessible when they are used correctly.

Tables are designed to handle data that is semantically related and is best presented in a linear-like format. So, yes, we can use tables today in the year 2020, and that will likely continue to be true many years from now.

Here’s a table being used to display exactly what it’s intended to: tabular data!

With the push toward web standards in the early 2000s, tables were pushed aside as a layout solution in favor of other approaches, most notably the CSS float property. Designers and developers alike rejoiced because, for the first time, we had a true separation of concerns that let markup do the markup-y things it needs to do, and CSS to do the visual stuff it needs to do. That made code both cleaner and way easier to maintain and, as a result, we could actually focus on true standards, like accessibility, and even other practices, like SEO.

See (or rather hear) the difference in this example?

Many of us have worked with floats in the past. They were originally designed to allow content to flow around images that are floated either to the left or right, and still be in the document flow. Now that we’ve gotten newer layout features — again, like grid and flexbox — floats, too, have sort of fallen by the wayside, perhaps either because there are better ways to accomplish what they do, or because they also got the same bad rap as tables after being (ab)used for a long time.

But floats are still useful and relevant! In fact, we have to use them for the shape-outside property to work.

A legitimate float use case could be for wrapping content around a styled <blockquote>.

CSS features like grid, flexbox, and multicolumn layouts are among the wonderful tools we have to work with these days. With even more layout possibilities, cleaner and more accessible code, they will remain our go-to layout approaches for many years to come.

No hacks or extra code in this flexbox example of the same layout we’ve looked at throughout this article:


So, next time you find yourself considering tables or floats, reach for them with confidence! Well, when you know the situation aligns with their intended use. It’s not like I’m expecting you to walk away from this with a reinvigorated enthusiasm for tables and floats; only that, when used correctly, they are perfectly valid techniques, and even continue to be indispensable parts of our overall toolset.


The post In Defense of Tables and Floats in Modern Day Development appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , ,
[Top]

10 modern layouts in 1 line of CSS

, ,
[Top]

“The Modern Web”

A couple of interesting articles making the rounds:

I like Tom’s assertion that React (which he’s using as a stand-in for JavaScript frameworks in general) has an ideal usage:

There is a sweet spot of React: in moderately interactive interfaces. Complex forms that require immediate feedback, UIs that need to move around and react instantly. That’s where it excels.

If there is anything I hope for the world of web design and development, it’s that we get better at picking the right tools for the job.

I heard several people hone in on this:

I can, for example, guarantee that this blog is faster than any Gatsby blog (and much love to the Gatsby team) because there is nothing that a React static site can do that will make it faster than a non-React static site.

One reaction was hell yes. React is a bunch of JavaScript and it does lots of stuff, but does not grant superpowers that make the web faster than it was without it. Another reaction was: well it actually does. That’s kind of the whole point of SPAs: not needing to reload the page. Instead, we’re able to make a trimmed network request for the new data needed for a new page and re-rendering only what is necessary.

Rich digs into that even more:

When I tap on a link on Tom’s JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we have to wait for the response. With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and data for them. We can kick off requests as soon as the user first touches (or hovers) the link instead of waiting for confirmation of a tap — worst case scenario, we’ve loaded some stuff that will be useful later if they do tap on it. We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don’t need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page. This stuff gets fiendishly difficult to do by hand.

That’s what makes this stuff so easy to argue about. Everyone has good points. When we try to speak on behalf of the entire web, it’s tough for us all to agree. But the web is too big for broad, sweeping assertions.

Do people reach for React-powered SPAs too much? Probably, but that’s not without reason. There is innovation there that draws people in. The question is, how can we improve it?

From a front-of-the-front-end perspective, the fact that front-end frameworks like React encourage demand us write a front-end in components is compelling all by itself.

There is optimism and pessimism in both posts. The ending sentences of both are starkly different.

The post “The Modern Web” appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Avoid Heavy Babel Transformations by (Sometimes) Not Writing Modern JavaScript

It’s hard to imagine writing production-ready JavaScript without a tool like Babel. It’s been an undisputed game-changer in making modern code accessible to a wide range of users. With this challenge largely out of the way, there’s not much holding us back from really leaning into the features that modern specifications have to offer.

But at the same time, we don’t want to lean in too hard. If you take an occasional peek into the code your users are actually downloading, you’ll notice that sometimes, seemingly straightforward Babel transformations can be especially bloated and complex. And in a lot of those cases, you can perform the same task using a simple, “old school” approach — without the heavy baggage that can come from preprocessing.

Let’s take a closer look at what I’m talking about using Babel’s online REPL — a great tool for quickly testing transformations. Targeting browsers that don’t support ES2015+, we’ll use it to highlight just a few of the times when you (and your users) might be better off choosing an “old school” way to do something in JavaScript, despite a “new” approach popularized by modern specifications.

As we go along, keep in mind that this is less about “old vs. new” and more about choosing the best implementation that gets the job done while bypassing any expected side effects of our build processes.

Let’s build!

Preprocessing a for..of loop

The for..of loop is a flexible, modern means of looping over iterable collections. It’s often used in a way very similar to a traditional for loop, which may lead you to think that Babel’s transformation would be simple and predictable, especially if you’re just using it with an array. Not quite. The code we write may only be 98 bytes:

function getList() {   return [1, 2, 3]; }  for (let value of getList()) {   console.log(value); }

But the output results in 1.8kb (a 1736% increase!):

 "use strict";  function _createForOfIteratorHelper(o) { if (typeof Symbol === "undefined" || o[Symbol.iterator] == null) { if (Array.isArray(o) || (o = _unsupportedIterableToArray(o))) { var i = 0; var F = function F() {}; return { s: F, n: function n() { if (i >= o.length) return { done: true }; return { done: false, value: o[i++] }; }, e: function e(_e) { throw _e; }, f: F }; } throw new TypeError("Invalid attempt to iterate non-iterable instance.\nIn order to be iterable, non-array objects must have a [Symbol.iterator]() method."); } var it, normalCompletion = true, didErr = false, err; return { s: function s() { it = o[Symbol.iterator](); }, n: function n() { var step = it.next(); normalCompletion = step.done; return step; }, e: function e(_e2) { didErr = true; err = _e2; }, f: function f() { try { if (!normalCompletion && it.return != null) it.return(); } finally { if (didErr) throw err; } } }; }  function _unsupportedIterableToArray(o, minLen) { if (!o) return; if (typeof o === "string") return _arrayLikeToArray(o, minLen); var n = Object.prototype.toString.call(o).slice(8, -1); if (n === "Object" && o.constructor) n = o.constructor.name; if (n === "Map" || n === "Set") return Array.from(o); if (n === "Arguments" || /^(?:Ui|I)nt(?:8|16|32)(?:Clamped)?Array$  /.test(n)) return _arrayLikeToArray(o, minLen); }  function _arrayLikeToArray(arr, len) { if (len == null || len > arr.length) len = arr.length; for (var i = 0, arr2 = new Array(len); i < len; i++) { arr2[i] = arr[i]; } return arr2; }  function getList() {   return [1, 2, 3]; }  var _iterator = _createForOfIteratorHelper(getList()),     _step;  try {   for (_iterator.s(); !(_step = _iterator.n()).done;) {     var value = _step.value;     console.log(value);   } } catch (err) {   _iterator.e(err); } finally {   _iterator.f(); }

Why didn’t it just use for loop for this? It’s an array! Apparently, in this case, Babel doesn’t know it’s handling an array. All it knows is that it’s working with a function that could return any iterable (array, string, NodeList), and it needs to be ready for whatever that value could be, based on the ECMAScript specification for the for..of loop.

We could drastically slim the transformation by explicitly passing an array to it, but that’s not always easy in a real application. So, to leverage the benefits of loops (like break and continue statements), while confidently keeping bundle size slim, we might just reach for the for loop. Sure, it’s old school, but it gets the job done.

function getList() {   return [1, 2, 3]; } 
 for (var i = 0; i < getList().length; i++) {   console.log(value); }

/explanation Dave Rupert blogged about this exact situation a few years ago and found that forEach, even polyfilled, as a good solution for him.

Preprocessing Array […Spread]

Similar deal here. The spread operator can be used with more than one class of objects (not just arrays), so when Babel isn’t aware of the type of data it’s dealing with, it needs to take precautions. Unfortunately, those precautions can result in some serious byte bloat.

Here’s the input, weighing in at a slim 81 bytes:

function getList () {   return [4, 5, 6]; } 
 console.log([1, 2, 3, ...getList()]);

The output balloons to 1.3kb:

"use strict";  function _toConsumableArray(arr) { return _arrayWithoutHoles(arr) || _iterableToArray(arr) || _unsupportedIterableToArray(arr) || _nonIterableSpread(); }  function _nonIterableSpread() { throw new TypeError("Invalid attempt to spread non-iterable instance.\nIn order to be iterable, non-array objects must have a [Symbol.iterator]() method."); }  function _unsupportedIterableToArray(o, minLen) { if (!o) return; if (typeof o === "string") return _arrayLikeToArray(o, minLen); var n = Object.prototype.toString.call(o).slice(8, -1); if (n === "Object" && o.constructor) n = o.constructor.name; if (n === "Map" || n === "Set") return Array.from(o); if (n === "Arguments" || /^(?:Ui|I)nt(?:8|16|32)(?:Clamped)?Array$  /.test(n)) return _arrayLikeToArray(o, minLen); }  function _iterableToArray(iter) { if (typeof Symbol !== "undefined" && Symbol.iterator in Object(iter)) return Array.from(iter); }  function _arrayWithoutHoles(arr) { if (Array.isArray(arr)) return _arrayLikeToArray(arr); }  function _arrayLikeToArray(arr, len) { if (len == null || len > arr.length) len = arr.length; for (var i = 0, arr2 = new Array(len); i < len; i++) { arr2[i] = arr[i]; } return arr2; }  function getList() {   return [4, 5, 6]; }  console.log([1, 2, 3].concat(_toConsumableArray(getList())));

Instead, we could cut to the chase and and just use concat(). The difference in the amount of code you need to write isn’t significant, it does exactly what it’s intended to do, and there’s no need to worry about that extra bloat.

function getList () {   return [4, 5, 6]; } 
 console.log([1, 2, 3].concat(getList()));

A more common example: Looping over a NodeList

You might have seen this more than a few times. We often need to query for several DOM elements and loop over the resulting NodeList. In order to use forEach on that collection, it’s common to spread it into an array.

[...document.querySelectorAll('.my-class')].forEach(function (node) {   // do something });

But like we saw, this makes for some heavy output. As an alternative, there’s nothing wrong with running that NodeList through a method on the Array prototype, like slice. Same result, but far less baggage:

[].slice.call(document.querySelectorAll('.my-class')).forEach(function(node) {   // do something });

A note about “loose” mode

It’s worth calling out that some of this array-related bloat can also be avoided by leveraging @babel/preset-env‘s loose mode, which compromises in staying totally true to the semantics of modern ECMAScript, but offers the benefit of slimmer output. In many situations, that might work just fine, but you’re also necessarily introducing risk into your application that you may come to regret later on. After all, you’re telling Babel to make some rather bold assumptions about how you’re using your code. 

The main takeaway here is that sometimes, it might be more suitable to be more intentional about the features you to use, rather than investing more time into tweaking your build process and potentially wrestling with unseen consequences later.

Preprocessing default parameters

This is a more predictable operation, but when it’s repeatedly used throughout a codebase, the bytes can add up. ES2015 introduced default parameter values, which tidy up a function’s signature when it accepts optional arguments. Here we are at 75 bytes:

function getName(name = "my friend") {   return `Hello, $  {name}!`; }

But Babel can be a little more verbose than expected with its transformation, resulting in 169 bytes:

"use strict"; 
 function getName() {   var name = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : "my friend";   return "Hello, ".concat(name, "!"); }

As an alternative, we could avoid using the arguments object altogether, and simply check if a parameter is undefined We lose the self-documenting nature that default parameters provide, but if we’re really pinching bytes, it might be worth it. And depending on the use case, we might even be able to get away with checking for falsey to slim it down even more.

function getName(name) {   name = name || "my friend";   return `Hello, $  {name}!`; }

Preprocessing async/await

The syntactic sugar of async/await over the Promise API is one of my favorite additions to JavaScript. Even so, out of the box, Babel can make make quite the mess out of it.

157 bytes to write:

async function fetchSomething(url) {   const response = await fetch(url);   return await response.json(); }  fetchSomething("https://google.com");

1.5kb when compiled:

"use strict";  function asyncGeneratorStep(gen, resolve, reject, _next, _throw, key, arg) { try { var info = gen[key](arg); var value = info.value; } catch (error) { reject(error); return; } if (info.done) { resolve(value); } else { Promise.resolve(value).then(_next, _throw); } }  function _asyncToGenerator(fn) { return function () { var self = this, args = arguments; return new Promise(function (resolve, reject) { var gen = fn.apply(self, args); function _next(value) { asyncGeneratorStep(gen, resolve, reject, _next, _throw, "next", value); } function _throw(err) { asyncGeneratorStep(gen, resolve, reject, _next, _throw, "throw", err); } _next(undefined); }); }; }  function fetchSomething(_x) {   return _fetchSomething.apply(this, arguments); }  function _fetchSomething() {   _fetchSomething = _asyncToGenerator( /*#__PURE__*/regeneratorRuntime.mark(function _callee(url) {     var response;     return regeneratorRuntime.wrap(function _callee$  (_context) {       while (1) {         switch (_context.prev = _context.next) {           case 0:             _context.next = 2;             return fetch(url);            case 2:             response = _context.sent;             _context.next = 5;             return response.json();            case 5:             return _context.abrupt("return", _context.sent);            case 6:           case "end":             return _context.stop();         }       }     }, _callee);   }));   return _fetchSomething.apply(this, arguments); }  fetchSomething("https://google.com");

You’ll notice that Babel doesn’t convert async code into promises out of the box. Instead, they’re transformed into generators that rely on the regenerator-runtime library, making for more a lot more code than what’s written in our IDE. Thankfully, it’s possible to go the Promise route by means of a plugin, like babel-plugin-transform-async-to-promises. Instead of that 1.5kb output, we end up with much less, at 638 bytes:

"use strict"; 
 function _await(value, then, direct) {   if (direct) {     return then ? then(value) : value;   } 
   if (!value || !value.then) {     value = Promise.resolve(value);   } 
   return then ? value.then(then) : value; } 
 var fetchSomething = _async(function (url) {   return _await(fetch(url), function (response) {     return _await(response.json());   }); }); 
 function _async(f) {   return function () {     for (var args = [], i = 0; i < arguments.length; i++) {       args[i] = arguments[i];     } 
     try {       return Promise.resolve(f.apply(this, args));     } catch (e) {       return Promise.reject(e);     }   }; }

But, like mentioned before, there’s risk in relying on a plugin to ease pain like this. When doing so, we’re impacting transformations in the entire project, and also introducing another build dependency. Instead, we could consider just sticking with the Promise API.

function fetchSomething(url) {   return new Promise(function (resolve) {     fetch(url).then(function (response) {       return response.json();     }).then(function (data) {       return resolve(data);     });   }); }

Preprocessing classes

For more syntactic sugar, there’s the class syntax introduced with ES2015, which provides a streamlined way to leverage JavaScript’s prototypical inheritance. But if we’re using Babel to transpile for older browsers, there’s nothing sweet about the output.

The input us only 120 bytes:

class Robot {   constructor(name) {     this.name = name;   } 
   speak() {      console.log(`I'm $  {this.name}!`);   } }

But the output results in 989kb:

"use strict";  function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }  function _defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if ("value" in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } }  function _createClass(Constructor, protoProps, staticProps) { if (protoProps) _defineProperties(Constructor.prototype, protoProps); if (staticProps) _defineProperties(Constructor, staticProps); return Constructor; }  var Robot = /*#__PURE__*/function () {   function Robot(name) {     _classCallCheck(this, Robot);      this.name = name;   }    _createClass(Robot, [{     key: "speak",     value: function speak() {       console.log("I'm ".concat(this.name, "!"));     }   }]);    return Robot; }();

Much of the time, unless you’re doing some fairly involved inheritance, it’s straightforward enough to use a pseudoclassical approach. It requires slightly less code to write, and the resulting interface is virtually identical to a class.

function Robot(name) {   this.name = name; 
   this.speak = function() {     console.log(`I'm $  {this.name}!`);   } } 
 const rob = new Robot("Bob"); rob.speak(); // "Bob"

Strategic considerations

Keep in mind that, depending on your application’s audience, a lot of what you’re reading here might mean that your strategies to keep bundles slim may take different shapes.

For example, your team might have already made a deliberate decision to drop support for Internet Explorer and other “legacy” browsers (which is becoming more and more common, given that the vast majority of browsers support ES2015+). If that’s the case, your time might best be spent in auditing the list of browsers your build system is targeting, or making sure you’re not shipping unnecessary polyfills.

And even if you are still obligated to support older browsers (or maybe you love some of the modern APIs too much to give them up), there are other options to enable you to ship heavy, preprocessed bundles only to the users that need them, like a differential serving implementation.

The important thing isn’t so much about which strategy (or strategies) your team chooses to prioritize, but more about intentionally making those decisions in light of the code being spit out by your build system. And that all starts by cracking open that dist directory to take a peak.

Pop open that hood

I’m a big fan of the new features modern JavaScript continues to provide. They make for applications that are easier to write, maintain, scale, and especially read. But as long as writing JavaScript means preprocessing JavaScript, it’s important to make sure that we have a finger on the pulse of what these features mean for the users that we ultimately aim to serve.

And that means popping the hood of your build process once in a while. At best, you might be able avoid especially hefty Babel transformations by using a simpler, “classic” alternative. And at worst, you’ll come to better understand (and appreciate) the work that Babel does all the more.

The post Avoid Heavy Babel Transformations by (Sometimes) Not Writing Modern JavaScript appeared first on CSS-Tricks.

CSS-Tricks

, , , , , , ,
[Top]

Modern CSS Solutions for Old CSS Problems

This is a hell of a series by Stephanie Eckles. It’s a real pleasure watching CSS evolve and solve problems in clear and elegant ways.

Just today I ran across this little jab at CSS in a StackOverflow answer from 2013.

Typical CSS. They provide CSS animations so it's not done in Javascript, and the styling is all in one place, but then if you want to do anything more than the bare basics then you have to implement a maze of hacks. Why don't they just implement things that make it easier for developers? – Jonathan. Aug 23 '13 at 13:52

This particular jab was about CSS lacking a way to pause between @keyframe animations, which is still not something CSS can do without hacks. Aside from hand-wavy and ignorable “CSS is bad” statements, I see a lot less of this. CSS is just getting better.

Direct Link to ArticlePermalink

The post Modern CSS Solutions for Old CSS Problems appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

The Unseen Performance Costs of Modern CSS-in-JS Libraries

This article is full of a bunch of data from Aggelos Arvanitakis. But lemme just focus on his final bit of advice:

Investigate whether a zero-runtime CSS-in-JS library can work for your project. Sometimes we tend to prefer writing CSS in JS for the DX (developer experience) it offers, without a need to have access to an extended JS API. If you app doesn’t need support for theming and doesn’t make heavy and complex use of the css prop, then a zero-runtime CSS-in-JS library might be a good candidate.

“Zero-runtime” meaning you author your styles in a CSS-in-JS syntax, but what is produced is .css files like any other CSS preprocessor would produce. This shifts the tool into a totally different category. It’s a developer tool only, rather than a tool where the user of the website pays the price of using it.

The flagship zero-runtime CSS-in-JS library is Linaria. I think the syntax looks really nice.

import { css } from 'linaria'; import fonts from './fonts';  const header = css`   text-transform: uppercase;   font-family: $  {fonts.heading}; `;  <h1 className={header}>Hello world</h1>;

I’m also a fan of the just do scoping for me ability that CSS modules brings, which can be done zero-runtime style.

Direct Link to ArticlePermalink

The post The Unseen Performance Costs of Modern CSS-in-JS Libraries appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

Custom Styling Form Inputs With Modern CSS Features

It’s entirely possible to build custom checkboxes, radio buttons, and toggle switches these days, while staying semantic and accessible. We don’t even need a single line of JavaScript or extra HTML elements! It’s actually gotten easier lately than it has been in the past. Let’s take a look.

Here’s where we’ll end up:

Things sure have gotten easier than they were!

The reason is that we can finally style the ::before and ::after pseudo-elements on the <input> tag itself. This means we can keep and style an <input> and won’t need any extra elements. Before, we had to rely on the likes of an extra <div> or <span>, to pull off a custom design.

Let’s look at the HTML

Nothing special here. We can style our inputs with just this HTML:

<!-- Checkbox --> <input type="checkbox">  <!-- Radio --> <input type="radio">  <!-- Switch --> <input type="checkbox" class="switch">

That’s it for the HTML part, but of course it’s recommended to have name and id attributes, plus a matching <label> element:

<!-- Checkbox --> <input type="checkbox" name="c1" id="c1"> <label for="c1">Checkbox</label>  <!-- Radio --> <input type="radio" name="r1" id="r1"> <label for="r1">Radio</label>  <!-- Switch --> <input type="checkbox" class="switch" name="s1" id="s1"> <label for="s1">Switch</label>

Getting into the styling 

First of all, we check for the support of appearance: none;, including it’s prefixed companions. The appearance property is key because it is designed to remove a browser’s default styling from an element. If the property isn’t supported, the styles won’t apply and default input styles will be shown. That’s perfectly fine and a good example of progressive enhancement at play.

@supports(-webkit-appearance: none) or (-moz-appearance: none) {   input[type='checkbox'],   input[type='radio'] {     -webkit-appearance: none;     -moz-appearance: none;   } }

As it stands today, appearance  is a working draft, but here’s what support looks like:

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Firefox IE Edge Safari
82* 74* No 79* TP*

Mobile / Tablet

Android Chrome Android Firefox Android iOS Safari
79* 68* 76* 13.3*

Like links, we’ve gotta consider different interactive states with form elements. We’ll consider these when styling our elements:

  • :checked
  • :hover
  • :focus
  • :disabled

For example, here’s how we can style our toggle input, create the knob, and account for the :checked state:

/* The toggle container */ .switch {   width: 38px;   border-radius: 11px; }  /* The toggle knob */ .switch::after {   left: 2px;   top: 2px;   border-radius: 50%;   width: 15px;   height: 15px;   background: var(--ab, var(--border));   transform: translateX(var(--x, 0)); }  /* Change color and position when checked */ .switch:checked {   --ab: var(--active-inner);   --x: 17px; }  /* Drop the opacity of the toggle knob when the input is disabled */ .switch:disabled:not(:checked)::after {   opacity: .6; }

We are using the <input> element like a container. The knob inside of the input is created with the ::after pseudo-element. Again, no more need for extra markup!

If you crack open the styles in the demo, you’ll see that we’re defining some CSS custom properties because that’s become such a nice way to manage reusable values in a stylesheet:

@supports(-webkit-appearance: none) or (-moz-appearance: none) {   input[type='checkbox'],   input[type='radio'] {     --active: #275EFE;     --active-inner: #fff;     --focus: 2px rgba(39, 94, 254, .25);     --border: #BBC1E1;     --border-hover: #275EFE;     --background: #fff;     --disabled: #F6F8FF;     --disabled-inner: #E1E6F9;   } }

But there’s another reason we’re using custom properties — they work well for updating values based on the state of the element! We won’t go into full detail here, but here’s an example how we can use custom properties for different states.

/* Default */ input[type='checkbox'], input[type='radio'] {   --active: #275EFE;   --border: #BBC1E1;   border: 1px solid var(--bc, var(--border)); }  /* Override defaults */ input[type='checkbox']:checked, input[type='radio']:checked {   --b: var(--active);   --bc: var(--active); }    /* Apply another border color on hover if not checked & not disabled */ input[type='checkbox']:not(:checked):not(:disabled):hover, input[type='radio']:not(:checked):not(:disabled):hover {   --bc: var(--border-hover); }

For accessibility, we ought to add a custom focus style. We are removing the default outline because it can’t be rounded like the rest of the things we’re styling. But a border-radius along with a box-shadow can make for a rounded style that works just like an outline.

input[type='checkbox'], input[type='radio'] {   --focus: 2px rgba(39, 94, 254, .25);   outline: none;   transition: box-shadow .2s; }  input[type='checkbox']:focus, input[type='radio']:focus {   box-shadow: 0 0 0 var(--focus); }

It’s also possible to align and style the <label> element which directly follows the <input> element in the HTML:

<input type="checkbox" name="c1" id="c1"> <label for="c1">Checkbox</label>
input[type='checkbox'] + label, input[type='radio'] + label {   display: inline-block;   vertical-align: top;   /* Additional styling */ }  input[type='checkbox']:disabled + label, input[type='radio']:disabled + label {     cursor: not-allowed; }

Here’s that demo again:

Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to @supports.

All in all, this is a much more pleasant developer experience than we’ve had to deal with in the past!

The post Custom Styling Form Inputs With Modern CSS Features appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

The Modern Lovers

I love stuff like this.

  1. The Modern Lovers, a rock band in the 70’s, play a show in Boston, probably having some poster of their own for the show.
  2. Mike Joyce is inspired by the music and combines his love of it with the design style of Swiss Modernism to create a new poster for it.
  3. Pete Barr is inspired by Mike’s Swissted project and animates the design for it, giving it a ton of new life.

This is what makes the internet cool. I’d bet none of these people have ever met each other.

And this is just one example. Mike has designed hundreds of these posters, and Pete has animated a number of them. Here’s another lovely example.

The post The Modern Lovers appeared first on CSS-Tricks.

CSS-Tricks

,
[Top]

CSS Architecture for Modern JavaScript Applications

There is a lot to like from Mike Riethmuller here:

  • The title. When you’re building a website from JavaScript-powered components anyway, that is a moment to talk about how to do styling, because it opens some doors to JavaScript-powered styles that you probably wouldn’t otherwise choose.
  • The personal experience and pragmatism. Drawing on five years of consulting, he’s seeing that component re-use and style understandability is suffering, not improving, partly due to every team having different approaches. He says “it’s a little bit of everybody’s fault” and sees the perspective of others who like parts of what JavaScript-powered styles can bring, like less dependence on specificity.
  • The fresh thinking. Since JavaScript-powered websites are all built by nested components anyway, why not use that architecture for styling? The thesis of the article is really about building UI components that, on purpose, don’t involve application logic but exist just for styling, and using a combination of clever CSS and JavaScript power to the kind of styling you need.

Direct Link to ArticlePermalink

The post CSS Architecture for Modern JavaScript Applications appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]