References

CSS Ruleset Terminology

An inforgraphic demonstrating the various parts of a CSS rule and their names. See the text following this image for more information.

If you ever wanted a mini-cheat sheet for what every part of a CSS rule is called, here it is:

  • The whole thing is a ruleset.
  • The curly braces and everything inside is a declaration block.
  • The bit before the opening curly brace is a selector.
  • Each key/value pair, as separated by a colon and ending in a semicolon, is a declaration.
  • In those key/value pairs, the key is a property (or property name), and the value is a value (or property value).

Tags: 

Clean Code: JavaScript

This is excellent and you should read it all.

Software engineering principles, from Robert C. Martin’s book Clean Code, adapted for JavaScript. This is not a style guide. It’s a guide to producing readable, reusable, and refactorable software in JavaScript.

Not every principle herein has to be strictly followed, and even fewer will be universally agreed upon. These are guidelines and nothing more, but they are ones codified over many years of collective experience by the authors of Clean Code.

Our craft of software engineering is just a bit over 50 years old, and we are still learning a lot. When software architecture is as old as architecture itself, maybe then we will have harder rules to follow. For now, let these guidelines serve as a touchstone by which to assess the quality of the JavaScript code that you and your team produce.

One more thing: knowing these won’t immediately make you a better software developer, and working with them for many years doesn’t mean you won’t make mistakes. Every piece of code starts as a first draft, like wet clay getting shaped into its final form. Finally, we chisel away the imperfections when we review it with our peers. Don’t beat yourself up for first drafts that need improvement. Beat up the code instead!

Tags: 

Hiding DOM elements - ally.js

This document explains the various ways of hiding things and the implications that come with that.

When we say an element is hidden, we usually mean it is not visible. However, the screen is not the only output mechanism we may need to hide content from. Systems like screen readers and braille displays rely on a document’s representation in the accessibility tree. For disambiguation we’ll use the following terms:

Completely hidden
The element is not rendered on screen, not exposed in the accessibility tree, not accessible to keyboard navigation.
Semantically hidden
The element is rendered on screen, but not exposed in the accessibility tree, and still accessible to keyboard navigation.
Visually hidden
The element is not rendered on screen, but exposed in the accessibility tree, and still accessible to keyboard navigation.

[…]

How to hide elements completely

Completely hiding elements can be done in 3 ways:

  • via the CSS property display, e.g. display: none;
  • via the CSS property visibility, e.g. visibility: hidden;
  • via the HTML5 attribute hidden, e.g. <span hidden>

While each of these techniques has the same end result, i.e. content is not rendered and not exposed in the accessibility tree, they have different behaviors.

[…]

How to hide elements semantically

To hide content from the accessibility tree but retain the content on screen, we may use the attribute aria-hidden="true".

[…]

2016 edition of .visuallyhidden

[…]

CSS

.visuallyhidden:not(:focus):not(:active) {
  position: absolute;
 
  width: 1px;
  height: 1px;
  margin: -1px;
  border: 0;
  padding: 0;
 
  clip-path: inset(100%);
  clip: rect(0 0 0 0);
  overflow: hidden;
}
  • It works in all modern browsers including Internet Explorer 9 - 11.
  • It side-steps the need to re-style everything for focusable elements such as skip-links.
  • It accounts for the deprecated clip property.

Keyboard navigation

The techniques to hide elements only visually or semantically come with a caveat. Focusable elements like <a href="…"> remain keyboard navigatable, even though the element is not visible on screen or not exposed in the accessibility tree.

To make sure sighted keyboard users do not end up focusing elements they can’t see, and screen reader users not focusing element’s that don’t exist for them, we need to make sure that partially hidden content is not accessible to keyboard navigation using the Tab and Shift Tab keys. To accomplish this, we can add tabindex="-1" to the elements we want to hide from the keyboard.

Recap

  • Use the hidden attribute to completely hide an element.
  • Use the aria-hidden attribute to hide an element from the accessibility tree.
  • Use the .visuallyhidden class to hide an element from the screen.
  • Use visibility: inherit; instead of visibility: visible; to avoid accidentally showing content.
  • Do not attach any CSS styles to the aria-hidden attribute.
  • Take care of keyboard focusable content that is partially hidden by adding tabindex="-1".

Tags: 

Front-End Performance Checklist 2017

This is an incredibly exhaustive list of performance tweaks, improvements, and best practices. Some may be outside the scope of smaller websites, but there are plenty of things for everyone.

Back in the day, performance was often a mere afterthought. Often deferred till the very end of the project, it would boil down to minification, concatenation, asset optimization and potentially a few fine adjustments on the server’s config file. Looking back now, things seem to have changed quite significantly.

Performance isn’t just a technical concern: It matters, and when baking it into the workflow, design decisions have to be informed by their performance implications. Performance has to be measured, monitored and refined continually, and the growing complexity of the web poses new challenges that make it hard to keep track of metrics, because metrics will vary significantly depending on the device, browser, protocol, network type and latency (CDNs, ISPs, caches, proxies, firewalls, load balancers and servers all play a role in performance).

So, if we created an overview of all the things we have to keep in mind when improving performance — from the very start of the process until the final release of the website — what would that list look like? Below you’ll find a (hopefully unbiased and objective) front-end performance checklist for 2017 — an overview of the issues you might need to consider to ensure that your response times are fast and your website smooth.

Tags: 

Pages