Tag: good

The Many Bad (and Good!) Patterns for Close Buttons

Manuel Matuzović details 10 bad HTML patterns for a close button. You know, stuff like this:

<a class="close" onclick="close()">×</a>

Why is that bad? There is no href there, so it really isn’t a link (close buttons aren’t links). Not to mention the missing href makes this “placeholder link” unfocusable. Plus, that symbol will be read as “multiplication” or “times”, which is not helpful (an “x” isn’t either).

What do you use instead?

There are plenty of good patterns too. If you prefer the visual look of a ×, then…

<button type="button">   <span class="sr-only">Close</span>   <span aria-hidden="true">×</span> </button>

…making sure you are accessibly hiding that close button.

Direct Link to ArticlePermalink

The post The Many Bad (and Good!) Patterns for Close Buttons appeared first on CSS-Tricks.

CSS-Tricks

, , , ,

How (some) good corporate engineering blogs are written

Interesting research from Dan Luu:

… it’s pretty common for my personal blog to get more traffic than the entire corp eng blog for a company with a nine to ten figure valuation and it’s not uncommon for my blog to get an order of magnitude more traffic.

I think this is odd because tech companies in that class often have hundreds to thousands of employees. They’re overwhelmingly likely to be better equipped to write a compelling blog than I am and companies get a lot more value from having a compelling blog than I do.

First, yes. There is a crapload of value in having a good blog (top of funnel traffic, showcasing culture for hiring, establishing industry leadership…) yet so few companies do it well even when they have more than enough resources to do so.

Dan doesn’t just speculate on this, he interviewed people at companies that have actually good engineering blogs: Heap, Segment, and Cloudflare. Then he listed their internal process for blogging. The first step in all three is the same: “Someone has an idea to write a post”. That makes sense, but I would think there is something deeper going on with good blogs: engineers that want to come up with ideas because it is encouraged and incentivized. And then after the ball is rolling, there is a positive feedback loop and as few blockers as possible.

Random observations from me:

  • We recently started using Appcues at CodePen, and it was on our radar at all because people at CodePen read their blog and liked it.
  • While Appcues largely blogs about stuff that is directly related to stuff their software can help with, Logrocket, a software product for tracking JavaScript errors, has a blog that isn’t terribly different than CSS-Tricks. It’s just about front-end everything and every single blog post has a section in it that is a pitch for the product. Looks like they’ve been doing it for about 3 years now, so my hunch is that it works extremely well.
  • All the browser vendors to a pretty good job of blogging overall, but at the same time, feel a bit disjointed. What blog(s) should I be reading for Mozilla/Firefox stuff? I don’t know really. Is it the official looking one? Or the “hacks” one? Or the planet one? Or nightly one? Or the one for releases? Google seems to have the same problem. There isn’t an obvious hub of writing.
  • Stripe has a strong engineering blog, but then take it to another level by producing a fancy publication (Increment) that is both online and in print.

Direct Link to ArticlePermalink

The post How (some) good corporate engineering blogs are written appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

The New Good Ol’ Days

Eighteen years into this game, I love to reminisce back to the good ol’ days of the early to mid-2000s when there was an explosion of creativity on the web. It felt fresh and unbridled, with boundaries expected to be pushed at every turn, and they were. This was mainly down to one thing, the thing of nightmares to some, Flash! It, of course, had some big inherent flaws, but love it or hate it, certainly helped pave the way for what we expected from the open web. Sure, it was probably a more drawn-out process than we’d hoped for, but with some savage new advancements made over the last few years, I now feel that things are really starting to get proper juicy.

Several things come to mind that get me excited these days in designing and developing for the web, some widely adopted now like SVG (even though technically old) and WebGL animation, which draw some obvious parallels to the Flash era. Certainly, CSS Grid stood up and made itself known, shouting from the parapets about how the shackles of layout are now a thing of the past. Kudos to awesome people like Rachel Andrew and Jen Simmons for their serious efforts in educating us mere mortals in this area, helping make the learning curve and adoption that bit more palatable and accessible.

Looking around today you can see how advancements like Grid have helped elevate the rise of more asymmetric layouts, with design styles like Brutalism design going through a bit of a trend over the last year or so. But over time it felt as though typography might have taken the back seat a tad with all the other successes happening in pushing the web forward. Now enter variable fonts 🥳

Variable fonts have certainly piqued my interest this past year or so. Not only do they give us the obvious boost in performance with fewer https requests and smaller sizes compared to the bundles of web fonts we all inject into our pages, but we also gain more control over typography in terms of readability and accessibility. Say goodbye to cheekily adding muddy sacrificial faux bold or italic styles to our CSS!

Taking this further, I feel that variable fonts have really unlocked the door to new creative possibilities that we’re only just scratching the surface of. Having the ability to interpolate between different values of the axes just screams out for animation. We have the standardized set of 5 registered axes like font-weight, font-stretch, font-style, etc. which are straight forward enough to appreciate, but when it comes to custom axes via font-variation-settings, things start getting crazy and fun. Type designers can use the interpolation in custom axes to create some really off the wall things beyond, well… text. Just check out Typearture’s fab variable font experiments to see what I mean.

A few months back I was privileged to be invited to experiment with and test Greensock’s newly released GSAP 3, which I’m also most definitely excited about. It boasts a new simplified API and 50+ new features, yet is only about half the file size as the previous version. This is currently my catnip though: layering GSAP on top of variable fonts in CodePen to create some lovely kinetic typography in the DOM. This kind of magic, until now I guess, has been more attributed to WebGL, Processing and After Effects. Now, throw some GSAP plugins on top again, and you can definitely create some very cool and unique stuff. I would suggest, however, that you use this new creative power of animating variable fonts in whichever way you do it sparingly, as reflow could become an issue with jank.

I’m excited to see what people will create using variable fonts over the next year as it becomes more widely adopted. Not just limited to typographic treatments in layouts, but also in terms of animation and micro-interactions. It looks like a big undertaking for designers in creating such fonts, but credit to them. I’m sure we’ll be all the more appreciative. Thanks in advance type designers!

The post The New Good Ol’ Days appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

Breaking CSS Custom Properties out of :root Might Be a Good Idea

CSS Custom Properties have been a hot topic for a while now, with tons of great articles about them, from great primers on how they work to creative tutorials to do some real magic with them. If you’ve read more than one or two articles on the topic, then I’m sure you’ve noticed that they start by setting up the custom properties on the :root about 99% of the time.

While putting custom properties on the :root is great for things that you need to be available throughout your site, there are times when it makes more sense to scope your custom properties locally.

In this article, we’ll be exploring:

  • Why we put custom properties on the :root to begin with.
  • Why global scoping isn’t right for everything.
  • How to overcome class clashing with locally scoped custom properties

What’s the deal with custom properties and :root?

Before we jump into looking at the global scope, I think it’s worth looking at why everyone sets custom properties in the :root to begin with.

I’ve been declaring custom properties on the :root without even a second thought. Pretty much everyone does it without even a mention of why — including the official specification.

When the subject of :root is actually breached, it mentions how :root is the same as html, but with higher specificity, and that’s about it.

But does that higher specificity really matter?

Not really. All it does is select html with a higher specificity, the same way a class selector has higher specificity than an element selector when selecting a div.

:root {   --color: red; }  html {   --color: blue; }  .example {   background: var(--color);   /* Will be red because of :root's higher specificity */ }

The main reason that :root is suggested is because CSS isn’t only used to style HTML documents. It is also used for XML and SVG files.

In the case of XML and SVG files, :root isn’t selecting the html element, but rather their root (such as the svg tag in an SVG file).

Because of this, the best practice for a globally-scoped custom property is the :root. But if you’re making a website, you can throw it on an html selector and not notice a difference.

That said, with everyone using :root, it has quickly become a “standard.” It also helps separate variables to be used later on from selectors which are actively styling the document.

Why global scope isn’t right for everything

With CSS pre-processors, like Sass and Less, most of us keep variables tucked away in a partial dedicated to them. That works great, so why should we consider locally scoping variables all of a sudden?

One reason is that some people might find themselves doing something like this.

:root {   --clr-light: #ededed;   --clr-dark: #333;   --clr-accent: #EFF;   --ff-heading: 'Roboto', sans-serif;   --ff-body: 'Merriweather', serif;   --fw-heading: 700;   --fw-body: 300;   --fs-h1: 5rem;   --fs-h2: 3.25rem;   --fs-h3: 2.75rem;   --fs-h4: 1.75rem;   --fs-body: 1.125rem;   --line-height: 1.55;   --font-color: var(--clr-light);   --navbar-bg-color: var(--clr-dark);   --navbar-logo-color: var(--clr-accent);   --navbar-border: thin var(--clr-accent) solid;   --navbar-font-size: .8rem;   --header-color: var(--clr-accent);   --header-shadow: 2px 3px 4px rgba(200,200,0,.25);   --pullquote-border: 5px solid var(--clr-light);   --link-fg: var(--clr-dark);   --link-bg: var(--clr-light);   --link-fg-hover: var(--clr-dark);   --link-bg-hover: var(--clr-accent);   --transition: 250ms ease-out;   --shadow: 2px 5px 20px rgba(0, 0, 0, .2);   --gradient: linear-gradient(60deg, red, green, blue, yellow);   --button-small: .75rem;   --button-default: 1rem;   --button-large: 1.5rem; }

Sure, this gives us one place where we can manage styling with custom properties. But, why do we need to define my --header-color or --header-shadow in my :root? These aren’t global properties, I’m clearly using them in my header and no where else.

If it’s not a global property, why define it globally? That’s where local scoping comes into play.

Locally scoped properties in action

Let’s say we have a list to style, but our site is using an icon system — let’s say Font Awesome for simplicity’s sake. We don’t want to use the disc for our ul bullets — we want a custom icon!

If I want to switch out the bullets of an unordered list for Font Awesome icons, we can do something like this:

ul {   list-style: none; }  li::before {   content: "\f14a"; /* checkbox */   font-family: "Font Awesome Free 5";   font-weight: 900;   float: left;   margin-left: -1.5em; }

While that’s super easy to do, one of the problems is that the icon becomes abstract. Unless we use Font Awesome a lot, we aren’t going to know that f14a means, let alone be able to identify it as a checkbox icon. It’s semantically meaningless.

We can help clarify things with a custom property here.

ul {   --checkbox-icon: "\f14a";   list-style: none; }

This becomes a lot more practical once we start having a few different icons in play. Let’s up the complexity and say we have three different lists:

<ul class="icon-list checkbox-list"> ... </ul>  <ul class="icon-list star-list"> ... </ul>  <ul class="icon-list bolt-list"> ... </ul>

Then, in our CSS, we can create the custom properties for our different icons:

.icon-list {   --checkbox: "\f14a";   --star: "\f005";   --bolt: "\f0e7";    list-style: none; }

The real power of having locally scoped custom properties comes when we want to actually apply the icons.

We can set content: var(--icon) on our list items:

.icon-list li::before {   content: var(--icon);   font-family: "Font Awesome Free 5";   font-weight: 900;   float: left;   margin-left: -1.5em; }

Then we can define that icon for each one of our lists with more meaningful naming:

.checkbox-list {   --icon: var(--checkbox); }  .star-list {   --icon: var(--star); }  .bolt-list {   --icon: var(--bolt); }

We can step this up a notch by adding colors to the mix:

.icon-list li::before {   content: var(--icon);   color: var(--icon-color);   /* Other styles */ }

Moving icons to the global scope

If we’re working with an icon system, like Font Awesome, then I’m going to assume that we’d be using them for more than just replacing the bullets in unordered lists. As long as we’re using them in more than one place it makes sense to move the icons to the :root as we want them to be available globally.

Having icons in the :root doesn’t mean we can’t still take advantage of locally scoped custom properties, though!

:root {   --checkbox: "\f14a";   --star: "\f005";   --bolt: "\f0e7";      --clr-success: rgb(64, 209, 91);   --clr-error: rgb(219, 138, 52);   --clr-warning: rgb(206, 41, 26); }  .icon-list li::before {   content: var(--icon);   color: var(--icon-color);   /* Other styles */ }  .checkbox-list {   --icon: var(--checkbox);   --icon-color: var(--clr-success); }  .star-list {   --icon: var(--star);   --icon-color: var(--clr-warning); }  .bolt-list {   --icon: var(--bolt);   --icon-color: var(--clr-error); }

Adding fallbacks

We could either put in a default icon by setting it as the fallback (e.g. var(--icon, "/f1cb")), or, since we’re using the content property, we could even put in an error message var(--icon, "no icon set").

See the Pen
Custom list icons with CSS Custom Properties
by Kevin (@kevinpowell)
on CodePen.

By locally scoping the --icon and the --icon-color variables, we’ve greatly increased the readability of our code. If someone new were to come into the project, it will be a whole lot easier for them to know how it works.

This isn’t limited to Font Awesome, of course. Locally scoping custom properties also works great for an SVG icon system:

:root {   --checkbox: url(../assets/img/checkbox.svg);   --star: url(../assets/img/star.svg);   --baby: url(../assets/img/baby.svg); }  .icon-list {   list-style-image: var(--icon); }  .checkbox-list { --icon: checkbox; } .star-list { --icon: star; } .baby-list { --icon: baby; }

Using locally scoped properties for more modular code

While the example we just looked at works well to increase the readability of our code — which is awesome — we can do a lot more with locally scoped properties.

Some people love CSS as it is; others hate working with the global scope of the cascade. I’m not here to discuss CSS-in-JS (there are enough really smart people already talking about that), but locally scoped custom properties offer us a fantastic middle ground.

By taking advantage of locally scoped custom properties, we can create very modular code that takes a lot of the pain out of trying to come up with meaningful class names.

Let’s um, scope the scenario.

Part of the reason people get frustrated with CSS is that the following markup can cause problems when we want to style something.

<div class="card">   <h2 class="title">This is a card</h2>   <p>Lorem ipsum dolor sit, amet consectetur adipisicing elit. Libero, totam.</p>   <button class="button">More info</button> </div>  <div class="cta">   <h2 class="title">This is a call to action</h2>   <p>Lorem, ipsum dolor sit amet consectetur adipisicing elit. Aliquid eveniet fugiat ratione repellendus ex optio, ipsum modi praesentium, saepe, quibusdam rem quaerat! Accusamus, saepe beatae!</p>   <button class="button">Buy now</button> </div>

If I create a style for the .title class, it will style both the elements containing the .card and .cta classes at the same time. We can use a compound selector (i.e. .card .title), but that raises the specificity which can lead to less maintainability. Or, we can take a BEM approach and rename our .title class to .card__title and .cta__title to isolate those elements a little more.

Locally scoped custom properties offer us a great solution though. We can apply them to the elements where they’ll be used:

.title {   color: var(--title-clr);   font-size: var(--title-fs); }  .button {   background: var(--button-bg);   border: var(--button-border);   color: var(--button-text); }

Then, we can control everything we need within their parent selectors, respectively:

.card {   --title-clr: #345;   --title-fs: 1.25rem;   --button-border: 0;   --button-bg: #333;   --button-text: white; }  .cta {   --title-clr: #f30;   --title-fs: 2.5rem;   --button-border: 0;   --button-bg: #333;   --button-text: white; }

Chances are, there are some defaults, or commonalities, between buttons or titles even when they are in different components. For that, we could build in fallbacks, or simply style those as we usually would.

.button {   /* Custom variables with default values */   border: var(--button-border, 0);    /* Default: 0 */   background: var(--button-bg, #333); /* Default: #333 */   color: var(--button-text, white);   /* Default: white */    /* Common styles every button will have */   padding: .5em 1.25em;   text-transform: uppercase;   letter-spacing: 1px; }

We could even use calc() to add a scale to our button, which would have the potential to remove the need for .btn-sm, btn-lg type classes (or it could be built into those classes, depending on the situation).

.button {   font-size: calc(var(--button-scale) * 1rem);   /* Multiply `--button-scale` by `1rem` to add unit */ }  .cta {   --button-scale: 1.5; }

Here is a more in-depth look at all of this in action:

See the Pen
Custom list icons with CSS Custom Properties
by Kevin (@kevinpowell)
on CodePen.

Notice in that example above that I have used some generic classes, such as .title and .button, which are styled with locally scoped properties (with the help of fallbacks). With those being setup with custom properties, I can define those locally within the parent selector, effectively giving each its own style without the need of an additional selector.

I also set up some pricing cards with modifier classes on them. Using the generic .pricing class, I set everything up, and then using modifier classes, I redefined some of the properties, such as --text, and --background, without having to worry about using compound selectors or additional classes.

By working this way, it makes for very maintainable code. It’s easy to go in and change the color of a property if we need to, or even come in and create a completely new theme or style, like the rainbow variation of the pricing card in the example.

It takes a bit of foresight when initially setting everything up, but the payoff can be awesome. It might even seem counter-intuitive to how you are used to approaching styles, but next time you go to create a custom property, try keeping it defined locally if it doesn’t need to live globally, and you’ll start to see how useful it can be.

The post Breaking CSS Custom Properties out of :root Might Be a Good Idea appeared first on CSS-Tricks.

CSS-Tricks

, , , , , ,
[Top]

What makes someone a good front-end developer?

We recently covered this exact same thing, but from the perspective of a bunch of developers.

Chris Ferdinandi weighs in:

The least important skills for a front-end developer to have are technical ones.

The nuances of JavaScript. How to use a particular library, framework, or build tool. How the cascade in CSS works. Semantic HTML. Fizz-buzz.

Chris takes that a little farther than I would. I do think that with an understanding of HTML, CSS, and JavaScript, the deeper the better, and that it is an ingredient in making a good front-end developer. But I also agree it’s much more than that. In fact, with solid foundational skills and really good soft skills (e.g. you’re great at facilitating a brainstorming meeting), you could and should get a job before they even look at your language skills.

Direct Link to ArticlePermalink

The post What makes someone a good front-end developer? appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]