A Beautiful Site

Copying a File Path in Finder

2026-09-23T00:00:00Z

I keep discovering macOS features I should've known about for years.

Need a file's full pathname? For a long time I was right clicking, opening Get Info, highlighting the path, and copying it. That's a lot of clicks for something I do many times a day. Yet I've somehow continued on like this for years…

I've known about the Option key menu trick in macOS, but I never knew that right-clicking a file in Finder and holding Option would turn the Copy action into Copy "filename" as Pathname. 🤯

This probably isn't news to everyone, but I've been a macOS user for longer than I care to admit and I just now discovered it.

Naturally, I posted about it on Bluesky and Dusty chimed in to tell me that you can press ⌘ + Option + C to do the same thing with the keyboard.

What other obvious shortcuts have I been missing out on?!

Named Breakpoints Without Sass

2026-09-22T00:00:00Z

I stopped using Sass awhile ago. CSS nesting and custom properties cover almost everything I used it for. It's been liberating to not have a build step for my CSS.*

But I do miss named breakpoints. In Sass, for example, you could set $md: 48em and use it in all your @media queries.

$md: 48em;

@media (min-width: $md) {
  ...
}

Early on, custom properties looked like they'd be the holy grail for this! Alas…

:root {
  --breakpoint-md: 48em;
}

@media (min-width: var(--breakpoint-md)) {
  /* lol nope */
}

I assumed this was an oversight that would get fixed eventually. Turns out, it was intentional.

"Why can't it just read the value from :root?"

The problem is that custom properties are element-scoped. They cascade and inherit like any other property, but their values aren't known until the browser computes styles for a specific element.

A media query is, well, not an element. It's evaluated against the viewport before the cascade runs, so there's no element to read --breakpoint-md from, and using :root would have been a malformed bastardization of the specification.*

The objection was scoping and evaluation order, but knowing why doesn't make it any less disappointing.

The Proposals

There are two proposals to help with this problem, but neither has shipped.

@custom-media from Media Queries Level 5 lets you name an entire query and reuse it.

@custom-media --tablet (width >= 48em);

@media (--tablet) {
  ...
}

The spec has been around for years. Firefox has it behind a flag, and Chrome and Safari haven't shipped it at all. It also names a query, not a length, so you can't reuse the same number in a width property somewhere else.

Author-defined env() variables are closer to what I actually want. Unlike custom properties, environment variables are global and don't cascade, which is why they're allowed in media queries. Browsers provide a few, like safe-area-inset-top, but there's no way for authors to define their own yet. The spec is a working draft as of 2025, and how you'd even declare one is still up in the air.

A Clever Solution

I stumbled upon this post by Mastro, which pointed at Andrew Walpole's CodePen. The idea is you write the viewport sizes in @media, set a named token on :root, and access it with a style query instead of repeating the media query.

:root {
  --viewport: 'desktop';

  @media (max-width: 64em) {
    --viewport: 'tablet';
  }

  @media (max-width: 37.5em) {
    --viewport: 'mobile';
  }
}

@container style(--viewport: 'mobile') {
  /* Styles for the mobile bucket */
}

@container style(--viewport: 'desktop'),
@container style(--viewport: 'tablet') {
  /* Styles for everything bigger */
}

This isn't a real viewport query, of course. It's a style query that happens to track one, and style queries for custom properties only landed in Firefox 151 back in May, so anyone on an older version won't get them. It's definitely a neat trick, though!

Unfortunately, there's no clean fallback for unsupportive browsers. @supports can't detect style queries, and even if it could, the only workaround would be to duplicate everything in @media. 😕

So it's a bit too early to use for production, but it will soon be a good reason to not keep a preprocessor around.

*Sass is one of the reasons we got -- instead of $ and I've seriously thought about making my own preprocessor because it's so awkward. But I really, really don't want a build step for my CSS.

I'd Rather Review Specs

2026-09-16T00:00:00Z

From a maintainer's perspective, AI-generated pull requests are just piles of potential slop that we have to sort through. We have no idea if folks are one-shotting them or if they're taking the time to spec out proper solutions and mold them into usable code.

That uncertainty isn't free. It costs review time, which is the one thing maintainers never have enough of. Daniel Stenberg has been feeling this same pain with curl.

I would much rather folks help spec out the features and improvements they want to see in the library, as that's much easier to review and a thousand times more useful than generating a bunch of code.

Send me the thinking. Not the slop.

Most Software Was Already Slop

2026-09-04T00:00:00Z

As software engineers, we take pride in hand-written code and knowing how everything we build works in detail. While there are many developers out there who build good software, there are many, many more who don’t. Yet we balk at the idea of vibe coding, even when it yields decent results.

You don’t need a scientific study to realize the mean quality of human-authored software leaned towards slop even before AI was around. How many times have you been frustrated by an app or website that just didn’t work right? (This is especially true for software produced by big companies.)

The quality of software humans can build is absolutely incredible. But the quality of software humans actually do build is usually not.

So no, AI can’t build perfect software. Maybe that will improve in the future, or maybe it will remain just as messy as the human-authored code LLMs have been trained on. I don’t think any of that matters, because if AI can build software that’s at least as good as the mediocre code that came before it, that will be acceptable for most industries.

Customers don’t care about the craft, they care about the result. And if the result is faster, cheaper, and good enough…well, that’s a better combination than anything they’ve ever had before. Why wouldn't they choose it?

FOUCE Should Be the Browser's Problem

2026-08-20T00:00:00Z

I've already written about FOUCE twice…it's that annoying Flash of Unstyled Custom Element that occurs when the page first loads. It's one of the most common complaints from folks who use web components.

And while the proposed solution works in practice, it's not exactly ergonomic:

Cloak the page with a class and a CSS rule
List every custom element by name
Wait for all of them to register (and use a setTimeout() as a fallback)
Remove the class with JS to reveal the page

Since we're a bit limited with what we can do in userland, I began pondering what browsers could do to solve such a problem.

What if we could register custom elements like this?*

<script type="element" src="my-button.js"></script>

When such a script is on the page, the browser would load the custom element from the module, wait until it fully resolves and registers, and then paint. That means zero FOUCE out of the box, and browsers could even take it a step further and guarantee those elements are available immediately, removing the need for await customElements.whenDefined().

Every custom element defined this way would become a first-class citizen, just like native HTML elements.

“But We Already Have `blocking=render`”

The blocking="render" attribute tells the browser to hold off painting until the script has been fetched and executed. If your file is a flat module that calls customElements.define() at the top level, this works today:

<script type="module" src="my-button.js" blocking="render"></script>

Alas, that's not how most component libraries are built. Registration tends to happen behind an await, e.g. a dynamic import or a lazy loader that defines elements as it finds them in the DOM. The module finishes executing before the elements are defined, so the browser paints and, well, we're right back where we started. 😕

The problem is that blocking="render" cares about scripts, but FOUCE is about custom elements.

Changing the Spec

I know this isn't a fast or easy thing to change but, at the moment, every project that wants to avoid FOUCE has to discover the problem, find a solution, and wire it all up correctly. That's a lot to ask for something the browser could easily handle on its own, and it's a big reason people reach for SSR or, more commonly, decide against using web components.

I'm not married to this proposed syntax, but I do hope this inspires browser makers to give us a sensible way to prevent FOUCE. This would

The browser already knows when custom elements get defined, it just won't let us wait for them.

*I considered <link rel="element" href="my-button.js">, but since custom elements are defined in JavaScript where other potentially unrelated logic can execute, it's seems <script type="element"> is more appropriate.

Contextual Styling With CSS Nesting

2026-08-12T00:00:00Z

I've been hooked on CSS nesting for awhile. Like Sass, I've always written it with the & selector at the front, like this.

.button {
  background: slategrey;

  &:hover {
    background: darkslategrey;
  }
}

Turns out, the & doesn't have to come first. Put it after another selector and the relationship flips. Instead of styling what's inside the element, you're styling the element based on what surrounds it.

.card {
  background: white;
  color: black;

  /* When the card is inside a dark container */
  .dark & {
    background: #1c1e21;
    color: white;
  }
}

That compiles to the equivalent of this.

.card {
  background: white;
  color: black;
}

.dark .card {
  background: #1c1e21;
  color: white;
}

Read .dark & as "when this element is inside .dark." The card's default styles and its dark mode styles now live in the same rule. This is handy for components that adapt to their container. Here's a button that slims down when it lands in a toolbar.

.button {
  padding: 0.875rem 1.125rem;

  .toolbar & {
    padding: 0.375rem 0.625rem;
  }
}

And since & is just a selector like any other, you can use it more than once. This adds spacing between adjacent cards.

.card {
  border: solid 1px lightgray;
  border-radius: 0.5rem;
  padding: 1rem;

  & + & {
    margin-top: 1rem;
  }
}

The caveat is specificity. Under the hood, the browser replaces & with the parent selector wrapped in :is(), so .dark & becomes .dark :is(.card). That matters because :is() takes the specificity of its most specific argument, which can bite you if the parent rule uses a selector list.

If you've used Sass, this trick probably looks familiar because it's worked there for ages. The two aren't quite the same underneath, though. Sass pastes the parent selector in as text, so & inherits whatever specificity that text happens to have.

Native CSS wraps it in :is() instead, which is where the selector list gotcha comes from. The examples here land in the same place either way, but the moment an ID shows up in the parent, the two stop agreeing.

The good news is that browser support for native nesting is green across the board now, so you don't need a preprocessor for it anymore.

That's one less reason to reach for a build step when writing CSS.

I'm pulling ColorCopy from the macOS App Store

2026-08-07T00:00:00Z

I launched ColorCopy on May 18. It was my second macOS app, but the first one I launched on the Mac App Store. Today, I decided to pull it.

The app isn't a new idea, but it bakes four color tools into a single menu bar app: an eyedropper, a color picker, a palette manager, and a contrast checker, each one a hotkey away.

I made it available for free, with a one-time in-app purchase to unlock unlimited use. No subscription, no recurring fees. It's simple, stable software with the lowest possible barrier to entry…exactly the kind of utility the App Store seems made for.

I wasn't sure what to expect, so I ran an experiment to answer some questions:

Is there any real benefit to having your Mac app on the App Store? Is the Apple tax worth it? Will customers just come flooding in?

For ColorCopy's release, I did zero marketing. No Product Hunt launch. No Hacker News post. The only things I published were this blog post and a tweet. If the App Store delivers on its promise of discoverability, that should be enough to see some kind of traffic…right?

You be the judge. In nearly three months on the App Store, ColorCopy got a little over 1,000 impressions, 149 product page views, 85 first-time downloads, three in-app purchases, and $21 in proceeds. Not per day. In total.

Broken down over 81 days, that averages out to:

13 impressions per day
1.8 product page views per day
1 download per day
0.04 in-app purchases per day (about one per month)
$0.26 in proceeds per day

Extrapolated to 12 months, ColorCopy would have earned about $95…not even enough to cover Apple's $99 annual developer fee.

If discoverability isn't a part of the App Store deal, what exactly is the benefit? Why limit your Mac app to the sandbox?* Why spend hours in App Store Connect filling out metadata, screenshots, and localization information? Why wait an arbitrary number of days for someone to review your app with the consistency of a coin flip?

It doesn't seem worth it for Mac developers.

Adios, App Store 👋

As of today, ColorCopy is self-distributed and sold through Polar (the new Stripe, which I highly recommend). This is the same way I sell TongueType, which makes pretty much everything easier on my end: one dashboard, real customer relationships, no finicky review process, and updates ship the moment they're ready.

The move required swapping out in-app purchases from StoreKit to Polar, and updates now ship through Sparkle instead of the App Store's built-in update mechanism. Both are tried and true solutions for self-distributed Mac apps.

To be fair, you can't really do this on iOS. Most users aren't jailbroken…walled garden and all. But on Mac, where self-distribution is still a first-class option, there seems to be zero incentive to be in the App Store, especially if you're counting on discoverability.

In three months, the App Store sent me barely a trickle of customers. Had I marketed the app myself, the traffic would have flowed the other way. I would've been sending my customers to Apple and paying a tax for the privilege.** Self-distribution gives me the freedom and control over my apps that the App Store's sandbox never will.

If it's on me to drum up all of my own traffic, I'm going to send it to my own website.

*I originally used a third-party library for the eye dropper because NSColorSampler is meh, but the sandbox forbids it so I was forced to remove it. Yes, I had to make my app shittier in order to put it on the App Store.

**I fully acknowledge this may not be the case for every app, but it was my experience and worth sharing. Your mileage may vary.

Aside: ColorCopy was available in 10 languages on the App Store. For some reason, the listing always showed FR as its primary language (it wasn't). The app is available in many languages, including English.

Software Has Changed

2026-07-12T00:00:00Z

A tweet from Jamon Holmgren inspired some thoughts about how software has changed, from a developer's perspective. He says:

I've been spending a lot of time talking to experienced software engineers lately and when you get in a 1:1 candid conversation, everyone is rather shell-shocked by how quickly and drastically things have changed.

It's true.

We're building faster, but not necessarily better. We're building more, but not necessarily more of the right things. We've traded flow states for "thinking…" states. We throw away code without a thought because experiments are cheap.

But that also means the good devs do more. We're not exhausted from writing every piece of code by hand, so we have the time and energy to review, polish, refactor, and add those extra features. We can solve technical debt before it ever lands in main.

I still love this field, but it changed overnight. It's not the world I chose to live in, but I'm making the best of it and learning to build faster than I could before. I think at a higher level now, and that helps avoid tunnel vision.

A question I find myself pondering: if the end result is solid code that I've thoroughly reviewed and trust, does it truly matter how it was created?

I Mostly Stopped Typing

2026-06-25T00:00:00Z

I built the dictation app I wanted. It's called TongueType, and my daughter did the voice over for the video. (Family business.)

It hasn't gotten much traction yet, and I think I know why. Dictation was bad for so long that most people stopped paying attention. I don't blame them. I wrote it off myself for years.

Alas, that reputation is out of date. The thing that was flaky and frustrating five years ago runs entirely on your Mac now, and it's good. Really good.

Downloads of the app are low so far, but the people who actually try it tend to stick around. So the problem isn't the app, it's getting anyone to give dictation one more chance.

The habit is the hurdle

The hard part isn't accuracy. It's that talking instead of typing is a new habit, and new habits are awkward before they're automatic. For the first week it feels strange. You catch yourself reaching for the keyboard out of muscle memory.

Then one day it clicks.

I still write code by hand. That's thinking, not transcribing, and I want my fingers on it (plus saying HTML tags and attributes out loud seems counterintuitive 😂). But for almost everything else, I talk.

I prompt LLMs
I send emails
I reply on Slack
I write commit messages
I do most other text with my voice

Every one of those is the same task: the thinking is done, I just have to get the words out. That's a bigger chunk of my day than I expected.

My desk setup

On the go, the MacBook's built-in mic works just fine. You don't need fancy hardware for this. But when I'm at my desk, my laptop is docked, so I pair TongueType with a Tula mic. It's small, portable, sounds great, and looks the part! (Kuru Toga mechanical pencil positioned for size comparison.)

One tip: use a wired mic if you can. Bluetooth adds latency, and latency is the enemy of a tool you reach for dozens of times a day.

Honest caveat: dictation probably isn't great in a co-working space. 😂

"Why is this better than macOS dictation?"

TongueType is more accurate, it's more customizable, and it doesn't send my voice anywhere.

I could list the features, but my answer is the same one I'd give for most things: just try it. It's free to start.

What's your experience been with dictation? If you wrote it off years ago, I'd genuinely love for you to give TongueType a shot and tell me what you think.

Introducing ColorCopy

2026-05-18T00:00:00Z

My second macOS app, ColorCopy, was approved by the Mac App Store today! It started as a menu bar color picker. Press a key, click any pixel on your screen, and the color lands on your clipboard in whatever format you need.

Then I kept finding more things I wanted to put into it.

Update (August 2026): ColorCopy is no longer on the Mac App Store. It's now self-distributed and available at ColorCopy.app. Here's why I pulled it.

Why I made it

I pick colors off my screen constantly. A shade in a screenshot, a brand color on a website, an accent color in an app I want to match.

There are plenty of color picker apps already, so why build another one? Because picking colors is the easy part. I also wanted to compare contrast ratios, keep my palettes organized, pull colors out of an image, and sync all of it between my Macs. Doing that meant opening four different tools.

Plus, I enjoy building my own tools!

How it works

Press the hotkey, click any pixel on screen, and the color is formatted and written to your clipboard. There are four configurable global hotkeys: pick a color instantly, open the Color Picker window, open your palettes, or open the contrast checker.

The Color Picker window has an eyedropper and shows the selected color in all 21 formats at once. Click a row to copy it. It's the format converter I always wanted.

Palettes

A color picker that forgets every color the moment you copy it isn't much of a tool. ColorCopy keeps a configurable history of recent picks and a full palette manager.

There are 24 built-in presets, including Tailwind, Material Design 3, Radix Colors, Open Color, IBM Carbon, GitHub Primer, and Apple System Colors. You can build unlimited custom palettes, organize them into named scales, and drag swatches around.

Star any swatch and it shows up under a Favorites submenu right in the menu bar. One click and that exact color is on your clipboard.

You can also extract a palette from any image by dragging one onto the window. Choose how many colors to pull and it saves the result as a new palette.

Palettes import from Adobe Swatch Exchange (.ase), Apple Color List (.clr), and JSON. They export to eight formats, including CSS custom properties, HTML, PDF, and PNG.

Turn on iCloud sync and your palettes follow you to all your Macs.

A built-in contrast checker

Colors rarely live alone. Text sits on a background, an icon sits on a button, and whether that pairing is readable shouldn't be a guess.

Pick a background and a foreground color and ColorCopy reports the contrast in both WCAG 2, with AA/AAA pass and fail for normal and large text, and APCA, the newer perceptual algorithm. If a pair fails, open the context menu and select fix, and ColorCopy nudges the color just enough to meet the contrast you asked for.

Color contrast isn't only an aesthetic decision. For people with low vision, it's the difference between readable and not.

A bit of personality

ColorCopy lives entirely in the menu bar, but it's not joyless. There are three menu bar icon styles, adjustable swatch sizes, and nine copy sounds to pick from — or silence, if you prefer.

Privacy

ColorCopy runs on your Mac. There's no account, no analytics, no telemetry, no crash reporter, and no server for your data to land on.

Two things are opt-in. In-app purchase goes through Apple's StoreKit, and iCloud sync keeps your palettes consistent across your Macs through your own private iCloud account. Sync is off by default, and even when it's on, your data goes to Apple, never to me.

It also needs no special permissions. ColorCopy uses Apple's sandboxed NSColorSampler, so it never asks for Screen Recording or Accessibility access.

Pricing

ColorCopy is free to download and the free tier includes every feature: all 21 formats, the Color Picker window, the contrast checker, the palette manager, image extraction, favorites, and every customization setting. It's metered to 50 color copies per month.

If you want unlimited copies, ColorCopy Pro is a one-time $7.99 purchase that removes the cap. That's the only difference between the tiers. No subscription.

You'll need macOS 14 (Sonoma) or later. It's available in 10 languages.

If you copy colors off your screen even occasionally, give ColorCopy a try and let me know what you think!

Introducing TongueType

2026-05-14T00:00:00Z

I just launched my first macOS app, TongueType. It's voice dictation that runs entirely on your Mac. Hold a key, speak, release, and your words appear wherever your cursor happens to be.

Why I made it

I type fast, but I often think faster than I type. When an idea is fully formed in my head, the bottleneck is my fingers.

macOS has had built-in dictation forever, but I never liked relying on it. Accuracy aside, I didn't love the idea of my voice taking a trip to a server and back just to write a sentence.

There are plenty of dictation apps out there. Alas, the good ones tend to want a subscription, a cloud account, or both. I wanted one that stays on my machine and gets out of the way.

TongueType uses OpenAI's Whisper model running locally on Apple Silicon. Nothing is uploaded, nothing is logged, and there's no account to create. Your voice never leaves your Mac.

How it works

The whole interaction is one key. By default it's the Right Option key, because it's sitting right there and your thumb isn't doing anything important. Hold it, talk, let go. The transcribed text gets inserted at your cursor, whether that's your editor, your email, a chat box, or a search field.

You can also drop in an audio or video file — WAV, MP3, MP4, MOV — and get a transcript back. Handy for meeting recordings and voice memos.

A few details I spent longer on than I expected:

A grace period, so a quick accidental tap doesn't start recording
Double-tap to latch, for when you want to keep talking without holding the key down
Cancel phrases, so you can say "scratch that" at the end and discard the whole thing
Spoken symbols, so "new line" and "question mark" produce the symbol instead of the words
Post-processing, for the terms that never get dictated properly

It speaks twelve languages and detects them automatically.

How I actually use it

Building the app was one thing. Using it every day turned out to be another. A couple months in, it's worked its way into most of what I do at the keyboard.

I prompt LLMs with it, which is where it surprised me most. Talking to an AI assistant is conversational by nature, and typing out a long, detailed prompt is tedious. Speaking it isn't. I get more context into a prompt because I'm not rationing my words to save my fingers.

I use it for email, too. Replies that used to sit in my drafts get spoken out in a single pass. I still read them before sending, but the blank-page friction is gone. Same for code comments and commit messages, which are really just writing. It's faster to explain why a change exists out loud than to stop and type it.

Every one of those is the same task: the thinking is done, I just have to get the words out.

A bit of personality

TongueType lives in the menu bar. The recording overlay is small and out of the way, and you can move it wherever you like on screen. There are twenty accent colors, including Rainbow Mode.

None of that was necessary. But it was fun to build.

Accessibility

I want to call this out specifically. Voice dictation isn't only a convenience. For some people it's the difference between using a computer comfortably or not. If typing is painful or difficult for you, TongueType is meant to be a real input method, not an afterthought. That shaped a lot of the decisions above.

Pricing

TongueType is free to try, and the free tier includes every feature. You get 30 minutes of live dictation each month plus short file transcriptions.

If you want unlimited, TongueType Pro is a one-time $19.99 purchase that covers up to five Macs. No subscription. Buy it once, keep it forever.

You'll need macOS 14 or later on an Apple Silicon Mac. Running the model locally is the whole idea, and Apple Silicon is what makes it fast enough to bother.

If any of this sounds useful, give TongueType a try and let me know what you think!

Update: I've since released a second macOS app, ColorCopy, a menu bar color picker. If TongueType sounds like your kind of app, that one might too.

My Stance on AI in Software Development

2026-04-20T00:00:00Z

I believe artificial intelligence is a powerful and valuable tool that can significantly improve how we create, solve problems, and bring ideas to life.

I didn't always feel this way.. But these days, I use AI regularly in my work and I expect that to continue.

We may not have chosen this reality, but it's the reality we're in. The tools and their benefits — costs be damned — can no longer be ignored.

That said, when people ask "was this made with AI?" the honest answer is rarely simple. AI can speed up many parts of the process, but it doesn’t replace human judgment, creativity, or responsibility. What appears effortless on the surface rests on deliberate human direction, critical thinking, and careful review.

Getting good results from AI requires active guidance and oversight. The nuances of context, ethics, user needs, and real-world application are simply too varied given the current technology.

Moreover, AI doesn’t generate meaningful ideas or elegant solutions on its own. Strong human vision, architecture, and decision-making are still essential. There is no prompt, model, or service that can deliver finished, trustworthy work without substantial human input.

My commitment to you is this: everything I create will be driven by human ideas, architecture, verification, and final review. I will use AI as an assistant to do what I would have done anyway, but more efficiently.

I will not let AI replace my intelligence, but I will use it to turn my intelligence into code faster.

— Cory LaViska

How I Use GitHub Issues

2025-08-04T00:00:00Z

I like using GitHub issues for actionable things such as bugs and backlog items I've committed to doing. Non-maintainers are encouraged to open issues only for bugs, whereas everything else is a discussion.

Bug Report 👉 Issue
Help/support 👉 Discussion
Ask a question 👉 Discussion
Ideas/suggestions 👉 Discussion
Waxing Philosophical 👉 Discussion

Alas, no matter how clear you make your templates, some folks will inevitably open issues anyway. Fear not! You can use this gem of a feature in GitHub's sidebar to convert it to a discussion. I use this very liberally. (Tip: make sure you take the time to categorize your discussions. Organization matters!)

Nobody ever got mad that their issue got turned into a discussion.

Strategic decisions

Sometimes things need to be addressed but there isn't anything actionable yet. Perhaps a decision needs to be made. I think it's best to hash that out in discussions. RFCs, proposals, philosophical discussions are all just that…discussions.

Once a decision is made, you can create an actionable issue from the discussion summarizing the problem and the agreed solution, keeping the [often messy] details out of the issue but cleanly linking back to them for reference.

The keyword is actionable. This can be anything from "implement feature X" to "determine the best approach to Y." In the case of the latter, the issue should probably contain a follow up, e.g. "once the best approach is determined, implement and document Y".

Using this approach combined with milestones has been such a joy compared to the old way of doing issues.

Result: GitHub issues serve as a clear backlog of committed, actionable TODOs for the project. Meanwhile, the discussion forum flourishes with questions, suggestions, and other thoughts from the community.

Win-win.

nb4 — I'm aware labels exist and I find them more useful as a tool to organize a backlog and triage than to separate actual "issues" from "discussions." We used to do this before GitHub had discussions, so there's some history there, but there's really no need to let non-issues clutter things up anymore.

Revisiting FOUCE

2024-12-23T00:00:00Z

It's been awhile since I wrote about FOUCE and I've since come up with an improved solution that I think is worth a post.

This approach is similar to hiding the page content and then fading it in, but I've noticed it's far less distracting without the fade. It also adds a two second timeout to prevent network issues or latency from rendering an "empty" page.

First, we'll add a class called reduce-fouce to the <html> element.

<html class="reduce-fouce">
  ...
</html>

Then we'll add this rule to the CSS.

<style>
  html.reduce-fouce {
    opacity: 0;
  }
</style>

Finally, we'll wait until all the custom elements have loaded or two seconds have elapsed, whichever comes first, and we'll remove the class causing the content to show immediately.

<script type="module">
  await Promise.race([
    // Load all custom elements
    Promise.allSettled([
      customElements.whenDefined('my-button'),
      customElements.whenDefined('my-card'),
      customElements.whenDefined('my-rating')
      // ...
    ]),
    // Resolve after two seconds
    new Promise(resolve => setTimeout(resolve, 2000))
  ]);

  // Remove the class, showing the page content
  document.documentElement.classList.remove('reduce-fouce');
</script>

This approach seems to work especially well and won't end up "stranding" the user if network issues occur.

Web Components Are Not the Future — They’re the Present

2024-09-27T00:00:00Z

It’s disappointing that some of the most outspoken individuals against Web Components are framework maintainers. These individuals are, after all, in some of the best positions to provide valuable feedback. They have a lot of great ideas!

Alas, there’s little incentive for them because standards evolve independently and don’t necessarily align with framework opinions. How could they? Opinions are one of the things that make frameworks unique.

And therein lies the problem. If you’re convinced that your way is the best and only way, it’s natural to feel disenchanted when a decision is made that you don’t fully agree with.

This is my open response to Ryan Carniato’s post from yesterday called “Web Components Are Not the Future.”

WTF is a component anyway?

The word component is a loaded term, but I like to think of it in relation to interoperability. If I write a component in Framework A, I would like to be able to use it in Framework B, C, and D without having to rewrite it or include its entire framework.

I don’t think many will disagree with that objective.

We’re not there yet, but the road has been paved and instead of learning to drive on it, frameworks are building…different roads.

Ryan states:

If the sheer number of JavaScript frameworks is any indicator we are nowhere near reaching a consensus on how one should author components on the web. And even if we were a bit closer today we were nowhere near there a decade ago.

The thing is, we don’t need to agree on how to write components, we just need to agree on the underlying implementation, then you can use classes, hooks, or whatever flavor you want to create them.

Turns out, we have a very well-known, ubiquitous technology that we’ve chosen to do this with: HTML.

But it also can have a negative effect. If too many assumptions are made it becomes harder to explore alternative space because everything gravitates around the establishment. What is more established than a web standard that can never change?

If the concern is premature standardization, well, it’s a bit late for that. So let’s figure out how to get from where we are now to where we want to be. The solution isn’t to start over at the specification level, it’s to rethink how front end frameworks engage with current and emerging standards and work to improve them.

Respectfully, it’s time to stop complaining, move on, and fix the things folks perceive as suboptimal.

The definition of component

That said, we also need to realize that Web Components aren’t a 1:1 replacement for framework components. They’re tangentially related things, and I think a lot of confusion stems from this. We should really fix the definition of component.

So the fundamental problem with Web Components is that they are built on Custom Elements. Elements !== Components. More specifically, Elements are a subset of Components. One could argue that every Element could be a Component but not all Components are Elements.

To be fair, I’ve never really liked the term “Web Components” because it competes with the concept of framework components, but that’s what caught on and that's what most people are familiar with these days.

Alas, there is a very important distinction here. Sure, a button and a text field can be components, but there are other types. For example, many frameworks support a concept of renderless components that exist in your code, but not in the final HTML. You can’t do that with Web Components, because every custom element results in an actual DOM element. (FWIW I don’t think this is a bad thing — but I digress…)

As to why Web components don’t do all the things framework components do, that’s because they’re a lower level implementation of an interoperable element. They’re not trying to do everything framework components do. That’s what frameworks are for.

It’s ok to be shiny

In fact, this is where frameworks excel. They let you go above and beyond what the platform can do on its own. I fully support this trial-and-error way of doing things.

After all, it’s fun to explore new ideas and live on the bleeding edge. We got a lot of cool stuff from doing that. We got document.querySelector() from jQuery. CSS Custom Properties were inspired by Sass. Tagged template literals were inspired by JSX. Soon we’re getting signals from Preact.

And from all the component-based frameworks that came before them, we got Web Components: custom HTML elements that can be authored in many different ways (because we know people like choices) and are fully interoperable (if frameworks and metaframeworks would continue to move towards the standard instead of protecting their own).

Frameworks are a testbed for new ideas that may or may not work out. We all need to be OK with that. Even framework authors. Especially framework authors. More importantly, we all need to stop being salty when our way isn’t what makes it into the browser.

There will always be a better way to do something, but none of us have the foresight to know what a perfect solution looks like right now. Hindsight is 20/20. As humans, we’re constantly striving to make things better. We’re really good at it, by the way. But we must have the discipline to reach various checkpoints to pause, reflect, and gather feedback before continuing.

Even the cheapest cars on the road today will outperform the Model T in every way. I’m sure Ford could have made the original Model T way better if they had spent another decade working on it, but do you know what made the next version even better than 10 more years? The feedback they got from actual users who bought them, sat in them, and drove them around on actual roads.

Web Standards offer a promise of stability and we need to move forward to improve them together. Using one’s influence to rally users against the very platform you’ve built your success on is damaging to both the platform and the community.

We need these incredible minds to be less divisive and more collaborative.

The right direction

Imagine if we applied the same arguments against HTML early on. What if we never standardized it at all? Would the Web be a better place if every site required a specific browser? (Narrator: it wasn't.) Would it be better if every site was Flash or a Java applet? (Remember Silverlight? lol)

Sure, there are often better alternatives for every use case, but we have to pick something that works for the majority, then we can iterate on it. Web Components are a huge step in the direction of standardization and we should all be excited about that.

But the Web Component implementation isn’t compatible with existing frameworks, and therein lies an existential problem.

Web Components are a threat to the peaceful, proprietary way of life for frameworks that have amassed millions of users — the majority of web developers. Because opinions vary so wildly, when a new standard emerges frameworks can’t often adapt to them without breaking changes. And breaking changes can be detrimental to a user base.

Have you spotted the issue? You can’t possibly champion Web Standards when you’ve built a non-standard thing that will break if you align with the emerging standard. It’s easier to oppose the threat than to adapt to it.

And of course Web Components don’t do everything a framework does. How can the platform possibly add all the features every framework added last week? That would be absolutely reckless.

And no, the platform doesn’t move as fast as your framework and that’s sometimes painful. But it’s by design. This process is what gives us APIs that continue to work for decades.

As users, we need to get over this hurdle and start thinking about how frameworks can adapt to current standards and how to evolve them as new ones emerge. Let’s identify shortcomings in the spec and work together to improve the ecosystem instead of arguing about who’s shit smells worse.

Reinventing the wheel isn’t the answer. Lock-in isn’t the answer.

This is why I believe that the next generation of frameworks will converge on custom elements as an interoperable component model, enhance that model by sprinkling in awesome features of their own, and focus more on flavors (class-based, functional, signals, etc.) and higher level functionality. As for today's frameworks? How they adapt will determine how relevant they remain.

Living dangerously

Ryan concludes:

So in a sense there are nothing wrong with Web Components as they are only able to be what they are. It's the promise that they are something that they aren't which is so dangerous. The way their existence warps everything around them that puts the whole web at risk. It's a price everyone has to pay.

So Web Components aren’t the specific vision you had for components. That's fine. But that's how it is.

They're not Solid components. They’re not React components. They’re not Svelte components. They’re not Vue components. They’re standards-based Web Components that work in all of the above. And they could work even better in all of the above if all of the above were interested in advancing the platform instead of locking users in.

I’m not a conspiracy theorist, but I find interesting the number of people who are and have been sponsored and/or hired by for-profit companies whose platforms rely heavily on said frameworks. Do you think it’s in their best interest to follow Web Standards if that means making their service less relevant and less lucrative? Of course not.

If you’ve built an empire on top of something, there’s absolutely zero incentive to tear it down for the betterment of humanity. That’s not how capitalism works. It’s far more profitable to lock users in and keep them paying. But you know what…?

Web Standards don't give a fuck about monetization.

Longevity supersedes ingenuity

The last thing I’d like to talk about is this line here.

Web Components possibly pose the biggest risk to the future of the web that I can see.

Of course, this is from the perspective of a framework author, not from the people actually shipping and maintaining software built using these frameworks. And the people actually shipping software are the majority, but that’s not prestigious so they rarely get the high follower counts.

The people actually shipping software are tired of framework churn. They're tired of shit they wrote last month being outdated already. They want stability. They want to know that the stuff they build today will work tomorrow.

As history has proven, no framework can promise that.

You know what framework I want to use? I want a framework that aligns with the platform, not one that replaces it. I want a framework that values incremental innovation over user lock-in. I want a framework that says it's OK to break things if it means making the Web a better place for everyone. Yes, that comes at a cost, but almost every good investment does, and I would argue that cost will be less expensive than learning a new framework and rebuilding buttons for the umpteenth time.

The Web platform may not be perfect, but it continuously gets better. I don’t think frameworks are bad but, as a community, we need to recognize that a fundamental piece of the platform has changed and it's time to embrace the interoperable component model that Web Component APIs have given us…even if that means breaking things to get there.

The component war is over.

Component Machines

2024-09-05T00:00:00Z

Components are like little machines. You build them once. Use them whenever you need them.

Every now and then you open them up to oil them or replace a part, then you send them back to work.

And work, they do.

Little component machines just chugging along so you never have to write them from scratch ever again.

Adapted from this tweet.

Styling Custom Elements Without Reflecting Attributes

2024-06-12T00:00:00Z

I've been struggling with the idea of reflecting attributes in custom elements and when it's appropriate. I think I've identified a gap in the platform, but I'm not sure exactly how we should fill it.

I'll explain with an example. Let's say I want to make a simple badge component with primary, secondary, and tertiary variants.

<my-badge variant="primary">foo</my-badge>
<my-badge variant="secondary">bar</my-badge>
<my-badge variant="tertiary">baz</my-badge>

This is a simple component, but one that demonstrates the problem well. I want to style the badge based on the variant property, but sprouting attributes (which occurs as a result of reflecting a property back to an attribute) is largely considered a bad practice. A lot of web component libraries do it out of necessary to facilitate styling — including Shoelace — but is there a better way?

The problem

I need to style the badge without relying on reflected attributes. This means I can't use :host([variant="..."]) because the attribute may or may not be set by the user. For example, if the component is rendered in a framework that sets properties instead of attributes, or if the property is set or changed programmatically, the attribute will be out of sync and my styles will be broken.

So how can I style the badge based its variants without reflection? Let's assume we have the following internals, which is all we really need for the badge.

<my-badge>
  #shadowRoot
    <slot></slot>
</my-badge>

What can we do about it?

I can't add classes to the slot, because :host(:has(.slot-class)) won't match.
I can't set a data attribute on the host element, because that's the same as reflection and might cause issues with SSR and DOM morphing libraries.
I could add a wrapper element around the slot and apply classes to it, but I'd prefer not to bloat the internals with additional elements. With a wrapper, users would have to use ::part(wrapper) to target it. Without the wrapper, they can set background, border, and other CSS properties directly on the host element which is more desirable.
I could add custom states for each variant, but this gets messy for non-Boolean values and feels like an abuse of the API.

Filling the gap

I'm not sure what the best solution is or could be, but one thing that comes to mind is a way to provide some kind of cross-root version of :has that works with :host. Something akin to:

:host(:has-in-shadow-root(.some-selector)) {
  /* maybe one day… */
}

If you have any thoughts on this one, hit me up on Twitter.

Reflection and Custom States in Web Components

2024-06-05T00:00:00Z

In the Web Component world, attribute reflection is commonly used to style custom elements both internally and as public APIs for consumers. If you're not familiar, attribute reflection occurs when an attribute in the DOM is updated due to changes in a corresponding property.

A lot of folks conflate attributes and properties, so here's an example.

<!-- This is the open attribute -->
<details open>
  ...
</details>

<script>
  // This is the open property. Changing it will "reflect"
  // back and update the attribute - but not all attributes
  // reflect!
  document.querySelector('details').open = false;
</script>

The pattern of using reflection as a styling API likely emerged out of necessity, as the suggested alternative, Custom States, only recently landed decent browser support.

However, from an HTML purist's perspective, we shouldn't sprout attributes. It's largely considered an anti-pattern because attributes are intended to be an input mechanism that should only be set by the consumer.

This is a sensible argument, but many native elements don't follow this convention. Here are some examples:

The id attribute reflects on all elements
The <details> element reflects the open attribute when expanded
The <dialog> element reflect the open attribute when shown
The <button> element reflects the disabled attribute when disabled
The <img> element reflects the src and alt attributes when set as properties
The <video> element reflects the src attribute when set as a property
The <input> element reflects the type attribute when set as a property
The <progress> element reflects the value attribute when set as a property
The <form> element reflects the action and method attributes when set as properties
The <textarea> component reflects the rows and cols attributes when set as properties

Of course, not all properties reflect. In fact, the rule seems rather arbitrary. For fun, I asked my friendly neighborhood AI — who is more patient and arguably more skilled at deciphering long technical documents then I am — when properties should reflect back to attributes, per the HTML spec.

Reflected properties in HTML are properties that, when changed, update the HTML markup to ensure synchronization between the HTML and the DOM. This allows for changes to be preserved if the page is reloaded or serialized back into a string. The decision to reflect a property is determined by the HTML specification on a case-by-case basis, considering whether the property represents the initial state or current behavior of the element.

It seems there's not an obvious convention to follow. If we're reflecting properties back to attributes to represent an element's initial state, wouldn't those attributes already be set by the author of the HTML?

Besides, some elements reflect their current state, such as <dialog open>, <details open>, <input checked>, etc. This suggests it's OK to reflect attributes to represent state. But if that's what Custom States intends to solve, why didn't these native elements use a state, such as :open?*

So when should we reflect attributes?

I usually prefer to align with the platform, but the platform isn't clear on this one. Because things like this bother me, I'm going to outline some rules I use to determine if an attribute should or shouldn't reflect.

An attribute should reflect when:

It represents a current state that the user can modify and/or may be interested in observing, such as checked, disabled, open, readonly, etc.
It represents a value that affects how the component is styled internally or externally. This allows us to target variants** without using an internal wrapper and/or replicating values internally.
It makes the debugging experience more intuitive for authors and consumers.

An attribute should not reflect when:

The data type is neither string, number, nor boolean.
The value is content or otherwise too cumbersome to store in the DOM, e.g. the content of a text area.
The user is unlikely to have interest in observing the attribute for state or styling purposes.

Notes:

It's OK if an attribute reflects and a custom state is applied. In this case, the consumer can choose how to target it in their own styles.***

*There is a non-zero chance that we are stuck in a perpetual hell for the sake of backwards compatibility. Alas, the lack of an obvious pattern makes it hard to identify a best practice moving forward, and user expectation may be contrary based on prior art.

**I suspect that some folks will disagree with this, so I'll elaborate. If I have a component that supports multiple variants, e.g. primary, secondary, tertiary, the user will typically set an attribute on the element: <my-badge variant="primary">. But what if they set the corresponding property instead because they're using a framework that sets properties instead of attributes? This means we can't rely on :host([variant="primary"]) in our styles, so we either have to a) map the selected variant to classes somewhere internally, possibly requiring a wrapper element that wouldn't be needed otherwise; b) use custom states…except we'd need to add one for every possible variant which isn't ergonomic for authors or end users; or c) use something like a data-variant attribute to…shit, this is the same as attribute reflection.

***Unfortunately, some libraries that use DOM morphing might break custom elements that reflect attributes. As such, it's a good idea to make sure your default styles don't rely on them. For example, if the default styles for <your-button variant="default"> get lost when you remove the variant attribute, you're gonna have a bad time.

Anchoring Software to Major Versions

2024-05-24T00:00:00Z

In a SemVer world, major releases are those which contain incompatible API changes. We often see software projects anchor themselves to major versions for long periods of time, usually with the promise of stability.

We all know how frustrating it is to upgrade a package and run into tons of breaking changes. Many of us have kept outdated software in production for longer than we should just because it can be such a pain to update.

I've been thinking a lot about this lately in the context of open source projects*, and I've come to believe that anchoring to major versions is counterintuitive. It's harder for developers, who have to maintain each distinct version for long periods of time; it's worse for consumers, who eventually get hit with a slew of broken things all at once; and it holds back features and improvements that can't be implemented until breaking changes are made.

Of course, there's something to be said about maintainer discipline. Are we breaking things for a good reason or just because? Do our changes actually benefit the project and its users, or does it just feel better to do it this way now? Every project is maintained differently.**

But the more I think about it, the less it makes sense.

For many projects, major versions should be released more frequently. Things are easier to maintain when the path to upgrading involves less friction; consumers are more apt to retain familiarity with less time in between updates; and developers can stop being scared to do the right thing for fear of a major version bump.

The right kind of breaking changes are good. We should embrace them rather than avoid them.

*I'm aware this logic doesn't apply as well to consumer-facing products where marketing is tied to major version numbers. "Upgrading from 3.x to 4.x? CLICK HERE TO PURCHASE!" These types of major versions are usually more about new features that were held back for the sake of revenue — you can't charge for a new release unless it's a major version! But they otherwise could have been added in a minor release.

**It's your project, do whatever you want. But if your goal is to garner trust and grow a community, maybe think twice about haphazardly changing things.

Building Custom Elements With a Library

2024-03-28T00:00:00Z

I often get asked why I use Lit to build web components. Hands down, it's become my preference after years of working with various libraries and tools. Here's why I use it.

Libraries offer a better DX

This seems like a selfish answer for a developer to lean on, but there are advantages to end users as well. A better developer experience (DX) means I can write components and fix bugs faster. In my experience, a lot faster. Lit, for example, maps attributes to properties automatically, meaning I can omit a ton of extra logic from my code.

Abstractions like this make me more efficient at writing components because I can concentrate on the important stuff. And with less code to worry about, I find components are less prone to bugs. If I had to write those mappings myself, for example, it would get very cumbersome. More code to write, more bytes to load, and more complexity to maintain.

Keeping it DRY

If I were writing vanilla web components, I'd eventually recognize patterns amidst the boilerplate. As any good developer would, I'd split them out and move them into a reusable utility of some sort. That's the DRY thing to do, right?

I've been down that road before. I built my own library to author web components. Declarative templates, reactive data binding, lifecycle hooks — all the shiny things that make building components fun.

I ended up spending more time working on the library than the components. If only there were something out there that did exactly what I was looking for…

Turns out, that was Lit.

Oddly enough, Lit was about the same size as my own library. What I like about Lit is that it's designed to work with the platform, not replace it. Its maintainers are very committed to stability and backwards compatibility, and they have an amazing track record to back this.

For building a one-off custom element, vanilla APIs will work just fine and save you some bytes. But when you start building a collection of them, the size and maintainability arguments fall apart. In my opinion, it's wiser to keep those abstractions well-tested, well-documented, and well-separated from the rest of your code.

Vanilla APIs are intentionally low-level

The APIs that comprise web components aren't like those like you're used to with React, Vue, et al. Remember, the platform evolves slowly because it has to commit to features for many, many years. This is why webpages from decades ago still work in modern browsers.

Web component APIs took a long time to establish. They were designed to be low-level so developers can build on top of them. As a result, vanilla web components tend to have a lot of boilerplate.

You know how you can build React components without JSX?

// without JSX
import { createElement } from 'react';

function Greeting({ name }) {
  return createElement(
    'h1',
    { className: 'greeting' },
    'Hello ',
    createElement('i', null, name),
    '. Welcome!'
  );
}

Sure, it's possible, but isn't this much easier to work with?

// with JSX
function Greeting({ name }) {
  return (
    <h1 className="greeting">
      Hello <i>{name}</i>. Welcome!
    </h1>
  );
}

Extrapolate this concept to more complex components. Which would you rather build and maintain? In some ways, Lit is to web components what JSX is to React. You can build things without it, but I wouldn't recommend it.

At the end of the day, the way a web component is built is an implementation detail. I can swap out Lit for any other library and, as long as I don't change the public API of my components, most users would never notice.

They're just HTML elements, after all.

Design Systems Are An Investment

2023-11-28T00:00:00Z

It's hard to put a value on a design system. It's a lot easier to add up the costs of said design system, especially in terms of salaries and development time. It's even easier to target a design system as the thing that's holding up a product from getting delivered.

The truth is, design systems aren't made to slow you down or piss you off, they're made to make you more productive. What a lot of organizations fail to understand is that the initial investment pays dividends later on. Well-designed components, patterns, and guidelines take time. But they always result in better products.

Your design system shouldn't be a target. It should be a beacon.

But design system teams are usually siloed. They tend to live higher up in the org chart because they make decisions that affect every product underneath them. They're often so segmented from the rest of the organization that they become barriers to their own users.

I used to think that design system teams were special and that they needed to live up there, but I don't think that's necessarily true anymore. Yes, you need support from management, but you can't rule from the top down with an iron fist. It must be a team effort. Respect has to be mutual for everything to work.

Break down the barricades, the fences, and the walls. Make your design system team accessible to their consumers. Fund them properly so they have the resources to meet the objectives you've set for them. Educate consumers so they understand the benefits, the expectations, and the workflows that will make collaboration with your design system team a success.

I know it's easy to blame the design system for holding things up. Everyone loves a scapegoat. But don't let today's needs interfere with tomorrow's progress. Understand what it means to invest. Understand the importance of working together to break out of impasses.

And design system teams — offer some grace to your users. Your job is to create guidelines, not to enforce them religiously. When consumers color outside the lines, your first instinct shouldn't be to strike them down, but to understand why and facilitate their needs in a way that benefits everyone moving forward.

No, you won't see an immediate payoff from any of this. But anyone who's played this game long enough knows that a quick win today isn't nearly as a good as an investment that pays dividends for years to come.

If it's unclear what that means, investing in your design system now will mean more consistency, more productivity, improved code quality, less bugs, less maintenance burdens, and happier teams.

In the words of Peter Lynch: "Know what you own, and why you own it."

How to File a Bug Report

2023-11-21T00:00:00Z

They say there's no such thing as bug-free code. When problems arise, creating a minimal reproduction will give you the best chance of a speedy resolution.

When a potential bug is discovered, many developers' first reaction is to file an issue. That's great, but please exercise due diligence before posting! Have you reviewed the docs to confirm the behavior in question? Are you able to reproduce the bug outside of your app? Have you removed all unrelated code to make sure nothing else is causing the problem?

I get it — creating a reproduction takes time! Why should that be on you if the bug is upstream? The thing is, the process of creating a minimal reproduction will often uncover the problem and, in many cases, the problem will be in your own code. I know that sounds arrogant but, as an open source maintainer, I see it happen quite frequently.

Help Us Help You

That's not to say our libraries don't have bugs…they totally do! We're just asking you to help diagnose the problem before we spend hours diving into your code only to realize it's not something we can fix in our code.

If you're using our software, we've already provided some kind of value to you. It's not fair to ask us to troubleshoot your app. Maintainers generally want to eliminate bugs from their software, but triaging issues can be a painstaking task, especially in larger projects.

Even if your bug report is completely valid, an issue that lacks sufficient information — or has too much of the wrong information — can easily fly under the radar for many reasons.

Think of it from a maintainer's perspective. You wake up in the morning to three new bug reports:

Bug #1 – doesn't have enough information, just a screenshot of the suspected problem and a line of text that vaguely describes it.
Bug #2 – has multiple screenshots of CI output and VS Code windows, but nothing else.
Bug #3 – has a clear description of the problem and a minimal reproduction. The submitter has thoughtfully included all relevant information pertaining to the issue.

Which one would you be most willing to resolve first?

Better Bug Reports

Here are some tips to help you get results faster. Investing a bit of time up front will usually lead to a more positive result. After all, there's nothing worse than watching your issue collect dust.*

Do

Be courteous and responsive
Search for existing issues
Provide all the information necessary to reproduce the problem
Provide a minimal reproduction when it makes sense
Taper your expectations — many maintainers do this for free!

Don't

Include information that doesn't pertain to the bug
Include multiple bug reports in the same issue
Be rude to maintainers or anyone else involved
Spam the maintainers with follow ups
Point fingers or blame others — it's just not productive

Just for Fun

In case you were wondering, here's how maintainers tend to feel when various bug reports are filed. 🤣

*Unfortunately, some maintainers are simply unresponsive. In my experience, the majority of open source authors care about their projects and want to be good stewards. Sometimes it can help to offer a bounty or, better yet, a PR. Alas, I've seen really good PRs collect dust too. In that case, you might need to consider forking the project or finding an alternative.

Thoughts on Framework Churn

2023-11-16T00:00:00Z

I often worry about framework churn. A lot. But using a framework isn't a bad thing. After all, they save time. They help you build things faster.

Yes, there are costs associated with frameworks later on, especially as new versions come out and your app instantly feels like legacy software. It can be exhausting trying to keep up, especially when your work schedule doesn't account for that type of maintenance.

While the upfront savings of using a framework offsets much of the eventual cost of its churn, there might be ways to reduce it even more.

A Tale of Churn

Over the years, I've become somewhat averse to frameworks because I've had bad experiences with churn. One time, I wrote an app using Vue 2 and, less than a year later, Vue 3 shipped. I went to upgrade and realized that Element, the Vue-based component library I was using, didn't support Vue 3! I was stuck, unless of course I wanted to swap out every single UI component in the app.

Eventually, Element released a version for Vue 3, but then I had to deal with breaking changes from both the framework and the component library. It felt like absolute chaos and I never want to deal with that again.*

It's easy to say "fuck frameworks" out of frustration, but that's not a realistic option. Modern apps expect too much to write everything from scratch. Yes, the Web platform is getting more and more amazing features, but many APIs are intentionally lower level. Frameworks smooth out those rough edges and tend to provide better DX.

The Age of Metaframeworks

As React, Vue, et al continue to evolve, we're seeing more and more metaframeworks pop up. It's almost as though you can't be successful as a framework without having a metaframework. React has Next.js and Remix. Vue has Nuxt.js. Angular has Analog. Svelte has SvelteKit. Solid.js has SolidStart.

This seems like complete madness to me. We're building abstractions on top of abstractions, further locking users into those ecosystems and making churn more of a problem than ever.

Sure, the box looks nice and shiny on the outside but, once you take the shrinkwrap off, there's a lot of stuff inside that won't age well. Many developers don't realize this until it's too late. Or maybe they just don't care.

In this industry, you don't win by building well-architected apps. You win by shipping fast and moving on. It will be someone else's problem soon, so fuck it. We used to joke about the Web being the wild west of the programming world, but it really is.

Tread Lightly

I've been thinking about this for a long time and I believe the compromise is to use whatever framework you like, but don't go all in on it. Consider avoiding metaframeworks. Avoid component libraries that aren't interoperable. (This is one place web component libraries such as Shoelace shine, because they work everywhere and won't break as frameworks evolve.) Avoid building every possible piece of your app in a framework-specific way and try to make the important chunks more portable.

Each framework is different and it's probably impossible to codify this advice, so I'm not going to attempt to. What I will say is, as you develop your app, consider the effort it would take to swap out your current framework for another. Would it be trivial or would it require a complete rewrite? Which pieces will be reusable and which pieces will need to be redeveloped?

Frameworks save you a lot of time up front, so consider using some of that time to architect your application more thoughtfully. Allow your app's concerns to be separated in such a way that the important pieces of it are more portable than if you were to write it in and for the framework.

I care about my craft. I care about the quality and maintainability of the things I create. Sometimes that means choosing the hard right over the easy wrong. While some level of framework churn is inevitable, a well-designed application can alleviate a lot of that pain later on.

*"But Cory, you wouldn't have that problem if you used React!" React has its own problems. It started with class-based components, then the world switched to hooks and class components were suddenly shit and if you used them you were a second-class developer. Now React Server Components are the hot new thing and everyone's pivoting towards that shiny thing. React may not seem to churn as much, but its paradigms certainly do.

Better Buttons with color-mix() and Custom Properties

2023-08-23T00:00:00Z

Let's build a button that accepts one color and calculates its hover and focus states automatically. For this experiment, we'll use CSS Custom Properties, color-mix(), and OKLCH to ensure that tints and shades are perceptually uniform.

To keep things simple, we'll follow today's flat design trend and use a single color for the background. We'll store that color in a custom property so we can reuse it and change things up as we go.

Let's kick things off with some styles.

/* Set some defaults for the button */
:root {
  --button-bg: slategrey;
}

/* Remove factory button styles and add our own */
button {
  unset: all;
  font: 16px sans-serif;
  border: none;
  border-radius: 6px;
  background-color: var(--button-bg);
  color: white;
  padding: .875rem 1.125rem;
  margin: 0;
  cursor: pointer;
  transition: 100ms background-color;
}

/* Tint the background when hovering */
button:hover {
  background-color: color-mix(in oklch, var(--button-bg) 100%, white 8%);
}

/* Shade the background when clicked */
button:active {
  background-color: color-mix(in oklch, var(--button-bg) 100%, black 4%);
}

/* Remove the default focus ring */
button:focus {
  outline: none;
}

/* Provide a color-matched focus ring for keyboard users */
button:focus-visible {
  outline: solid 3px var(--button-bg);
  outline-offset: 1px;
}

We're using a custom property called --button-bg that sets the button's background. Using a custom property allows us to pass it into the color-mix() function to calculate the hover and active states. This also allows us to use it again to make a color-matched outline for the focus state.

The magic is here:

/* Tint the background when hovering */
button:hover {
  background-color: color-mix(in oklch, var(--button-bg) 100%, white 8%);
}

/* Shade the background when clicked */
button:active {
  background-color: color-mix(in oklch, var(--button-bg) 100%, black 4%);
}

Using color-mix(), we can adjust the tint/shade based on the background color, meaning we don't need to manually select lighter/darker colors for those states. And because we're using OKLCH, the variations will be perceptually uniform, unlike HSL. This means that tints and shades will look consistent for any color we choose!

Oh, and because we're using a custom property, we can easily test that theory by setting --button-bg to any color. Note how the hover and focus states update accordingly in this example.*

See the Pen Color mix with buttons by Cory LaViska (@claviska) on CodePen.

The caveat is browser support for color-mix(), which is green across the board, but still somewhat recent. However, I would argue that this is a great candidate for progressive enhancement, as the absence of color changes on hover and click doesn't affect the function of the button.

Not bad for a few lines of CSS!

*Alas, we can't automatically ensure the label's contrast based on the background color, but when CSS Color Module Level 5 lands, we'll get relative colors that will allow us to do just that!

Dynamic Slots

2023-07-19T00:00:00Z

Web Component authors already know how powerful slots are, but what if you could do even more with them? Here's an interesting technique to use (or abuse) slots in your custom elements. I've been calling the pattern dynamic slots.

Before we dive in, let's take a quick look at how slots actually work. Here's a custom button with a label and an image.

<my-button>
  Click me
  <img slot="icon" src="..." alt="...">
</my-button>

And let's imagine this is the button's template, which will be rendered in a shadow root.*

<template>
  #shadow-root
    <button type="button">
      <span class="icon">
        <slot name="icon"></slot>
      </span>

      <span class="label">
        <slot></slot>
      </span>
    </button>
</template>

If you're wondering why one slot has a name and the other doesn't, that's because there are two types of slots! By default, all content goes into the aptly named default slot — the one without a name attribute.

Elements with a slot attribute, however, will go inside of the corresponding named slot. A named slot is simply a slot with a name attribute. In this case, the <img slot="icon"> will be "slotted" into the named slot <slot name="icon">.

If you're feeling comfortable with everything up to this point, you're ready to move onto the next section. Otherwise, I'd suggest reading more about templates and slots before continuing.

Making Things Dynamic

Since slots can be named arbitrarily, we have a lot of flexibility here. And since there's no limit as to how many can exist in a shadow root, we can do some pretty interesting things. Here's another contrived example. This time, we'll build a custom element grid that accepts an [oversimplified] attribute of columns and rows.

Under the hood, the grid will render a <table> based on the provided attributes. For brevity, we'll use Lit to build it and the markup to use it will look like this.

<my-grid cols="a,b,c,d,e" rows="1,2,3,4,5"></my-grid>

Inside the custom element, our render function will look something like this.

render() {
  const cols = this.cols?.split(',') ?? '';
  const rows = this.rows?.split(',') ?? '';

  return html`
    <table>
      <thead>
        <tr>
          <th></th>
          ${cols.map(col => html`<th>${col}</th>`)}
        </tr>
      </thead>
      <tbody>
        ${rows.map(row => html`
          <tr>
            <th>${row}</th>
            ${cols.map(col => html`
              <td>${col + row}</td>
            `)}
          </tr>
        `)}
      </tbody>
    </table>
  `;
}

See the Pen Web Components: dynamic slots in a custom grid (part 2) by Cory LaViska (@claviska) on CodePen.

Notice how the user isn't slotting in each cell declaratively. Instead, they're generated imperatively based on the columns and rows provided to the element.**

Given this API, how can we let users slot in custom content for specific cells? In a real data grid, we'd probably pass an array of objects like this to populate the grid.

grid.rows = [
  { id: 1234, content: 'Content from data store' },
  // ...
];

We could ask users to loop through the data and modify content as needed, but that seems sloppy. It would be better to offer a declarative API, so let's modify our example to make use of dynamic slots!

We'll start by wrapping each cell with a named slot using the cell:{col}{row} convention, so a slot named cell:a1 will target the first row in the first column of the grid. The custom element's template will look like this now.

render() {
  const cols = this.cols?.split(',') ?? '';
  const rows = this.rows?.split(',') ?? '';

  return html`
    <table>
      <thead>
        <tr>
          <th></th>
          ${cols.map(col => html`<th>${col}</th>`)}
        </tr>
      </thead>
      <tbody>
        ${rows.map(row => html`
          <tr>
            <th>${row}</th>
            ${cols.map(col => html`
              <td><slot name="cell:${col + row}">${col + row}</slot></td>
            `)}
          </tr>
        `)}
      </tbody>
    </table>
  `;
}

The magic behind dynamic slots exists right here.

<slot name="cell:${col + row}">

This results in a slot for every single cell that we can target in our HTML! Thus, the new markup will look like this.***

<my-grid cols="a,b,c,d,e" rows="1,2,3,4,5">
  <!-- you can slot in as many or as few cells as you like -->
  <span slot="cell:b3">foo</span>
  <span slot="cell:d4">bar</span>
  <span slot="cell:e2">baz</span>
</my-grid>

See the Pen Web Components: dynamic slots in a custom table by Cory LaViska (@claviska) on CodePen.

In this example, we used dynamic slots to let users customize the content of each cell. Remember that you can move the slot around, though! Perhaps you only want users to append content instead of replacing it entirely. In that case, you'd render the cell's content and then follow it with a dynamic slot. Or maybe you only want certain columns to be customizable, in which case you'd only render the slot in cells within those columns.

Perhaps a more realistic example is a date picker you want to add date-specific labels or icons to. The use cases tend to be quite specific, but dynamic slots can be really useful when you're iterating data and want to sprinkle in declarative customizations in a way regular slots just can't.

Anyways, that's the gist of dynamic slots!

Suggested Naming Convention

If you choose to follow this pattern, I'd suggest using a colon to delimit the slot's primary name and it's positional name.

<slot name="item:1"></slot>
<slot name="item:2"></slot>
<slot name="item:3"></slot>
...

This feels cleaner than item-n and makes it a bit easier to document, especially if you use other dashes in slot names. Of course, this is by no means a requirement!

Caveats

"Just because you can, doesn't mean you should" applies here. Here are some reasons you might want to avoid this pattern.

Dynamic slots, like most declarative things, result in more HTML. Use them sensibly to avoid long load times.
More slots means more DOM footprint, so you might run into performance issues if you get too crazy with it.
Some folks might consider this an anti-pattern. I understand that perspective, but there seem to be use cases where dynamic slots make a lot of sense.

*The button example is a bit contrived, but try to imagine a more complex component. The spans aren't strictly necessary, but they help demonstrate the fact that slots can be rendered anywhere in a template.

**This is a common pattern for data grids and other components that render large amounts of data from a data store. Component authors could offer a declarative API that lets consumers slot in columns and rows, but this usually requires more effort from the author and the end user because authors need to do the work to watch/parse the slotted content and end users need to massage raw data into a custom, table-like API. It's not fun for anyone.

***In a real world application, you probably wouldn't use col:row for naming dynamic slots. An id is a much better way to link database records to slots.

My Commitment to Accessibility

2023-06-02T00:00:00Z

I recognize the need for all users, regardless of ability or device, to have undeterred access to the websites and applications that are created with my software. This is an important goal of my projects.

Oftentimes, people will ask "is it accessible?" I'm reluctant to answer because accessibility isn't binary — there's no simple "yes" or "no" response to provide. What seems accessible to a sighted user might be completely inaccessible to a non-sighted user. And even if you optimize for various screen readers, you still have to account for low-level vision, color blindness, hearing impairments, mobility impairments, and more.

Accessibility is something you have to continuously strive for. No individual contributor — or perhaps even an entire team — can claim their software is 100% accessible because of the sheer diversity of abilities, devices, assistive technologies, and individual use cases.

Furthermore, accessibility doesn't stop at the component level. Using accessible building blocks doesn't magically make the rest of your webpage or application compliant. There is no library or overlay that will make your software "fully accessible" without putting in the effort.

My commitment to my users is this: everything I develop will be built with accessibility in mind. I will test and improve my software to the best of my ability and knowledge. I will work around upstream issues, such as browser bugs and limitations, to the best of my ability and within reason.

I'm fully aware that I won't get it right every time for every user, so I invite the community to participate in this ongoing effort by submitting issues, pull requests, and discussions. Many accessibility improvements have already been made thanks to contributors submitting code, feedback, and suggestions.

This is the path forward. Together, we will continue to make accessible software for as many users as possible.

— Cory LaViska

Converting a URL Object to a Plain Object in JavaScript

2023-03-22T00:00:00Z

I needed to convert a URL object to a plain object yesterday. You might have used it before. It's pretty handy for working with URLs!

const url = new URL('https://example.com/');

console.log(url);

// URL {origin: 'https://example.com', protocol: 'https:', username: '', password: '', host: 'example.com', …}

Alas, you can't provide a URL object as data to Handlebars for security reasons. Essentially, allowing prototype properties in that context can lead to arbitrary code execution, which we definitely want to avoid.

So the solution is simple! Turn the URL object into a plain object and pass that to Handlebars instead. Surely we can destructure it and move on.

const url = new URL('https://example.com/');
const plainObject = { ...url };

console.log({ ...url });

// {}

Weird. It's empty. Let's try iterating over its keys instead. If we have the keys, we can loop through them and generate a plain object that way.

const url = new URL('https://example.com/');

console.log(Object.keys(url));

// []

An empty array? Oh, right, URL uses Symbol internally so we have to use getOwnPropertySymbols().

const url = new URL('https://example.com/');

console.log(Object.getOwnPropertySymbols(url).map(key => url[key]))

// []

Ugh, it's still empty? What type of black magic is this?! Fine. Surely we can use Reflect to get the keys.

const url = new URL('https://example.com/');

console.log(Reflect.ownKeys(url))

// []

Well, that's lame. Might as well do it the hard way…

const url = new URL('https://example.com/');
const plainObject = {
  hash: url.hash,
  host: url.host,
  hostname: url.hostname,
  href: url.href,
  origin: url.origin,
  password: url.password,
  pathname: url.pathname,
  port: url.port,
  protocol: url.protocol,
  search: url.search,
  searchParams: url.searchParams,
  username: url.username
}

console.log(plainObject);

// {hash: '', host: 'example.com', hostname: 'example.com', href: 'https://example.com/path/to/file.ext', origin: 'https://example.com', …}

Well, this is what we want, but it's verbose and unreliable if future properties are added. Surely there must be a better way. After throwing this question over to Konnor Rogers, he found a solution.

const url = new URL('https://example.com/');

console.log(Object.getOwnPropertyNames(Object.getPrototypeOf(url)));

// (15) ['origin', 'protocol', 'username', 'password', 'host', 'hostname', 'port', 'pathname', 'search', 'searchParams', 'hash', 'href', 'toJSON', 'toString', 'constructor']

(Cue the "doh!" moment…) 🙈

Well, we finally have the keys so we can create a new object using them. Here's a function that neatly wraps the conversion up.

function urlToPlainObject(url) {
  const keys = Object.getOwnPropertyNames(Object.getPrototypeOf(url));
  const plainObject = {};

  for (key of keys) {
    plainObject[key] = url[key];
  }

  return plainObject;
}

const url = new URL('https://example.com/');

console.log(urlToPlainObject(url));

// {origin: 'https://example.com', protocol: 'https:', username: '', password: '', host: 'example.com', …}

Well, that was harder than it needed to be. Thanks, Konnor!

Update (March 23, 2023)

Special thanks to Nick Williams who discovered an even simpler approach.

const url = new URL('https://example.com/');

for (field in url) {
  console.log(field);
}

// (14) ['origin', 'protocol', 'username', 'password', 'host', 'hostname', 'port', 'pathname', 'search', 'searchParams', 'hash', 'href', 'toJSON', 'toString']

You might notice there are 14 fields instead of the original 15 now. That's because the constructor property is omitted, which we didn't really want anyways. An updated version of our function looks like this, and it also discards the other non-string properties now.

const url = new URL('https://example.com/');

function urlToPlainObject(url) {
  const plainObject = {};

  for (const key in url) {
    if (typeof url[key] === 'string') {
      plainObject[key] = url[key];
    }
  }

  return plainObject;
}

console.log(urlToPlainObject(url));

// {origin: 'https://example.com', protocol: 'https:', username: '', password: '', host: 'example.com', …}

I have no idea why I didn't try a for loop in the first place. 😅

The Term "Headless Component" is a Misnomer

2023-01-25T00:00:00Z

You've likely heard the term "headless component" tossed around. The idea is you get solid, accessible components without any styles. A clean slate to style from scratch! But the structure (bones) and logic (head) are there. You're mostly adding styles.

They should be called "skinless components."

And the thing about headless components is that, in my experience, people actually don't want to start from scratch. It's much, much easier to start with sensible base styles and customize from there.

This is exactly what CSS was designed to do.

Libraries such as Shoelace makes this easy for you. Its default theme has opinions for the sake of ease and consistency, but you can override them at a high level (design tokens) and/or at a low level (components) to achieve the look you want without having to write all the styles yourself.

Even HTML elements aren't headless

User agents ship a default stylesheet that controls the appearance of most elements. We sometimes "reset" them, which is another misnomer because we're usually just normalizing the defaults that vary between browsers.

But I digress…

I'm really happy that we're paying more attention to how things work and not just how they look. As web devs, we've come a long way, especially in terms of accessibility and performance, but we seem to go from one extreme to another.

It's OK when off the shelf components have opinions because it results in a lot less work!

But what's important is that those opinions can be easily changed to work for your needs, preferably through a common and familiar syntax like CSS.

Take it from someone who's built hundreds of components over the years. You rarely want to style third-party components 100% from scratch. There's too much room for error. There are too many details and edge cases you're not going to get right.

Default styles gives you a safety net

Despite all that, headless components aren't bad! Any time you can avoid reinventing the wheel, you should. But if you want to spend more time building things and less time styling UI primitives, choose something that already has styles and sprinkle in your own customizations.

One thing I will caution you to look out for is what I call "Bootstrap syndrome." This occurs when you use a library's default styles with little to no customizations whatsoever. Your site ends up looking like every other site that uses Bootstrap as-is.

This phenomenon started when devs would pull in bootstrap.min.css from a CDN only to realize it wasn't easy to customize without Sass and a build step or a lot of CSS. So they didn't.

That problem has mostly been solved with CSS vars, but you still need to do the design work.

Another consideration is, when you're not doing things from scratch, you can start building right away and incrementally improve the design as you go. That sounds like a huge win to me.

Making a choice

So you're left with:

Roll components & styles from scratch (bespoke)
Roll styles from scratch (headless)*
Only customize the things you need (e.g. Shoelace)

There's an element of design involved no matter what, but only one option lets you start building right now.

*But Cory, [headless lib] has themes I can pick from! If you're going to go headless, this is how you should start. Pick a theme, preferably one that's very comprehensive, and start there. But keep in mind that third-party themes may be buggy or incomplete too!

This post was originally a Twitter thread.

Shoelace 2.0

2023-01-24T00:00:00Z

It's been three years since I broke ground on Shoelace 2.0. Between then and now, the project has amassed over 300 million monthly hits on jsDelivr and, as of today, it is jsDelivr's 73rd most popular project.

And that was just the beta version.

Today, I'm happy to announce that the first stable release of Shoelace is finally available!

First and foremost, I'd like to say thank you to all my users. I've poured my heart and soul into this library and I'm thrilled to see so many people building with it. You continue to inspire me every day!

For those unfamiliar, Shoelace is a free, open source library of Web Components you can use to build websites and web applications. There are over 50 accessible, handcrafted user interface components to choose from, and you can use them in any framework you want!

Why Choose Web Components

Web Components are built using Web Standards, meaning they don't require a framework to use. You can think of them as custom HTML elements, because that's exactly what they are!

And because they're just HTML elements, you can use them in any framework you want, such as React, Vue, Angular, Svelte, Solid, and more. This makes Web Components a great candidate for your next design system! In fact, Shoelace acts as a design system starter kit, allowing you to customize it to suit your needs.

Shoelace is built with accessibility in mind and comes with both light and dark themes out of the box. Why spend months building your own UI primitives (i.e. buttons, dialogs, form controls, tabs, etc.) when you can get dozens of battle-tested components and start building with them right now?

I invite you to learn more about Web Components to better understand how you and your organization can benefit from them.

What's Next

While this release is a major milestone for Shoelace, I feel like we're still just getting started. There's always more to do — more features, more tests, more polish — and with the support of the amazing folks at Font Awesome, we're going to deliver an incredible amount of value in the coming year.

Sorry, no spoilers! But you'll be hearing a lot about Shoelace as we continue our journey to become everyone's favorite open source Web Component library.

Before I go, I'd like to share some interesting stats about this release!

Shoelace 2.0 in Numbers

Development of Shoelace 2.0 started in January 2020. The first beta was released on July 15, 2020. Since then, Shoelace has grown quite a bit! Here's a look at some stats from the project.*

55 components have been built
Over 2,500 commits have been made to the project
85 people have contributed to the project
669 issues have been filed on GitHub
274 pull requests have been opened
More than 150 discussions have been started on GitHub
Over 500 people have joined the Shoelace community on Discord
Over 300 million CDN hits per month
Over 13,000 npm downloads per week
73rd most popular project on jsDelivr
#2 product of the day on Product Hunt (July 25, 2020)

*Stats recorded on January 24, 2023

Special Thanks

I'd like to extend a very special thank you to every single contributor who worked to make this possible. Everyone who's filed a bug, submitted a PR, requested a feature, started a discussion, helped with testing, and advocated for the project. You are just as responsible for Shoelace's success as I am. I'd also like to thank the folks at Font Awesome for recognizing Shoelace's potential and believing in me to make it happen.

Thank you! And keep building awesome stuff!

This post was originally published on the Font Awesome blog.

Installing Shoelace in a React App

2022-12-15T00:00:00Z

Although Shoelace is a web component library, it ships React wrappers that lets you use the library idiomatically in React. This video shows you how to install Shoelace in a brand new Create React App.

If you found this video helpful, please subscribe to my channel on YouTube and follow me on Twitter for more helpful Shoelace tips!

Why You Should Prefix Custom Events

2022-12-12T00:00:00Z

Similar to how every custom element must contain a dash, I like to pretend that every custom event must also contain a dash. This removes all ambiguity between native events and custom events.

Therefore, I prefix all custom events in Shoelace with sl-. It may seem contradictory that I've chosen to follow the platform's convention for emitting events but not for naming them. There's a good reason, though.

To preserve encapsulation, events that emit from within a shadow root are retargeted so they appear to come from the host element. If a custom element has three buttons in its shadow root, a click on any of those buttons will appear to come from the host element, as demonstrated below.

<!-- A custom element with three buttons in its shadow root -->
<three-buttons></three-buttons>

<script>
  // Define the custom element
  class ThreeButtons extends HTMLElement {
    constructor() {
      super();
      this.attachShadow({ mode: 'open' });

      // There are better ways, but for brevity…
      this.shadowRoot.innerHTML = `
        <button type="button">First</button>
        <button type="button">Second</button>
        <button type="button">Third</button>
      `;
    }
  }

  // Register it
  customElements.define('three-buttons', ThreeButtons);

  // Notice how the target is the same, regardless of which button you click?
  document.querySelector('three-buttons').addEventListener('click', event => {
    console.log(event.target);
  });
</script>

Try it on CodePen

Retargeting is necessary and sometimes even convenient but, because of it, you might observe a seemingly endless number of events getting emitted from the host element as the user interacts with its internals.

So how can you differentiate a click event emitted by an internal element from a custom click event emitted by the host?

You can't rely on the event phase because it will show AT_TARGET. You probably shouldn't use Event.composedPath() because that breaks encapsulation, relies on private structures that can change, and doesn't work for closed shadow roots.

(Flips table over and walks out)

To do this, devs would need to listen to and prevent every event that might be retargeted from any applicable element inside the shadow root, and then re-emit an even of the same name with some kind of payload in event.detail to help differentiate. This would mean a lot of unnecessary code and clutter, and even the most astute custom element authors will fail to get it right from time to time.

Instead, you can simply prefix custom events to sidestep this problem.*

Another benefit of prefixing is that, in the context of a web component library, it's immediately clear which events belong to a particular library. It's fairly obvious that sl-change is a Shoelace event, for example.

*It could be argued that one shouldn't prefix custom events and should instead prevent retargeted events from conflicting with custom events, but I avoid this pattern because it breaks the expectation that consumers may have for handling retargeted events.

Custom Event Names and the Bubbling Problem

2022-12-12T00:00:00Z

The topic of custom element event names comes up every now and then, especially from Shoelace users who get confused when events of the same name are emitted from different components.

Take <sl-details>, <sl-dialog>, and <sl-dropdown>, for example. They all emit sl-show and sl-hide events, allowing you to hook into their lifecycle as they open and close. Occasionally, someone will nest a component inside another, listen for an event such as sl-hide, and wonder why the callback executes at the "wrong time."

In this example, you can see that we have an <sl-dropdown> inside of an <sl-dialog>. Both of these components emit sl-show and sl-hide events.

<sl-dialog label="Dialog">
  <!-- Note how the dropdown is nested inside the dialog -->
  <sl-dropdown>
    <sl-button slot="trigger" caret>Open and close me</sl-button>
    <sl-menu>
      <sl-menu-item>Option 1</sl-menu-item>
      <sl-menu-item>Option 2</sl-menu-item>
      <sl-menu-item>Option 3</sl-menu-item>
    </sl-menu>
  </sl-dropdown>
</sl-dialog>

<sl-button id="open">Open Dialog</sl-button>

<script>
  const dialog = document.querySelector('sl-dialog');
  const openButton = document.getElementById('open');

  // Show the dialog when the button is clicked
  openButton.addEventListener('click', () => dialog.show());

  // Listen for the sl-show event
  dialog.addEventListener('sl-show', event => {
    console.log('The dialog has opened…or has it?')
  });

  // Listen for the sl-hide event
  dialog.addEventListener('sl-hide', event => {
    console.log('The dialog has closed…or has it?')
  });
</script>

Try it on CodePen

The logic above is faulty because it runs when the dialog or any of the dialog's children emit the sl-show or sl-hide event. This occurs due to event bubbling, which is an incredibly useful feature of the platform. When events bubble up, listeners on ancestor elements will execute. This enables an extremely useful feature called event delegation.

Alas, this is also a source of confusion.

Fortunately, there are a number of easy ways to work around it.

Checking the Target

Events are emitted with a target property that you can inspect to determine which element emitted it. Thus, we can modify the handlers from the previous example to ensure the target is the same dialog we attached the listener to.

// Listen for the sl-show event
dialog.addEventListener('sl-show', event => {
  if (event.target === dialog) {
    console.log('The dialog has opened')
  }
});

// Listen for the sl-hide event
dialog.addEventListener('sl-hide', event => {
  if (event.target === dialog) {
    console.log('The dialog has closed')
  }
});

Try it on CodePen

Checking the Current Target

Another way is to compare Event.currentTarget, which effectively does the same thing.

// Listen for the sl-show event
dialog.addEventListener('sl-show', event => {
  if (event.target === event.currentTarget) {
    console.log('The dialog has opened')
  }
});

// Listen for the sl-hide event
dialog.addEventListener('sl-hide', event => {
  if (event.target === event.currentTarget) {
    console.log('The dialog has closed')
  }
});

Try it on CodePen

Checking the Event Phase

Here's yet another way to ensure the event was emitted by the expected element. It's a bit more verbose, but it doesn't require a reference. Instead, we can inspect Event.eventPhase to determine which phase the event is in. In this example, the listener is attached directly to the dialog, so we're interested in the AT_TARGET phase.

// Listen for the sl-show event
dialog.addEventListener('sl-show', event => {
  if (event.eventPhase === Event.AT_TARGET) {
    console.log('The dialog has opened')
  }
});

// Listen for the sl-hide event
dialog.addEventListener('sl-hide', event => {
  if (event.eventPhase === Event.AT_TARGET) {
    console.log('The dialog has closed')
  }
});

Try it on CodePen

Why Not Use Unique Event Names?

It has been proposed numerous times that custom elements should emit events with unique names to avoid such confusion. For example, instead of emitting sl-show for multiple components, event names might be named based on their tag, e.g. sl-dialog-show and sl-dropdown-show.

I appreciate the idea, but this just isn't how events works. If you click a <button> you get a click event, not a button-click event. If you set focus to an <input>, you get a focus event, not an input-focus event. Besides, you still wouldn’t be able to differentiate the target element this way since elements of the same type can often be nested inside others.

For the sake of consistency with the platform, I consider this suggestion an anti-pattern that should be avoided in custom elements. Instead, developers must understand that many events bubble — including native ones — and they should be doing these checks any time elements are nested to avoid unexpected behaviors.

This problem isn't exclusive to custom elements.

The Future of Shoelace

2022-10-17T00:00:00Z

It's been more than two years since the beta release of Shoelace 2.0, which was the first version of the project to ship Web Components. What started off as a fun side project has quickly grown to become one of the most recognized Web Component libraries in the world. As of today, Shoelace receives more than 100 million monthly CDN hits on jsDelivr, and that number continues to grow.

Thank you for that. I've poured my heart and soul into this library and I'm honored by the overwhelmingly positive feedback Shoelace receives on a daily basis.

But today, I want to talk to you about the future.

Shoelace is and always has been a side project. I spend a lot of time maintaining it because I enjoy working on it. However, the effort I put into Shoelace is in addition to my full-time position as a technical lead at Microsoft.

Lately, I haven't been able to find enough spare time to move the project forward. The more hours I carve out to work on it, the less I have for myself and my family. I've been careful not to burn out. I take breaks when I need to. But there's so much more that needs to be done.

Shoelace has reached the point where it demands a full-time effort, otherwise its potential will never be realized. That's why I've decided to bid farewell to Microsoft in November.

To be honest, that's a really, really hard thing for me to say. Microsoft has been great to me. I have an amazing manager, we've built a fantastic team, and I get to work with Web Components every day! In many ways, it's a dream job and that makes it very hard to give up — especially for an open source project that doesn't have any revenue.

If that seems crazy, well, there's a bit more to the story. Let me explain…

A few months ago, I found myself on a plane to Bentonville, Arkansas to meet with the folks who created Font Awesome. We spent days talking about Web Standards, open source, and Shoelace. I had a great time and learned a lot about their values and how they were able to turn an open source project into a sustainable business.

What came of that trip was something I never expected — an opportunity to work on Shoelace full-time. I thought about it long and hard and ultimately decided that, given my current obligations, I can't do this all on my own anymore. And who better to team up with than an amazing group of people who have been there and done it before?!

It's bittersweet, but as I close this chapter at Microsoft, I will be starting a new chapter with the folks at Font Awesome. I will be responsible for building Shoelace into a sustainable open source project under their expert guidance.

You can expect the same commitment to open source as always! But now, with my full attention and more resources, you'll get bug fixes even faster; you'll get features I've wanted to build for a very long time; and you'll get even more as Shoelace continues to grow!

Thank you for your support and contributions up to this point. The last two years have been an amazing journey for me, and I'm very excited to see what the future holds.

If you're not following Shoelace on Twitter, now would be a good time to hit the button to keep up with the latest news.

Hang on, everyone! Shoelace is about to get even more awesome.

A Web Component Story

2022-09-30T00:00:00Z

Gather 'round, it's story time.

A number of years ago, I was hired by a company to rebuild a component library for their design system. The one they were replacing was built with AngularJS, but AngularJS was old and rickety and nobody wanted to use it anymore. Plus, many teams had moved on to other frameworks and one team even preferred doing everything with vanilla JS.

But the company couldn't hire for AngularJS. There was no talent available. Devs had moved on. Nobody wanted to work with a "legacy framework."

So they had to build something new to get out of that ecosystem. They talked about building a new component library in modern Angular. Or maybe React. A handful of engineers wanted Vue.

But they knew that whatever framework they chose, they would be locking teams into it or forcing them to build their own components. This would mean duplicating effort and risking stylistic and behavioral deviations — an inevitable side effect of competing libraries.

They also knew that they'd be doing this again in a few years if they picked any of today's popular frameworks, so they decided to give Web Components a try.

So that's what we built, and that's what they still use to this day. It no longer matters if their teams want to build with React, Vue, Svelte, Solid, or whatever tomorrow brings.

Nobody is forced to use a specific framework
Nobody needs to reinvent UI primitives
Upgrading or switching frameworks is much easier
No duplicate efforts

At this point, you might be thinking "we only use React, so who cares?" And you can get away with that for awhile, especially if you're a single team or a small shop. I get it. React feels good and it's sticky. But all frameworks eventually fizzle out.

Thanks to Web Components, large companies are realizing you don't need to rebuild buttons and other UI primitives every few years. Teams don't need to argue about frameworks anymore. You can have your cake and eat it too!

It's already happening on a large scale at some of the largest companies in the world, but the impact isn't limited to big players — everyone can benefit from Web Components today.

To be clear, I'm not suggesting you throw out your framework and go all in on Web Components...Web Components are complementary to frameworks! In 2022, I strongly suggest building your design system with them. Knock out the UI primitives and patterns that all teams use and give devs the freedom to build with whatever framework(s) they want!

Any org that goes all in on a single framework will eventually find themselves swimming upstream to hire talent to maintain legacy code and avoid framework rot. But you can reduce this burden (and the associated costs) by using Web Components in your design system.

Remember that design systems aren't cheap. It takes a lot of time to redesign and rebuild dozens of components, so why keep doing it every few years? It costs too much and it prevents you from shipping faster.

Here's a quick case study from an open source UI library called Element UI. This is a very popular Vue 2 library, but breaking changes in Vue 3 meant the library no longer worked! They had to build and maintain a completely different version of the library, and now they maintain two separate versions — one for Vue 2 users and one for Vue 3 users. 🤦🏻‍♂️

This is what happens when you go all in on a framework for UI primitives. Imagine having to maintain multiple versions of your component library for each framework — and each major version — you want to support.

Thanks to Web Components, this it totally avoidable!

A common criticism I hear is that Web Components aren't perfect, to which I'll agree. No, they're not perfect. But they're pretty damn good, they're part of the standard, and we can collectively work to improve any shortcomings they might have.

I'll take platform-based interoperable components over framework churn any day of the week. ✌🏻

Shameless plug: you should take a look at Shoelace if you're looking for an awesome library of web components.

This post was originally a Twitter thread.

Not Everything Can Be Feature Detected

2022-08-15T00:00:00Z

In the early days of Web browsers, it was extremely common to see user agent checks in JavaScript. Sometimes, you'd write the same code in two or three different ways to support various browsers. Code such as that shown below allowed webpages to work in browsers like Netscape Navigator and Internet Explorer, who didn't always agree on how features should be implemented.

if (navigator.userAgent.indexOf('MSIE') > -1) {
  // code for Internet Explorer
} else {
  // code for other browsers
}

To exacerbate this, Internet Explorer introduced a syntax for conditional comments that allowed developers to provide IE-specific code. It even allowed devs to target specific versions of Internet Explorer.

<!--[if gte IE 6 ]>
  <p>Only IE 6 and above will see this</p>
<![endif]-->

This may seem like madness in 2022, but it was an absolute necessity to make your web app work everywhere. Some of you might remember those little This site best viewed in Internet Explorer badges.

Eventually, and probably largely due to Modernizr, we started telling developers to detect features instead of browsers. The idea was that, as standards became more established and browser development picked up after the IE6 lull, it was more reliable to test for specific features rather than specific browser versions.

These days, feature detection is the de facto winner over browser sniffing, which is mostly a good thing. Alas, some developers take things from one extreme to another. Over the years, I've stumbled upon numerous code snippets where, instead of detecting a feature, the developer was detecting something completely unrelated to the feature and using that as a flag to sniff the browser.

The line of thinking goes like this: "Feature A only works in Firefox, but I can't detect Feature A directly. Hmm...but I can detect Feature B which also only works in Firefox, so I'll use that to determine whether Feature A is supported!" (I'm intentionally omitting links to avoid calling anyone out.)

Hopefully, you can see why this is a bad idea. One day, Firefox might implement Feature A before Feature B, which means your test is now useless. Or, the opposite could happen and they ship Feature B before Feature A, leaving you with a broken website.

Alas, feature detection isn't always straightforward, so occasionally developers do things like this because it seems better than user agent sniffing. Which brings me to my next point...

Not Everything Can Be Feature Detected

You see, not everything can be feature detected. One example can be found in the Shoelace code for <sl-input>. This component acts as a supercharged <input> element, offering more features than a standard form control. One of its features, for example, is a clear button. Many browsers will show their own clear button for <input type="search">, but not for other input types. Shoelace, on the other hand, allows you to add a custom clear button to any input type while providing a consistent UI in all browsers.

The problem is that Firefox adds its own clear button to date inputs, which resulted in this:

No other browsers do this, and there's no obvious way to turn it off or hide it in Firefox. Furthermore, you can't feature detect it — or at least we haven't discovered a way to do so.

This is where some developers might lean on detecting Feature B to support Feature A to avoid browser sniffing — but we've already discussed why that's a bad idea.

So what's a developer to do?

Calling Out User Agent Checks

The solution here is to do the thing that's become taboo...we need to sniff the user agent string for Firefox! That can be done with ease:

const isFirefox = navigator.userAgent.includes('Firefox');

But developers aren't the only ones calling out browser sniffing. Running this code in Chrome will yield a notice in the dev console.

A page or script is accessing at least one of navigator.userAgent, navigator.appVersion, and navigator.platform. Starting in Chrome 101, the amount of information available in the User Agent string will be reduced.

To fix this issue, replace the usage of navigator.userAgent, navigator.appVersion, and navigator.platform with feature detection, progressive enhancement, or migrate to navigator.userAgentData.

While sniffing is usually a bad idea, Chrome isn't exactly saying that here. It's letting us know that they're going to be reducing the information provided in navigator.userAgent, likely to mitigate fingerprinting. This check will probably continue to work for a long time, but if we want to eliminate this notice from the console, we need to use an alternative. That's where navigator.userAgentData comes in.

Currently, support is limited to Chromium-based browsers, but we can still leverage it — perhaps ironically — using feature detection!

To suppress the old school user agent check, we can look at navigator.userAgentData first. If it's present, we can check to see if we're using a Chromium browser and, if so, stop there. Otherwise, we can do the traditional check.

const isChromium = navigator.userAgentData?.brands.some(b => b.brand.includes('Chromium'));
const isFirefox = isChromium ? false : navigator.userAgent.includes('Firefox');

Note that we're specifically checking for Chromium in navigator.userAgentData.brands because that's a known value. It's not clear if or when Firefox will support navigator.userAgentData and, when does, what it will provide as a brand. Checking for "Firefox" seems sensible, but given the strange history of user agent strings, they could ship something like "Gecko" or "Quantum" instead.

Or, devastatingly, they could ship "Chromium" for some kind of compatibility reason. If they do that, well, this check will blow up.*

So yeah, turns out browser sniffing really does stink.

Browser Sniffing Stinks, But It's Sometimes Necessary

Clearly, user agent sniffing is unreliable, so there's good reason to avoid it. But if we commit to never ever doing it, there will inevitably be some problems we can't solve.

So when is it OK to do naughty things? Typically as a last resort after all other options have been exhausted. In the Shoelace example above, no functionality is lost if the check fails. Instead, the user will simply see two clear buttons. That's not ideal, but it's also not broken.

That's a good rule of thumb. If you absolutely can't feature detect something and you can implement a sniff that, when it fails, won't lead to a loss of functionality, go ahead and sniff that browser.

*In this case, it seems unlikely Firefox would bloat the new navigator.userAgentData API with the wrong user agent. After all, the new API doesn't have all the crazy history that navigator.userAgent has, but we know better than to make such assumptions on the Web.

Buttons and Cursors

2022-07-27T00:00:00Z

There's a post from 2016 entitled Buttons shouldn't have a hand cursor that's been making its way around social media this week. While the author is correct in his statement that operating system buttons don't have hand cursors, the pattern has become ubiquitous and somewhat expected on the Web.

Some of his points include:

When a button has the hand cursor, it subtly suggests that the user is interacting with a link when they’re not.

The hand cursor is reserved for links. This is because they are unique in their behaviour.

Links have always been handled this way since the web came along — this is the convention of the web that you need not innovate on.

Admittedly, most of my designs as of late do include cursor: pointer for buttons as well as other clickable, non-link controls. And while I don't have a strong opinion either way, revisiting that post triggered a thought about the psychology behind user interfaces.

Learned Behaviors

As a computer user, you undoubtedly know what radio buttons are and how they work. But how do you know that? Do you remember the very first time you used one? Probably not, but it's likely that your first experience created a pathway in your brain that said "I can only pick one of these" and that knowledge has been engrained ever since.

These are learned behaviors. A child who has never seen a radio button before might try to click on one to make a choice. Then they might click on another one to select a second choice. Quickly, the child will realize the limitations of a radio button: "I can only pick one."

That lesson remains with them until something challenges the pattern, and when such change occurs, they will dislike it because it doesn't feel correct to them. It's suddenly "unintuitive" because they've learned to expect certain behaviors, and anything unfamiliar will be called out as "poor design."

This is why radio buttons are almost always round and checkboxes are almost always square. Swapping something as simple as the shape of these controls will confuse users because it contradicts their learned behaviors.

How We Got Here

If users develop such intrinsic expectations for consistent UIs, then how did the proliferation of hand cursors on buttons even occur? A theory I have dates back to the "Web 2.0" trend where buttons got bigger, more colorful, and eventually a lot flatter. When buttons stopped looking like buttons, designers threw in a subtle way to more easily distinguish them by changing the cursor.

Plenty of users complained about flat design, but I believe the trend is directly related to why almost every button on the Web today has a "link cursor." It was a subtle enough change — an improvement, if you will — that made flatter controls more tolerable. Web designers slipped the pattern in and, while everyone was busy complaining about the lack of skeuomorphism and increasingly harder-to-identify buttons, nobody really noticed.

Now that nearly every clickable thing on the web seems to have a hand cursor, I'd argue that not doing it is the new anti-pattern, largely due to user expectations. The Web isn't an operating system and, despite the obvious inconsistency between operating system and Web interfaces, nobody seems to care.*

In some ways, I wonder if this hurts the web. Those of us who would love to see Web-based technologies compete more with native apps could easily argue that Web apps should behave the same way to make them as indistinguishable as possible, but I seldom hear about this particular inconsistency in the wild.

I wonder if anyone would even notice if we suddenly removed the hand cursor from all of our buttons. My guess is that few would, especially now that touch devices are more prominent for consumers. The handful of people who would notice are those that aren't browsing on iPhones and iPads, but "regular" computer users who, arguably, aren't so regular anymore.

*Admittedly, I don't have a strong preference here. I rarely think about it, although the thought does cross my mind from time to time. I tend to side with my users' expectations and, given the ubiquity of hand cursors on the Web, I'll continue to change the cursor on buttons until there's a good reason to stop.

My Stance on AI-generated Code

2022-07-08T00:00:00Z

2026-04-20 - Times change, and so do feelings. Please see this post for my latest thoughts on the matter.

I recently added this to Shoelace's contribution guidelines, which sums up my position on AI-generated code.

As an open source maintainer, I respectfully ask that you refrain from using AI-generated code when contributing to this project. This includes code generated by tools such as GitHub Copilot, even if you make alterations to it afterwards. While some of Copilot's features are indeed convenient, the ethics surrounding which codebases the AI has been trained on and their corresponding software licenses remain very questionable and have yet to be tested in a legal context.

I realize that one cannot reasonably enforce this any more than one can enforce not copying licensed code from other codebases, nor do I wish to expend energy policing contributors. I would, however, like to avoid all ethical and legal challenges that result from using AI-generated code. As such, I respectfully ask that you refrain from using such tools when contributing to this project. At this time, I will not knowingly accept any code that has been generated in such a manner.

Also let it be known that I would have zero problem with people using Copilot et al if software licensing and attribution were respected. But it means nothing if a computer "learns" from licensed and copyrighted code and spits it back out in your project like it's your own.

As humans, we learn from each other's code and we produce new code based off those learnings.

"What's the difference then?"

The difference is that humans can't store copies of every available codebase in their brain. We remember concepts. Computers remember by copying.

Design Systems Aren't Cheap

2022-03-21T00:00:00Z

Buttons are one of my favorite components. On the surface they seem simple, but in practice, they tend to be much more involved. In a post by Nathan Curtis entitled And you thought buttons were easy?, he demonstrates how costs can quickly skyrocket to $1,000,000 when one arm of the organization isn't aware of what the other is doing.

This is easy to brush off as an extreme example that only applies to really large companies. But how much does a design system actually cost?

A Real Life Example

Before joining Microsoft, I did a short stint at a company with more than 10,000 employees. I was on a dedicated design system team that included five engineers, four designers, and two design technologists. Over the course of 12 months, they had built about 30 components for their design system.

Many of those positions paid six figure salaries, and that doesn't account for benefits and HR costs. Let's pretend the average salary for each position was only $100K USD. That's 11 FTEs working for a year, totaling $1.1M in salaries. Again, this doesn't include stock grants, health insurance, and additional benefits.

All that to build buttons, dialogs, form controls, tabs — nothing proprietary. Just every day components that have been built many, many times before.

The Cost of Frameworks

I forgot to mention that the components they were building were for React, which means that only React teams can use them. As a result, either the entire company must agree to use React or non-React teams will have to duplicate effort by building the same thing in their framework, running the price up even higher.

In large orgs, these costs tend to fly under the radar, but they're tangible expenses if you know where to look.

Many design system teams I've spoken with are rebuilding or preparing to rebuild "legacy" design systems. The story usually goes something like "we're phasing out Angular 1.x" or "we're evolving from a Bootstrap-like design system."

And a lot of them want to build in React.

This leads to more costs that aren't being realized. Just like jQuery dominated the front end yesterday, React dominates it today. There will be something new that dominates it tomorrow. Your design system team will continue doing the same work and incurring more and more costs to keep up with framework churn. And let's not forget the cost of updating tomorrow's legacy apps, who are consumers of your soon to be legacy design system.

The Platform Outlives Frameworks

A modern design system's component library — the foundational elements from which all your apps are built — are excellent candidates for Web Components: a standard technology that's built into all modern browsers. Web components are used by some of the world's largest companies, including Adobe, Amazon, Apple, Ford, GM, Google, Microsoft, NASA, Salesforce, SpaceX, Visa, and many, many more.*

If you care about longevity and cost, the platform is simply a more logical choice because browsers have committed to supporting Web Components for a long time.

It's astonishing to me that so many engineers fail to see that doing the same work over and over again isn't productive nor cost effective. How many times do you have to rebuild a button before you think "maybe this isn't the best way forward?" Imagine how much more productive an organization could be if those design and engineering hours were spent elsewhere.

Now imagine if you didn't have to build all those portable UI primitives yourself. What if you could just apply some of your own styles and start building patterns and apps? 🤔

Jump Starting Your Design System

Every design system is different, but how much would you save if you could kick things off with a solid set of accessible, well-tested components? Imagine not spending $1,000,000 on buttons. Imagine jumping right in and building more useful components for your organization. Imagine telling your engineers to use whatever framework they want because it will work just fine with your design system.

That's one of the reasons I built Shoelace, an open source web component library that serves as a design system starter kit.**

Shoelace solves real world problems by offering accessible, intuitive, and interoperable components that save teams and individuals tens of thousands of dollars or more. It's totally free, by the way, although sponsorships are always welcome.

There's no need to roll your own buttons anymore.

*There's a longstanding misconception that Web Components aren't ready for mainstream consumption. This is a stale argument that held more water many years ago when the standards were less mature. These days, companies such as Adobe are embracing Web Standards by migrating flagship products to web components. Web components aren't just ready for mainstream — they are mainstream.

**One of my followers told me they didn't want to use a third-party library as a basis for their design system. I suggested they fork the project if they want to have complete control of it. Their reply was something like, "but then I have to maintain it myself!" That argument wasn't well thought out, because you'll still be maintaining it yourself if you build it from scratch!

CSS Parts Inspired by BEM

2022-03-10T00:00:00Z

In a previous post, I explored valid names for CSS parts and discovered that there are very few restrictions in what you can call them. The purpose of that deep dive was to help identify a pattern for naming parts that lets me expose states and subparts, or parts exported as a result of composition.

Using inspiration from BEM, I've settled on a familiar and intuitive pattern that I'd like to share.

Blocks → Parts

In BEM terms, a block "encapsulates a standalone entity that is meaningful on its own." Block names consist only of Latin letters, numbers, and dashes. This translates well to CSS parts.

Consider the following custom element template. It's contrived, as its only purpose is to render an image.

<template>
  <!-- shadow root -->
  <img part="image" src="..." alt="...">
</template>

If we wanted to make a more descriptive name, we could have called the part user-provided-image or something, as long as we stick to letters, numbers, and dashes.

Elements → Subparts

In BEM, elements are "parts of a block [that] have no standalone meaning. Any element is semantically tied to its block." An example looks like this.

<div class="block">
  ...
  <span class="block__elem"></span>
</div>

Note the two underscores separating the block from the element. You might be wondering how this ties into CSS parts. Since parts are unique to the shadow root, we don't need to namespace them to prevent collisions. Two different custom elements can have two different parts with the same name and that's totally fine.

However, when a custom element is nested inside another custom element, it's often desirable to expose the nested element and its parts, otherwise, consumers won't be able to target it fully with ::part().* This means we need to expose the nested element with the part attribute and its parts with the exportparts attribute.

Let's evolve our example so it contains a nested a custom element called <my-image>, and let's assume that <my-image> has two parts called photo and caption.

<template>
  <!-- shadow root -->
  <my-image
    part="image"
    exportparts="
      photo:image__photo,
      caption:image__caption
    "
    src="..."
    alt="..."
  >
    ...
  <my-image>
</template>

You can see that I've exposed the host element for styling with part="image", which follows the "block" naming convention. Now take a look at the exportparts attribute. Conveniently, we can rename subparts when we export them. This lets us avoid collisions (e.g. what if the host element and the nested element have parts of the same name?).

In this example, the host element is exposed through the image part, and its photo and caption subparts are exposed as image__photo and image__caption, respectively. Notice how everything is scoped to the image block now?

End users can now use a very familiar syntax for targeting the nested element and all its parts in their CSS.

::part(image) {
  /* matches the nested <my-image> element */
}

::part(image__photo) {
  /* matches the subpart named photo in <my-image> */
}

::part(image__caption) {
  /* matches the subpart named caption in <my-image> */
}

It's not uncommon for custom element authors to neglect to export parts. At the time of this writing, exportparts seems to be one of the lesser known features of web components, but it's well-supported and incredibly powerful.

Anyways, this is feeling pretty good so far!

Modifiers → States

Element state is a pretty simple concept. If you have a button, it can have a hover state, a focus state, an active state, etc. Normally, we can target such states with CSS using pseudo selectors.

button:hover {
  /* targets the button's hover state */
}

This also works with parts, too.

::part(image):hover {
  /* targets the image part's hover state */
}

But not all states are available to target with pseudo selectors, and what if you want to add custom states? More often than not, custom element authors lean on host element attributes for this.

my-image[loaded] {
  /* targets the host element when the image has loaded successfully */
}

my-image[error] {
  /* targets the host element when the image fails to load */
}

While this works, mapping stateful parts to attributes on the host element isn't an elegant solution. Let's see how we can improve our example using stateful parts and a BEM-like syntax. In BEM, a modifier is used "to change appearance, behavior or state" and is delimited by two dashes.

Fortunately, parts are designed to work a lot like classes. In fact, they use the same DOMTokenList API as classList. This means elements can have more than one part, and part names can be reused throughout the custom element's template!

Evolving our example further, we can add modifier parts to indicate various states. Let's imagine the image in our example has loaded successfully. We can indicate this by adding the image--loaded part.

<template>
  <!-- shadow root -->
  <my-image
    part="image image--loaded"
    exportparts="..."
    src="..."
    alt="..."
  >
    ...
  <my-image>
</template>

Now we can target the loaded state using ::part()!

::part(image--loaded) {
  /* targets the image once it has loaded */
}

There's no limit to the number of parts an element can have. You can add many additional states if you think they'll be useful.

<template>
  <!-- shadow root -->
  <my-image
    part="
      image
      image--loaded
      image--square
      image--large
      image--jpeg
    "
    exportparts="..."
    src="..."
    alt="..."
  >
    ...
  <my-image>
</template>

Why BEM?

While the examples herein are contrived, I'm hoping you can see the value in using the BEM convention for naming CSS parts. I chose it because it's familiar and it easily represents everything we need: parts, subparts, and states.

Another big win for BEM-inspired part names is that consumers don't have to escape anything in their CSS. It's perfectly valid to name a part image:loaded, for example.

<div part="image image:loaded">

But your users will need to escape the colon in their stylesheet, otherwise the selector won't match.

::part(image\:loaded) {
  /* this works, but requires a backslash before the colon */
}

This may not seem like a big deal but, in the world of CSS, escaping isn't something users typically do and they're probably going to forget. Imagine how frustrating it will be for a user to see a part called image:loaded in your documentation and, when they try to implement it, it doesn't work and they don't know why.

Since dashes and underscores don't need to be escaped, they're a more foolproof choice for naming parts.

*The ::part() selector is intentionally limited by the spec so you can only target elements the custom element author explicitly exposes.

When To Create CSS Parts

2022-02-21T00:00:00Z

I was recently asked a really good question on Twitter: when shouldn't an element be a CSS Part?

I've spent a lot of time building web components, most of which are intended for design systems, and my answer is pretty straight-forward.

Every part you expose is an API that you're committing to supporting, so it should be very intentional. Consider a component that uses a complex structure that you later need to refactor. If you've exposed everything as a part, your internals are locked down and breaking changes will be harder to avoid.

We're in a transitionary period where developers are starting to consume custom elements, many for the first time, and the concept of a shadow DOM frustrates them because they can't style things the way they're used to.

That's the feature.

You don't have to worry about internals. All the customizations are built in and exposed through attributes, custom properties, and CSS parts. I think of it not as a flat chunk of HTML I'm adding to the page, but as unique components with APIs that control their appearances and behaviors.

We As Developers

I often hear developers lament, "but I just want to style [some simple thing]!" This is a valid frustration if the custom element isn't designed well. You can easily run into things that aren't exposed that probably should be!

It means we, as custom element authors, must think more about our component APIs. We need to consider composition, portability, and reusability. We can't just throw some HTML and CSS together and call it done. We have be more intentional with the things we create.

I don't think that's a bad thing. The Web has always been a sort of wild west where anything goes. HTML and CSS, by design, are very forgiving. But when you're creating components — building blocks that serve as critical pieces of an application's foundation — you really need to think them through.

Think of this as a feature, not a limitation. Be very explicit with the things you expose. Think of CSS parts and custom properties as part of your component's public API, because that's exactly what they are.

Valid Names for CSS Parts

2022-02-20T00:00:00Z

CSS Shadow Parts, colloquially known as CSS Parts, are used to expose elements inside a web component's shadow root so they can be styled by consumers with CSS. But what are we allowed to call these parts? What characters comprise a valid CSS part name? To find out, I had to dive into the spec!

The part attribute is parsed as a space-separated list of tokens representing the part names of this element.

OK, but what exactly is a "token?" It's not really clear from this page, but we get a hint if we look at the spec for the ::part() pseudo selector:

::part() = ::part( <ident> )

It expects an <ident>, whatever that is. Fortunately, there's a link to it that takes us to a page that defines it.

CSS identifiers, generically denoted by <ident>, consist of a sequence of characters conforming to the <ident-token> grammar.

Perfect! So part names must conform to the <ident-token> grammar, but what's that mean? Let's follow the link to <ident-token> in the spec.

From that page:

<ident-token> [...] have a value composed of zero or more code points. Additionally, hash tokens have a type flag set to either "id" or "unrestricted". The type flag defaults to "unrestricted" if not otherwise set.

That's not, uh, super helpful. There's a link around "code points," so let's see if that makes it more clear. The link goes to this page:

A code point is a Unicode code point and is represented as "U+" followed by four-to-six ASCII upper hex digits, in the range U+0000 to U+10FFFF, inclusive. A code point’s value is its underlying number.

That seems to be a pretty wide range, though. According to Wikipedia:

The last code point in Unicode is the last code point in plane 16, U+10FFFF.

So does this mean we can use any Unicode character as a CSS part name? I'm no Unicode expert, so it still isn't clear.

Experimenting with Various Characters

Let's experiment and see what actually works in the browser. I created a sample custom element with the following parts, then tried styling them with ::part() to see what actually worked.

✅ part="a"
✅ part="a-b"
✅ part="a_b"
❌ part="a,b"
❌ part="a.b"
❌ part="a$b"
❌ part="a+b"
❌ part="a@b"
❌ part="a?b"

Clearly we can't use any character for part names. The browser doesn't like symbols, which feels intuitive to be honest.

Let's try some more characters.

✅ part="á"
✅ part="ñ"
✅ part="ę"
✅ part="Ф"
✅ part="平"
✅ part="λ"
✅ part="ה"
✅ part="字"

It seems to be OK with non-punctuation. What about emojis?!

✅ part="🥕"
✅ part="🐛"
✅ part="🐓"
✅ part="💩"
✅ part="🤨"

Totally fine. So it seems like any character except punctuation is good. Let's check out that lower Unicode range the spec referred to: U+0000

Here's a document with the lower end character points. It lists a number of the symbols we tried earlier in this range. 🥲

Clearly this range doesn't reflect valid CSS part names. Maybe we overlooked something in the spec, or maybe the CSS spec defines the argument too generically. Surely the HTML spec will explain it better.

Whoops...there's no mention of the part attribute at all. 😭

Let's see if this MDN page can help us clear things up.

A space-separated list of the part names of the element. Part names allows CSS to select and style specific elements in a shadow tree via the ::part pseudo-element.

OK, but what is a valid part name?!

MDN To The Rescue

I'm still not sure what's correct per the spec. Let's take a look at the ::part() docs in MDN now. I found this, which looks a lot like what we saw in the spec!

::part( `<ident>+` )

There's a link around <ident> that goes to this page, which says:

Thus far, MDN has provided the most human-readable explanation of what a valid ident is, and therefore what a valid CSS part name is. Here's the rundown of valid characters:

A-Z, a-z
0-9
hyphens
underscores
escaped chars
unicode chars in hex format

This explains why my punctuation examples didn't work. Here's something interesting, though:

an escaped character (preceded by a backslash, )

So can we use any character? Let's try one of those parts with punctuation that didn't work again:

<div part="a.b">

Now let's target it with CSS:

::part(a\.b) {
  ...
}

It works! So the spec is technically correct in that any character can be used, it just wasn't clear in that some of them need to be escaped.

Check this out:

<div part="a.b{c}|d">

And with CSS:

::part(a\.b\{c\}\|d) {
  ...
}

This works too!

Using Parts To Target State

Until now, I've primary used a single part for each element I wanted to expose. However, per the spec, parts should be used more like classes:

Part names act similarly to classes: multiple elements can have the same part name, and a single element can have multiple part names.

I guess I should change the way I use parts. I used to think of them as an identifier, but thinking of them more like classes as the spec suggests can help fill a gap!

Now that I know underscores are valid, I may explore them as a convention for hover/focus/active states since we never got the ::state selector. For example, we can give parts a synthetic focus state or even "hoist" a natural focus state to another element in the component.

<div part="control control_focus">

With this convention, perhaps we don't need a ::state selector after all!

Just Because You Can, Doesn't Mean You Should

So there you have it. You can name CSS parts anything you want — just remember to escape special characters! Using the previous example, we can even remove all of the letters and make a part name with only symbols!

<div part=".{}|">

The selector gets a bit crazy, though.

::part(\.\{\}\|) {
  /* 😎 */
}

I've tested this in all modern browsers and it appears to work consistently. Of course, this isn't very practical. Out of respect for your users, I would advise against naming your CSS parts like this! 🙈

I'm torn on whether or not special characters are useful here. Perhaps for an internal pattern, but I don't think I'd expose it as part of a public API. Users will definitely forget to escape those characters in their stylesheets. For my parts, I'll probably continue using a-z and dashes most of the time.

This post was originally a Twitter thread.

Complacency on the Front End

2022-02-14T00:00:00Z

We live in a world where front end developers are fatigued from the framework wars. Most have settled into a niche — especially the React crowd — and they’re happy to not have to think outside that box. They are, by far, the hardest crowd to sell web components to.

I'm not knocking them. They went through hell trying to keep up with things and ended up finding something that made sense and worked for them. Getting shit done is more important than chasing what's new!

But it's time to look up and consider what the platform has to offer nearly 10 years after React came out.

Not in a "how can web components replace my framework" way, but in a "how can web components complement my framework" way.

This post was originally a tweet.

A Web Components Primer

2022-02-04T00:00:00Z

On the eve of February, I was inspired to tweet about web components. What started as a simple thought quickly turned into a series of tweets that folks seem to find useful. I've adapted the thread and I'm posting it here for prosperity.

Overview

Shadow DOM? Light DOM? Slots? If you've heard of these but aren't sure what they are, maybe this will clear things up!

Custom elements are a feature that's baked into modern web browsers. You can build portable, reusable elements and use them in any HTML page. The collection of browser APIs that make this possible is known as web components.

Custom elements are written in JavaScript and must be registered at runtime. A custom element's tag name must start with a-z and contain at least one dash, e.g. <my-button>.

Shadow DOM

One of the best (and least understood) features of web components is the ability to encapsulate styles so nothing leaks in and nothing leaks out. This is done by attaching a hidden, separate DOM to the custom element.

This hidden DOM is called a "shadow DOM" or "shadow root."

The shadow root lets you use simple class names and ids without worrying if other elements on the page are using the same ones. (No more BEM!)

You can attach styles and scripts to a shadow root, too. It's kinda like a mini webpage within a webpage…minus the <iframe>. 😂

The Host Element

When you attach a shadow root to a custom element, the custom element acts as the host. Thus, we call it the "host element." Within a shadow root, you can target the host element in CSS using the :host() selector. (OK, it's technically a function.)

The host element is just another HTML element, but you control its API. You control what attributes it can have, what properties it uses, and what it renders.

You can even control the content that gets "slotted in."

Slots

Within a shadow root, you can create placeholders called slots. Slots let you control where child elements will be rendered in the template. The default slot looks like this in the custom element's template:

<slot></slot>

Additional slots can be added, but must be named. In the template, that looks like this.

<slot name="header"></slot>

Given the following custom element, the default slot will be populated with the paragraph and the header slot will be populated with the <h2>.

<my-element>
  <h2 slot="header">Named Slot Example</h2>
  <p>Lorem ipsum</p>
</my-element>

Everything you see here above is rendered in what we call the "light DOM."

Light DOM

You can style things in the light DOM as you'd expect using simple CSS selectors. What you don't see is the internal HTML structure of the custom element. That stuff exists in the shadow DOM and isn't exposed for styling. This is what seems to confuse and frustrate people.

By default, you can't style anything other than a few inherited font properties. That doesn't sound useful at first, but the browser gives us ways to "poke through" the shadow root and apply styles.

That's right. As a custom element author, you can tell users what they can and can't change in the shadow root — and enforce it!

There are two primary tools we lean on for styling custom elements.

CSS Custom Properties

Unlike regular CSS properties, CSS Custom Properties, or "CSS variables," cascade through shadow roots. They look kinda funny because they always start with two dashes.

:root {
  --brand-color: blue;
}

Tip: the :root selector above targets the <html> element.

To reference a CSS variable in a stylesheet, we use the var() function.

:host {
  color: var(--brand-color);
}

CSS variables get interpolated, so the above will be interpreted by the browser as:

:host {
  color: blue;
}

But unlike Sass, nothing gets compiled! Thus, if the variable changes at runtime, the browser happily updates everything using it. Did I mention that CSS variables cascade? You can redefine CSS variables in any selector, including pseudos such as :hover and :focus.

Of course, since we can't tap into the shadow DOM to style things, the custom element will need to "expose" which CSS variables it accepts as part of its API. This is a bummer, because the custom element author will need to expose a CSS variable for every property and state you might want to target.

If only we could style specific parts inside the shadow DOM. 🤔

CSS Parts

Well, we can! A custom element can expose "parts" which are aptly called CSS Parts. Parts are also defined in the custom element's template, this time through the part attribute.

<div part="container">
  ...
</div>

This exposes a part in the shadow root called container that consumers can target with CSS.

my-element::part(container) {
  background: blue:
  color: white;
}

Now you can style any property you want on that part, including states such as :hover and :focus!

my-element::part(container):hover {
  /* ... */
}

my-element::part(container):focus {
  /* ... */
}

To recap: a CSS variable allows users to customize a single property and a CSS part allows them to customize all properties on the exposed part. When authoring custom elements, it's not always clear which one to use and when. The rule of thumb I follow is:

When a single value gets reused throughout a component's styles, a CSS custom property is usually fine
When you need to expose more than a handful of properties on a single element, a CSS part is usually better

"Why can't I just style things like normal?"

That's a great question. I'm glad you asked…

Custom elements give us a way to build complex components with strong API contracts. Component authors can freely refactor internals without changing the public API. That wouldn't be possible if everything was exposed by default. Most things would be a breaking change. 😭

Style and logic encapsulation has been the holy grail of web development for a long time. Many solutions have been implemented to fake it, but elements have always been susceptible to leaks. The platform has finally given us a tool to solve this problem, so it's worth taking the time to learn and understand it. Once you do, I'm certain you'll embrace it!

"Web components sound kinda complicated!"

Perhaps at first, but if you know HTML you're halfway there! Plus, these are standard browser features and, unlike framework knowledge, learning this stuff will last you a long, long time.

Think of all the frameworks you've learned over the years and no longer use because their popularity declined. The nice thing about web components is that browsers have committed to supporting them for a long time!

The spec will surely evolve, but the rug won't be pulled out from under you.

"How do you write web components?"

You can write them with plain ol' JavaScript. Or you can use one of the many great component authoring libraries such as Google's Lit. React users might like Haunted for its hook-like syntax. Functional programmers might prefer Hybrids. There's also Microsoft's FAST Element and many others.

It's worth mentioning that both Svelte and Vue let you generate custom elements too!

Each library/framework has its own philosophy, but they all generate web components that work in any framework — and in plain ol' HTML pages.

The beautiful thing about this is you're not forced into a specific flavor. You can write web components the way you want to write them without sacrificing interoperability!

"Does anyone even use web components?"

Yes. A lot of big companies are using them and they're becoming ubiquitous. Recently, over 18% of pages loaded in Chrome registered at least one web component.

Fun fact: Adobe is using web components for the web-based version of Photoshop and other apps that used to be desktop-first are transitioning.

"But I like my React/Vue/Angular!"

That's cool! I like frameworks too, but I'm tired of rebuilding the same components every couple years. Most frameworks play nicely with web components, so you can have your cake and eat it too!

While most web components work perfectly fine as-is inside various frameworks, there is one notable exception.

React is super popular but it kinda doesn't get web components. What can we do?! No worries, React has added experimental support for custom elements behind a flag. A lot of progress has been made here recently!

In the meantime, you can wrap any custom element for React with a simple function call. This will generate a real React component that wires things up to the underlying custom element. It's like magic! (Tip: the utility has Lit in the name, but it works with all custom elements.)

How to Get Started

Hopefully you learned something about web components and shadow DOM in this thread! If you haven't experimented with them yet, why not? It's worth your time to better understand them. Even if you're not developing them yet, you'll likely be using them soon.

One great way to jump in is by using a library. I happen to be the author of Shoelace, an open source web component library featuring more than 50 useful components.

This is a great way to get started with custom elements and, because it's open source, you can dive into the code and start learning how they're made too!

Have questions? Want to learn more about web components? Follow me on Twitter for more tips, resources, and other web dev stuff!

Success Requires Luck

2022-01-14T00:00:00Z

I've concluded that successful "makers" have one thing in common: luck.

It's not that strategy and vision don't play a role in success, but nobody — literally nobody — can guarantee that a product or service will be successful. Think about some of the major corporations that launched new products, throwing tens of millions of dollars into research, development, and marketing, only to see their best efforts flop.*

Even if you have the right idea and the right strategy, the timing is hard to get right. Too soon and nobody appreciates your genius. Too late and somebody's already eaten your lunch. There are simply too many variables to account for.

Is there skill involved in being successful? Of course. Will connections and capital encourage success? Undoubtedly. But we shouldn't underestimate the one thing that can make or break our every attempt at success, and we shouldn't feel disenchanted when our attempt to get a piece of the pie fails.

At the end of the day, success requires luck.

So every time you see a post from somebody riding the wave of their success, take it with a grain of salt. There may be tidbits of good advice baked in, but it usually lacks context and their advice can just as easily misdirect you from what might make your attempt successful.

Then how do you guarantee success? Generally speaking, you can't.** However, you can increase your odds by following one simple rule. You may have heard your parents tell you this when you were little:

If at first you don't succeed, try and try again.

The one piece of advice I will leave you with — which is useful both in and out of the business world — is to simply learn from your mistakes.

Oh, and good luck!

*What I like about this post is that it spans many decades and shows how large companies even outside of the tech industry are prone to failure.

**Bear in mind that success is relative. Large MRRs and big exits sound appealing, but would you consider $10M in the bank a success? Most of you will say "yes," but what if it comes at the expense of your happiness? Will having a lot of money make you feel successful if, for example, your family falls apart because you devote your life to making it? The definition of success is different for all of us.

Flash of Undefined Custom Elements (FOUCE)

2021-12-29T00:00:00Z

Update (December 23, 2024): Check out my latest post on this topic: Revisiting FOUCE

Web components are defined and registered with JavaScript. Depending on how and when you load the scripts that perform registration, you may see a brief flash of unstyled HTML where your custom elements should be when the page loads. This is not dissimilar to FOUC, which occurs when HTML is displayed before the stylesheet has loaded.

For reference, here's an exaggerated example of three custom elements loading at different intervals.

Since the world needs more acronyms, and since one doesn't seem to exist yet, I'm calling this phenomenon FOUCE (rhymes with "spouse"), which stands for Flash of Undefined Custom Elements.

Fortunately, the browser gives us some tools to mitigate it.

The `:defined` selector

One option is to use the :defined CSS pseudo-class to "hide" custom elements that haven't been registered yet. You can scope it to specific tags or you can hide all undefined custom elements as shown below.

:not(:defined) {
  visibility: hidden;
}

As soon as a custom element is registered, it will immediately appear with all of its styles, effectively eliminating FOUCE. Note the use of visibility: hidden instead of display: none to reduce shifting as elements are registered.

The drawback to this approach is that custom elements can potentially appear one by one instead of all at the same time.

That's certainly a lot better, but can we take things a bit further?

Awaiting `customElements.whenDefined()`

Another option is to use customElements.whenDefined(), which returns a promise that resolves when the specified element gets registered. You'll probably want to use it with Promise.allSettled() in case an element fails to load for some reason (thanks, Westbrook!).

A clever way to use this method is to hide the <body> with opacity: 0 and add a class that fades it in as soon as all your custom elements are defined.

<style>
  body {
    opacity: 0;
  }

  body.ready {
    opacity: 1;
    transition: .25s opacity;
  }
</style>

<script type="module">
  await Promise.allSettled([
    customElements.whenDefined('my-button'),
    customElements.whenDefined('my-card'),
    customElements.whenDefined('my-rating')
    // ...
  ]);

  // Button, card, and rating are registered now! Add
  // the `ready` class so the UI fades in.
  document.body.classList.add('ready');
</script>

In my opinion, this is the better approach because it subtly fades in the entire page as soon as all your custom elements are registered. After all, what's the point of showing the page before it's ready?

The drawback, of course, is that you need to keep track of which elements you're using and add them to the list. But this can also be an advantage if your initial UI only requires a handful of custom elements. For example, you can load only the ones you need upfront and let the rest of them load asynchronously to make your page load faster.

December 30, 2021: The original version of this article mentioned script placement in the <head> as a method of eliminating FOUCE, but that doesn't work if you're using ES modules. While the approach works for non-modules, I've removed it because it leads to poor page load times and because of the growing ubiquity of ES modules on the Web.

Bulletproof Components

2021-12-08T00:00:00Z

Somewhere buried in my dusty basement lives a signed copy of Dan Cederholm's classic book Bulletproof Web Design. I purchased it during my first trip to An Event Apart in 2007. This book meant a lot to me back then, and almost 15 years later, many of its concepts still hold true.

The premise of the book is that designs should be "bulletproof" to accommodate the many ways they can be used.

I'm using the term bulletproof partly to describe flexibility — in other words, designs for the web that can easily accommodate various text sizes and amounts of content, designs that expand or contract along with whatever is placed within them.

I've been a software engineer for many years. More recently, my focus has been on building design systems. Although a lot has changed on the World Wide Web over the last decade, it's easy to recognize that many of the principles in Dan's book also apply to component development.

But what does a bulletproof component entail? Before jumping in, let's take a look at why we break down websites and applications into components in the first place.

Why do we build components?

Perhaps the most obvious benefit of the component pattern is reusability. Nobody wants to write the same code over and over again. If you end up doing that, have fun finding and updating all of the instances — and variations thereof — that make their way into the wild. This doesn't scale well in small orgs and it falls flat on its face in large ones.

Components are a vehicle for reusability. Their very nature leads to visual and behavioral consistency. By encapsulating structure, style, and logic into neat little packages, components become powerful tools in your users' arsenal — tools that are convenient to use and a bit harder to misuse.

When you break a design down into reusable bits, you can assemble, or compose, those bits to recreate the original design. Better yet, you can create entirely new designs with a lot less effort. Components are the building blocks of your application!

It's no secret that I'm a fan of web components (and I'm in good company), but I'm not here to sell you on web components today. What I will say is that more and more large organizations are leaning on web standards to build and rebuild their design systems in a technology agnostic way. Interoperability falls under the umbrella of reusability, but I think it's an important technical detail to point out.

What makes a component bulletproof?

The term bulletproof might be misleading, so let's consider this passage from Dan's book before we continue:

Out in the nonvirtual world, a bulletproof vest never guarantees complete, 100% protection, but rather being bulletproof is something that's constantly strived for. You're far better off wearing a bulletproof vest than if you weren't.

What we're aiming for with bulletproof components isn't perfection. We're aiming for components that are as intuitive, flexible, and resilient as possible.

Here are some of the key features that comprise a bulletproof component.

Ease of Use

Every component has an API that serves as its primary interface for users. As a component author, many of your users are probably developers which means good DX is critical. Offering consistent, predictable APIs is vital to good DX and therefore a fundamental feature of bulletproof components.

If you have a library, for example, don't make the size property accept small|medium|large in one component and sm|md|lg in another. As a user, if I've used one or two of your components, I should be able to get the hang of things pretty quickly based on prior experience. Let me build on that knowledge as I go.

Similarly, I should be able to glance at any component and have a pretty good idea what it does. I know you've documented it, but when I see a component in the wild, I don't want to open the docs unless I absolutely have to.

It's easy to overload a component with too many features. Oftentimes, that's a sign you should break it down further. Components that take on too much responsibility aren't only harder to use, they're harder to maintain too.

Versatility

Components are designed to be reused, so you never know where they'll end up in an application. Plan for this. Expect that users will drop your component into a 100×100 container, a 1200×1200 container, and everything in between. It's not that they're trying to break things, it's that edge cases happen a lot and it's better to be prepared than to be caught off guard.

As component developers, we can't predict every possible use case, but we can offer resilience by asking the right questions during development.

Does it break when I place it in common locations?
Does it grow and shrink as the user will expect it to?
How does it render on a mobile device? A tablet? An extra large screen?
Is it accessible in all places it's likely to be used in?
Does it work equally well on touch devices as it does with a mouse?
Does it work properly as part of a composition?

Sometimes it doesn't make sense to test for one thing or another. Use your best judgment and consider the intent. Nobody understands your users better than you, so adapt your questions accordingly.

Interoperability

As building blocks, components must work across a variety of applications. Unless your organization has a technical mandate, this usually means you need to support a variety of frameworks such as React, Vue, Angular, etc. Interoperability doesn't mean building the same component for every framework you need to support. It means using the same exact components in every framework.

This might sound like a web component plug but, realistically speaking, why wouldn't you want your components to work everywhere? Interop is important because there's a lot of upfront costs, maintenance burdens, and technical debt that comes with building the same thing multiple times.

Smaller orgs can get away with using a single framework for awhile, but it will eventually catch up to them. Which brings me to the next feature of bulletproof components…

Longevity

Congratulations! You've built a component library using your favorite framework. Your users are happy and everything is great. They love the shiny new buttons you gave them!

[a year or two later]

Oh look, your favorite framework has evolved. Version 2 is out and that means breaking changes! Quite possibly lots of them. No worries though, version 1 is still, uh, kinda supported. You can probably keep using that for awhile. Wait, what's that? You say a number of teams in the company have already upgraded to version 2?

Now you have two component libraries to build and maintain! Or maybe you can endure the challenge of getting everyone in the org to upgrade their old apps. Neither situation is ideal for you, your users, or your organization. Web components can help mitigate this.

Documentation

As a component author, I can tell you without question that most developers don't like to read documentation. Nevertheless, good documentation is a necessity for bulletproof components. But what exactly is "good documentation?"

Good documentation isn't necessarily comprehensive documentation. While it's certainly important to include all the relevant details of a component's usage, producing superfluous amounts of content is a disservice to your users. People aren't reading your documentation during their coffee break. They have work to do and they want to get it done efficiently. Make it easy for them to find what they need.

Your component's documentation should be scannable. Tell me what it does. Tell me how to import it. Tell me what props are available. Fill the page with relevant examples and order them from most common to least common, leaving the edge cases for last. Call out important tips and gotchas in context so they're prominent, but not distracting.

Don't let your content become stale. Nothing is more frustrating than docs that aren't aligned with a component's implementation. Avoid decoupling things that are likely to be forgotten over time.

Code analyzers can help keep important things such as props, events, and more up to date by bringing the documentation closer to the to code. Remember how I said developers don't like to read? Most don't like to document things, either. Make it harder for them to not document their changes.

Get Inspired

Building components is an art, and this post certainly isn't definitive nor comprehensive. My intent is to document, through experience and observations, the characteristics that make up bulletproof components.

Consider this an ode to Dan's vision of Bulletproof Web Design — an extension of a great idea adapted for component development.

I'm particularly proud of the work I've done on Shoelace, a library of components that I purposefully maintain with longevity in mind. This project demonstrates all of the principles I've described herein, and I encourage you to use it as inspiration in your own projects. I also encourage you to contribute to the paradigm of bulletproof components through discussion or demonstration via Twitter.

I can't wait to see what you're working on!

Empowering Design System Users

2021-11-01T00:00:00Z

The question of whether or not component APIs should be locked down at the code level comes up quite a bit. For example, if a button spec only calls for primary, secondary, and tertiary variants, should we still expose parts and custom properties so users can make further customization as needed?

In my experience, the answer is "yes."

The arguments for locking things down seem to stem from designers who want pixel-perfect results. That's understandable — after all, engineers aren't usually known for their creative skills — but restraints have consequences.

As design system engineers, we have to face the hard fact that, at some point, users are going to do things that are wrong. It's not our job to prevent them from doing those things. It's our job to give them tools that make it as easy as possible to do things that are right.

This may seem counterintuitive, but requirements change and designs evolve. The best way to experiment with new ideas is to customize what's already there. Neutering a component's API for the sake of design purity means it can no longer be used as a building block for new ideas.

When your API is too rigid, users will do crazy things to work around it. I've seen developers poke through the shadow root with JavaScript to add custom styles to encapsulated components. In another instance, a consumer built their own version of a component because we didn't expose any CSS parts. All the functionality was there — they just needed different styles.

You might think you're doing your organization a favor by enforcing standards. I mean, the whole purpose of a design system is to encourage consistency, isn't it?!

Absolutely, and you can do that with well-designed components and copy + paste examples that demonstrate their correct usage. Assuming developers want to do the wrong thing is a fallacy. Most of them want to do the right thing and, given the tools, will seldom venture outside the walled garden that is your design system.

But when users do need to color outside the lines, taking away their crayons won't stop them. They'll just grab the closest Sharpie and do it anyway.

Empower your users and you'll save everyone a lot of time and frustration.

Take advantage of design reviews to understand how consumers are using your components. What customizations have they made? What pain points did they have implementing them? Use this feedback to improve your offering, but know when to draw the line.

Exploring the EyeDropper API

2021-10-26T00:00:00Z

The EyeDropper API has landed in Chrome and Edge 95! This is a simple promise-based API that lets you select a color from anywhere on the screen. Let's dive in and see how it works.

To start, we'll add a button that activates the eye dropper.

<button type="button">Select a color</button>

When the button is clicked, we'll launch the eye dropper. As soon as the user selects a color, we'll update the page's background to match.

const button = document.querySelector('button');

if ('EyeDropper' in window) {
  const eyeDropper = new EyeDropper();

  button.addEventListener('click', () => {
    eyeDropper
      .open()
      .then(colorSelectionResult => {
        document.body.style.backgroundColor = colorSelectionResult.sRGBHex;
      })
      .catch(() => {
        // The user canceled selection
      });
  });
} else {
  // The EyeDropper API isn't supported
}

Try it on CodePen

Breaking it down

Here's what's happening in the code above:

Feature-detect the API
Instantiate an EyeDropper object
Listen for button clicks
Call the eye dropper's open() method, which returns a Promise
Wait for the promise to resolve (the user selected a color) or reject (the user canceled selection)
On resolve, grab the hex value and set the background
On reject, do nothing (the empty catch will prevent an error hitting the console)

Note how I'm feature-detecting the EyeDropper API. This is important because, at the time of this writing, Firefox and Safari don't support it. That doesn't mean you can't use the API to progressively enhance your users' experience, though!

For example, I'm using it in Shoelace's color picker to show an eye dropper if the API is available. Otherwise, I don't show the eye dropper but everything else still works.

Another Example

I whipped up another example that's a bit more practical. Play around with it and let me know what you think!

Try it on CodePen

The Future of Frameworks

2021-10-25T00:00:00Z

Love them or hate them, web components ("custom elements") are making a huge dent in the world of front-end development. As of today, close to 18% of page views in Chrome are registering web components. That's an insane amount of usage!

The benefits of a framework-agnostic component model are becoming obvious to web developers, particularly those who have built the same components over and over again to accommodate various framework flavors. That kind of rework is a time sink that inevitably leads to visual and functional inconsistencies. Maintaining multiple versions of the same component isn't a winning strategy for developers, designers, or end users.

Web components solve this problem not by replacing frameworks, but by complementing them with a standardized component model. Create your lower-level building blocks as custom elements, then plug them into a framework that handles higher-level operations. When it's time to upgrade or switch frameworks, you can do it more easily because you don't have to rip out the foundation and rebuild everything from scratch. Interoperability is why web component-based design systems are so appealing to large organizations.

My prediction is that front-end frameworks will move away from proprietary component models and embrace custom elements as first-class citizens. Both Vue and Svelte provide mechanisms for authoring them — although they still use and support their own component models as well.

"But I don't plan on switching frameworks!"

Unlike diamonds, frameworks aren't forever.* They come and go and, as their popularity fades, so does support, contributions, and community interest. Contrast this to web standards that browsers commit to supporting without breaking changes.

We've been building and rebuilding buttons for years because the component model has been baked into our frameworks. We don't need to do that anymore. If longevity is a goal, custom elements are where it's at.

*Whether you consider React a framework or a library is irrelevant. It has its own component model, VDOM, and synthetic event system. If it walks like a framework and talks like a framework…

Superpowers

2021-10-12T00:00:00Z

I stumbled upon a short post that intrigued me. In it, the author claims that the cure for boredom is superpowers. Not superpowers in the Superman sense, but ones that we can teach ourselves.

Learn Photoshop, and you’ll have a superpower. You’ll be able to see what your bedroom would look like with blue walls, improve the lighting in your craigslist posting, make custom christmas cards, do your own wedding invitations, and more.

This is true. I remember what it was like when I started learning Photoshop. I spent hours following Robouk's Photoshop tutorials (which are, impressively, still online in 2021) and even more time cropping my head onto various movie posters. I still have some of them lying around.

Those skills — er, superpowers — complemented the programming skills I learned as a teenager and ultimately led to me becoming a software engineer.

Many of us haven’t been bored in years. If that sounds unbelievable, maybe you should learn to fly too.

Thinking about it, I genuinely can't recall the last time I was bored. If anything, I wish there were more time in the day to do all the things I want to get done.

It may not feel like flying, but it does feel a bit like having superpowers.

Know When To Draw The Line

2021-10-11T00:00:00Z

One-off variations aren't uncommon, but they don't belong in your design system. You're design system isn't solving for every possible use case — it's encouraging visual consistency and efficient development. Use custom styles for one-offs.

This came up recently on my team.

We have a button component that supports prefix icons. By default, the icon color matches the text. In one design, the same button was used but the icon color was the primary color instead. The question came up:

"Should we make a new button variant?"

The answer, of course, was no. Because the button should only look like that in a specific toolbar, the solution was something like:

my-toolbar my-button::part(icon) {
  color: var(--primary);
}

Know when to draw the line.

Don't Do Magic

2021-10-11T00:00:00Z

We recently had a design for an "alert" component with an actions slot. In the spec, only secondary buttons were allowed in it.

Dev: "Design only wants secondary buttons in the actions slot, so I'm forcing it."

The developer was listening for the slotchange event and applying the secondary variant to all buttons in the slot automatically. The idea was to prevent consumers from using the wrong buttons by constraining the design in code. This magic will cause problems.

Here's the thing: designers change their minds. Sometimes a lot. They might tell you that a design will never, ever change. They might swear to everything holy that it will never change. But it can and often will.

In this case, forcing a variant on slotted buttons changed them from:

<my-button>

to:

<my-button appearance="secondary">

Aside from being unexpected, it leaves the user with no obvious way to add anything other than a secondary button to the slot.

"But that's what design wants!"

...until they realize they need a primary action button in that slot. Now you have to write code to account for this new requirement, PR it, get it reviewed, approved, and push a new version so they can use it. Problem solved, right?

Not so fast…

Scopes Change

Turns out, another team is using the same component to prototype a new feature and they want to use all possible button variations. This isn't the use case the design team initially specced the component for, but it doesn't make sense to create one from scratch because this one is close enough. Due to time and cost constraints, management decides the existing component should be modified to support both use cases.

Boom. The design that won't change has changed.

But remember the magic we coded that forced all slotted buttons to be secondary buttons? Because of that, we have to introduce a breaking change in our alert component OR give users an alternate API that's inconsistent with how buttons already work. Neither option is great.

In my opinion, locking design choices down with code, or "magic," is an antipattern. It creates more work for devs, makes things less intuitive for users, and introduces tech debt that will haunt you later on.

"Well then how do we force users to use the right buttons?"

We don't! That's not our job. Neither design nor engineering can account for every possible use case for the components we build.

Our job is to give users tools to build things with. If I give you a hammer and you smash a hole in the wall instead of tapping in a nail, that's a misuse of the tool.

When Bulletproofing is Overengineering

As engineers, it can be tempting to make components "bulletproof" using ✨magic✨ code. This is usually an overstep. There are two things you shouldn't underestimate:

The importance of design reviews
Use cases that evolve over time

If you're not taking the time to do design reviews, do them! But don't wait until the very end. You'll have better success if design and engineering work together throughout the process.

As for magic — I consider it a code smell. If you find yourself forcing things like this via code, that's a red flag. A better approach is good documentation! Show examples of approved use cases. Give users code to copy and paste. Make it easy for them to get it right.

Users will definitely do things they're not supposed to. Get comfortable with that and catch it in design reviews. Use these instances to understand why they're doing it that way and work with design to iterate if necessary. These are great opportunities to learn from each other.

Don't assume users are dumb or just don't get it. Give them the tools they need and make it easy for them to succeed. Most importantly, listen to feedback and know when it's time to steer them away from incorrect usage vs. adapting the tooling for new requirements.

This post was originally a series of tweets.

On Buttons and Links

2021-10-06T00:00:00Z

I posted a tweet yesterday that was met with some controversy, so I thought it would be a good idea to unravel it.

Unpopular opinion: in a design system, a "link" and a "button" should be one component.
— Cory LaViska (@claviska) October 5, 2021

At face value, I understand why people are upset with this. It's hard to provide context in 280 characters, though, so I made it a thread. That was a mistake, because people don't always read the thread so the intent gets lost and assumptions get made. Twitter is a wonderful place.

Semantically Different

Let's start by stating the obvious. A button and a link are semantically different HTML elements, so no need to bust out the keyboard to tell me that. The idea of merging the two into a single component comes from real world experience working on multiple design system teams for large companies.

The fact is that designers always, always ask for links that look like buttons and buttons that look like links. I know, designers shouldn't do this. But this isn't a fantasy, it's our reality, and when it costs your organization measurable value in terms of conversions, sales, etc., you're not going to win that argument.

Emotions aside, this often leads to developers producing two separate button and link components with the same styles and logic, and consumers end up misusing them just like <button> and <a>.

To alleviate this, I propose that a custom element such as <my-button> should render the same "button" visually, but based on the presense of an optional href attribute, it will use a <button> or an <a> under the hood.

<my-button>Save</my-button>
<!-- 👉 <button class="button button--primary">Save</button> -->

<my-button href="/new">New</my-button>
<!-- 👉 <a class="button button--primary" href="/new">New</a> -->

This makes it more foolproof — if it goes somewhere, it becomes a link. If not, it's remains a button. So far, we're more or less aligned with the Twittersphere…except for one detail:

They should look different because they should do different things.

Visually Different?

As much as I want to agree with this statement, it falls apart in practice. Links will inevitably need to look like buttons from time to time. No, buttons and links are not semantically the same, but there are times when they need to be visually the same.

In web apps, the function of buttons and links is often blended. Some actions, such as "new," might simply open a new page. Others aren't as obvious. "Save" might fire off an XHR and redirect you to another page if the response is successful — or go nowhere and show an error if the response fails.

Suddenly, the line between "button" and "link" is more blurry. Should it still be a link if it takes me somewhere only after an XHR is successful? What if the request errors out and doesn't redirect? What if you click a link and the app prevents navigation because you have unsaved changes? There are so many scenarios and "what ifs" that, in practice, it's hard to settle on a 100% agreeable definition.

And then comes the design team with a Figma for the app's toolbar.

We'll assume that "New" takes you to /new and "Edit" takes you to /edit/:id. Those should definitely be links! But wait — "Settings" doesn't go anywhere. It just opens up a dialog, so it needs to be a button. And instead of creating an endpoint on the server that downloads the file, we'll use the download attribute so that also needs to be a link.

Let's adjust the design to account for the idea that buttons and links must be visually different.

Do you think the design team is going to be thrilled with these changes to the toolbar? Do you think your customers will prefer this toolbar over the previous one?

What Users Expect

If the user is presented with a set of actions, they don't care if you use buttons or links under the hood. They care that it's consistent and that each control does what it's supposed to do. Remember that in all cases, each control's action is clearly inferred from its label.

Whether clicking "Delete" takes the user to a new page to confirm or opens a dialog to confirm is irrelevant. To the user, they're all just "buttons" that do something.*

It is true that links and buttons have different behaviors and the decision to make them look visually similar should be carefully considered. For example, CMD or CTRL + click typically opens a link in a new window. When buttons and links are identical, it can put users at a disadvantage.

I would recommend not making buttons and links look the same if you can reasonably expect the user will desire such behaviors. Some environments are more predictable than others. But accessibility isn't binary, so thought and consideration is still required from both design and development regardless of your approach.

Enforcement via API

The suggestion I'm making enforces the semantic definition of "button" and "link" by leaning on API design to ensure DRY principles and remove the burden of thought from consumers. This solves the problem of when to use a link or button under the hood.

It does not answer the question of "should buttons and links be visually similar?" That's a topic I'd love to have a conversation about because there are plenty of use cases that suggest at least sometimes they should.

Just know that, if you're working on a design system, it's extremely likely you will come across this requirement!

*This doesn't mean you should throw the baby out with the bathwater. It just means there might be situations where you need to use a link as a button, and the user doesn't care as long as it works. The download example comes to mind.

On Using Web Component Libraries

2021-09-20T00:00:00Z

We tend to think of components as things that belong to a framework. After all, React has components, Vue has components, Angular has components…it's just how we've always used them.

Because of that, people tend to refer to Lit and FAST Element as frameworks, but they’re not. They’re libraries, and that’s an important distinction.

If you want a React component to work, you have to use it with React. If you want a Vue component to work, you have to use it with Vue. If you want an Angular component to work…well, you get the point.

With web components, the platform is the framework.

Naturally, a follow up question is "why do you need a library then?" The truth is that we don’t. We can create web components without a library. Here's a counter component written in pure JavaScript.

class MyCounter extends HTMLElement {
  static get observedAttributes() {
    return ['count'];
  }

  constructor() {
    super();
    this.state = {
      count: 0
    };
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.innerHTML = `
      <button type="button">
        Count:
        <span class="count">${this.state.count}</span>
      </button>
    `;
    this.handleClick = this.handleClick.bind(this);
  }

  connectedCallback() {
    this.shadowRoot.querySelector('button').addEventListener('click', this.handleClick);
  }

  disconnectedCallback() {
    this.shadowRoot.querySelector('button').removeEventListener('click', this.handleClick);
  }

  get count() {
    return this.state.count;
  }

  set count(newCount) {
    this.state.count = newCount;
    this.update();
  }

  attributeChangedCallback(name, oldValue, newValue) {
    if (name === 'count') {
      this.state.count = Number(newValue);
      this.update();
    }
  }

  handleClick() {
    this.count = this.count + 1;
  }

  update() {
    this.shadowRoot.querySelector('.count').textContent = this.state.count;
  }
}

customElements.define('my-counter', MyCounter);

We choose to use libraries to improve the the component authoring experience and abstract messy boilerplate into efficient, reusable modules. Here's a functionally equivalent counter built with Lit.

import { LitElement, html } from 'lit';
import { customElement, property } from 'lit/decorators.js';

@customElement('my-counter')
class MyCounter extends LitElement {
  @property({ type: Number }) count = 0;

  handleClick() {
    this.count++;
  }

  render() {
    return html`
      <button type="button" @click=${this.handleClick}>
        Count: ${this.count}
      </button>
    `;
  }
}

Sure, we can bake features such as declarative rendering and reactivity into each and every component, but that’s not DRY. It would convolute the code and make our components larger and more difficult to maintain. That’s not what I want and it's probably not what my users want.

Alternatively, we could build those features ourselves and split them off into reusable modules — but that's just reinventing the wheel, isn't it?

When you think of it that way, using a library to build web components makes a lot of sense.

Aside: It’s been said that developer experience is the only benefit to using a library. While it’s true that benefits to the end user are marginalized with one-off components, it's worth noting that APIs such as those offered by Lit and FAST Element lead to less bugs due to reduced complexity and less code in the component itself. Consider the counter examples above. Which one is easier to maintain?

Finding the Closest Element Through Shadow Roots

2021-09-13T00:00:00Z

A great trick to find the closest element in the DOM that matches an arbitrary selector is Element.closest().

// Starts at el and walks the DOM until it finds a parent element
// that matches the selector. In this case, it will return the
// <body> element.
el.closest('body');

But what happens if you do this from inside a custom element's shadow root?

someElementInShadowRoot.closest('body');

By design, Element.closest() will not break out of the shadow root, so null is returned.

In my case, I needed to determine the lang of the closest element, even if the element was outside of a shadow root. Time for some recursive magic! ✨

Here's a TypeScript function that will do just that, even if the root is buried in multiple layers of shadow roots.

function closest(selector: string, root: Element = this) {
  function getNext(el: Element | HTMLElement, next = el && el.closest(selector)): Element | null {
    if (el instanceof Window || el instanceof Document || !el) {
      return null;
    }

    return next ? next : getNext((el.getRootNode() as ShadowRoot).host);
  }

  return getNext(root);
}

You can use it like this:

// Matches the closest element with a lang attribute, even if
// it's outside of the shadow root
const closestEl = closest('[lang]', el);

Testing Support for :focus-visible

2021-08-24T00:00:00Z

The new :focus-visible CSS selector lets us remove unsightly focus rings that often result in developers adding this to their stylesheets:

/* Please don't do this */
button:focus {
  outline: none;
}

While unsightly to mouse users, a clear focus indicator is essential for proper accessibility. How else will keyboard users, for example, know which element has focus?

Fortunately, :focus-visible gives us a way to make everyone happy by only applying focus styles when the user is interacting with a keyboard.

button:focus-visible {
  outline: dashed 2px orange;
}

It's currently available in all browsers except Safari. Well, it is available in Safari Technology Preview, but it's buried under the experimental features menu and it's not clear when it will land in mainstream Safari.

There's a polyfill you can use in the meantime but, since you can't polyfill pseudo selectors, it applies a focus-visible class instead. It's still useful if you really want this behavior, though!

Detecting Support

If you're trying to figure out how to feature detect :focus-visible, you might be surprised to learn that there isn't an obvious way to do it — but there is a way!

function hasFocusVisible() {
  const style = document.createElement('style');
  let isSupported;

  try {
    document.head.appendChild(style);
    style.sheet.insertRule(':focus-visible { color: inherit }');
    isSupported = true;
  } catch {
    isSupported = false;
  } finally {
    style.remove();
  }

  return isSupported;
}

The secret sauce is in CSSStyleSheet.insertRule(), which will throw an error if you pass in a style it doesn't understand.

You can use it like this.

if (hasFocusVisible()) {
  // Supported!
} else {
  // Not supported
}

This can be pretty helpful if you're building something and you want to provide different behaviors depending on the browser's support for :focus-visible.

Querying through shadow roots

2021-08-04T00:00:00Z

Let's say I have a web component with an open shadow root, like this one from Shoelace.

<sl-button>Click me</sl-button>

Inside the shadow root is a <button> that I want to target with JavaScript.* Alas, Element.querySelector() doesn't offer a shortcut for traversing shadow roots so we have to do this.

const button = document.querySelector('sl-button').shadowRoot.querySelector('button');

That's pretty verbose! It's nice that we can chain the selectors, but it would be even nicer if we could poke through shadow roots right in the selector.

// This doesn't work, but we can dream
const button = document.querySelector('sl-button >>> button');

Well, here's a TypeScript function that gets us pretty close to that.

function shadowQuery(selector: string, rootNode: Document | Element = document): Element | null {
  const selectors = String(selector).split('>>>');
  let currentNode = rootNode;

  selectors.find((selector, index) => {
    if (index === 0) {
      currentNode = rootNode.querySelector(selectors[index]) as Element;
    } else if (currentNode instanceof Element) {
      currentNode = currentNode?.shadowRoot?.querySelector(selectors[index]) as Element;
    }

    return currentNode === null;
  });

  if (currentNode === rootNode) {
    return null;
  }

  return currentNode as Element | null;
}

This let's you use >>> in your selector instead of splitting it into multiple queries, resulting in a much simpler syntax.

const button = shadowQuery('sl-button >>> button');

Querying starts on document by default, but you can pass a node as the second argument to change that.

const container = document.querySelector('.your-root-node');
const button = shadowQuery('sl-button >>> button', container);

Finally, you can even traverse multiple shadow roots in one query.

shadowQuery('my-element >>> my-second-element >>> my-third-element');

*It's worth noting that you probably shouldn't be targeting shadow roots — they're encapsulated for a reason! Nevertheless, this can be very useful in exceptional situations.

Prefers Reduced Motion

2021-05-19T00:00:00Z

By now, most devs are familiar with the prefers-reduced-motion media query that tells whether or not a user prefers, well, reduced motion. You can use this to tone down (or turn off) transitions and animations in your stylesheet to accommodate users with vestibular motion disorders.

.animation {
  /* normal animation */
}

@media (prefers-reduced-motion) {
  .animation {
    /* subtle or no animation */
  }
}

That's pretty useful, but if you're using the Web Animations API, you may want to check for this with JavaScript instead. Thanks to window.matchMedia, it's pretty easy to do. I like to wrap it up in a small function that returns a boolean: true if the users prefers reduced motion or false if they have no preference.

function prefersReducedMotion() {
  const query = window.matchMedia('(prefers-reduced-motion: reduce)');
  return query?.matches;
}

Usage looks something like this:

if (prefersReducedMotion()) {
  // subtle or no animation
} else {
  // normal animation
  document.querySelector('.my-element').animate(...);
}

Finding the active element in a shadow root

2021-03-22T00:00:00Z

You can get the focused element with document.activeElement but, if it's inside a shadow root, this will be the host element. This happens because of retargeting, but sometimes you might need access to the internal element that actually has focus.

Here's a recursive function that will return the internal element that has focus, even if it's inside a shadow root.

function getActiveElement(root: Document | ShadowRoot = document): Element | null {
  const activeEl = root.activeElement;

  if (!activeEl) {
    return null;
  }

  if (activeEl.shadowRoot) {
    return getActiveElement(activeEl.shadowRoot);
  } else {
    return activeEl;
  }
}

Usage:

const activeEl = getActiveElement();

Moving from Stencil to LitElement

2021-03-02T00:00:00Z

Over the weekend, I finished migrating Shoelace from Stencil to LitElement. Even though consumers of the library won't see much of a difference, this was a major overhaul of Shoelace's internals.

Naturally, such a big change brings questions from the community, such as "what were the reasons behind shifting away from Stencil?" These are valid questions, so I wanted to take the time to answer them here.

But before I jump in, it's worth mentioning that Stencil is a great project that played a significant role in getting me into web components. Being able to type npm init stencil and have an entire project ready to go is really something special.

Let it also be clear that this isn't a jab at Stencil, nor is it advice for or against using Stencil to build your own projects. This is why I chose to move on based on my experience, my observations, and my desire to own as much of my own code as possible.

Less is more

When you're managing a software project, dependencies can quickly become liabilities. Despite its many niceties, Stencil can be a box of mystery at times. As a contributor, it was difficult for me to dive into its codebase and figure things out. There's little documentation on its internals, so everything requires digging. A lot of digging. Even as a member of the Stencil team, I found it hard to get the information I needed to make useful contributions to the project.

Why does this matter? Well, when code is complex and lacks documentation, the barrier of entry is higher and people are less apt to make contributions. Despite a tight-knit community of talented Stencil users, many bugs continue to go unpatched. Even worse, a bot closes issues after 30 days of inactivity, so many of the bugs that do get reported are closed without feedback or resolution. In my opinion, valid, reproducible bugs should remain open until they're resolved to provide transparency and accountability.

One might surmise that the maintainers are overwhelmed by the number of bugs that get filed, but garbage collecting valid issues is disingenuous and a disservice to the community. I appreciate that Stencil is open source and its maintainers have zero responsibility to fix bugs for free, but I fundamentally disagree with this aspect of how the project is maintained.

And what happens when I have an issue that I can't resolve myself? Will someone point me in the right direction? Will it ever get fixed? Probably not. (That was submitted a year ago, before issues were automatically closed.)

Build & distribution

Stencil is a compiler that generates components using any number of possible output targets. In theory, this is really convenient because it can produce multiple distributions from a single source. In practice, I found that having two separate distributions made my project harder to document and left users confused.

These output targets are also limited in terms of configuration. Since last year, Shoelace was plagued with a tree shaking problem I couldn't fix because of this. Moving away from Stencil, I was able to gain full control over how my build works and the tooling used to power it. I leaned on standards and went with a single collection of ES modules that work in both browsers and bundlers. Best of all, having full control over the build let me finally resolve that pesky tree shaking issue.

Less Magic

Speaking of distributions, one thing I'm losing by leaving Stencil is its lazy loading dist. At first, I wondered how I could reproduce this outside of Stencil. It's a very convenient feature for users.

Lazy loading works by registering every component as an empty custom element. Then, when you insert a component into the DOM, its source is fetched and its internals are swapped out. This is necessary because you can't reregister custom elements, so you have to resort to a bit of magic. It's a clever trick, but it does lead to a form of FOUC, especially when components are added after the initial page load.

I believe it was also the source of some strange Shoelace + React/Svelte timing bugs and a very annoying error I kept seeing on the documentation website:

Uncaught (in promise) DOMException: Failed to set the 'adoptedStyleSheets' property on 'ShadowRoot': Sharing constructed stylesheets in multiple documents is not allowed

I'm pretty sure this was a combination of how Docsify loads pages and Stencil's lazy loading, but I was never able to pinpoint it. Regardless, it's no longer an issue with the new version.

Considering all this, I thought long and hard about the benefits and drawbacks of lazy loading. Ultimately, I decided it wasn't worth the effort. With the latest version of Shoelace, users can load the entire library or cherry pick components — something that wasn't possible before. I think that's a fair tradeoff to avoid all the weird issues it seemed to be causing.

Native templates

I prefer to stick to the platform when possible. Although I like JSX, I like template literals even better because they're simple and they don't require transpilation. Now that the platform has a built-in for templating, we should utilize it.

The syntax is similar, but not identical. Here's the original render function from Shoelace's badge component.

// JSX
render() {
  return (
    <span
      part="base"
      class={({
        badge: true,
        'badge--primary': this.type === 'primary',
        'badge--success': this.type === 'success',
        'badge--info': this.type === 'info',
        'badge--warning': this.type === 'warning',
        'badge--danger': this.type === 'danger',
        'badge--pill': this.pill,
        'badge--pulse': this.pulse
      })}
      role="status"
    >
      <slot />
    </span>
  );
}

Compare that to the native equivalent.

// Template literals
render() {
  return html`
    <span
      part="base"
      class=${classMap({
        badge: true,
        'badge--primary': this.type === 'primary',
        'badge--success': this.type === 'success',
        'badge--info': this.type === 'info',
        'badge--warning': this.type === 'warning',
        'badge--danger': this.type === 'danger',
        'badge--pill': this.pill,
        'badge--pulse': this.pulse
      })}
      role="status"
    >
      <slot />
    </span>
  `;
}

They're so similar. I just don't see why I should run the code through another layer of transpilation when template literals suffice. This is what they were designed to do.

A special syntax is no longer necessary.

Virtual DOM

Like React and other popular frameworks, Stencil uses a virtual DOM ("VDOM") to render things faster than working directly with the real DOM. However, it's a common misconception that VDOMs are actually faster. Rich Harris writes:

But hang on a minute! The virtual DOM operations are in addition to the eventual operations on the real DOM. The only way it could be faster is if we were comparing it to a less efficient framework (there were plenty to go around back in 2013!), or arguing against a straw man — that the alternative is to do something no-one actually does.

It's an outdated meme. You can write poor performing components with or without a virtual DOM. Consider lit-html and µhtml, both of which leverage direct DOM diffing for fast, efficient rendering.

There's no need for an extra layer here, either.

A long time coming

The move away from Stencil was inevitable. As part of my never-ending quest for simplicity, I've been experimenting with other libraries for a long time. One of the first I explored was Hybrids, which is great if you want to go with a more functional approach. Ultimately, I decided that class-based made the most sense because, well, that's how you create custom elements. You can't do it without extending HTMLElement.

class SlButton extends HTMLElement {
  // build something awesome
}

I also dove into Microsoft FAST and I like what they're doing. The API is very sensible, but its templates feel a bit strange since you have to use attr=${x => x.prop} instead of attr=${this.prop}. I believe they do this to provide a faster alternative to DOM-diffing during render, but this would mean a lot more work for me. I also found it confusing that contexts can be nested, which makes larger templates harder to maintain.

I experimented with my own base class called Shoemaker. I wanted to make the thinnest possible abstraction around the features I needed, but the more the project evolved the more I realized I was recreating LitElement. Between that and feedback from the community, I decided it didn't make sense to reinvent the wheel.

~~I do have a few [opinionated] DX concerns that I'll be sending over to the LitElement team for consideration. However, I've alleviated most of them with a handful of custom decorators.~~

Jan 18, 2022: since this was written, Lit has evolved a bit and the one thing I still want from them is a @watch decorator. For now, I implemented my own, which is something I couldn't do with Stencil.

Moving forward

Consumers of Shoelace won't notice much of a difference in this release. I've simply replaced the old engine with a new one that does the same thing except with a leaner, simpler codebase with less magic. I have a responsibility to my users, so I need to be able to fix problems when they arise. I wasn't always able to do that before. Now I can.

I'm tired of rebuilding buttons. I designed Shoelace for longevity, taking advantage of the best parts of the platform — the stuff that doesn't change on us every few years. It only makes sense to bring its code closer to the platform as well.

With LitElement, I'm getting all the features I want with the smallest possible footprint. Now I can get back to building components again.

March 8, 2021 - updated to reflect the latest changes to the library.

SVG Repo

2021-02-15T00:00:00Z

I stumbled upon a great resource for free SVGs. They're currently boasting over 300,000 images. Check it out over at SVG repo.

Looks like they have a sister site for fonts, too. Lots of 'em.

Archiving Postleaf

2021-02-03T00:00:00Z

Postleaf — at least in its current form — has been discontinued. In the future, I'd like to bring it back as something different. Maybe an open source project. Maybe a SaaS product. I'm not sure at this point.

The world still needs a simple platform to encourage blogging and the decentralization of publishing. Unfortunately, This version of Postleaf didn't fill that gap because it was too difficult and expensive for the majority of users to install and host. Aside from that, the world of web hosting has changed significantly in recent years.

For now, I'm taking some time to focus on other projects and interests. I hope to revisit Postleaf again when the time is right for me, but I'm not exactly sure when that might be.

That said, I'm archiving the Postleaf repository. Anyone is welcome to fork the project and carry the torch, but I'm hanging onto the "Postleaf" name, U.S. trademark, and website, so new maintainers will need to release it under a different name.

Thanks for the many years of encouragement. While my vision for Postleaf wasn't fully realized, I've learned so much from this project and its community. I'm still excited for Postleaf's future.

— Cory

Getting localized month and day names in the browser

2020-11-25T00:00:00Z

JavaScript has a well-supported date/time formatting API called Intl.DateTimeFormat. Here's a tip — you can use it to generate localized month and day names without the need for a language pack! This is super useful if you're building, say, a date picker or a calendar app.

I've written a couple functions to demonstrate how this works. Consider them MIT licensed if you want to use them!

function getDayNames(locale = 'en', format = 'long') {
  const formatter = new Intl.DateTimeFormat(locale, { weekday: format, timeZone: 'UTC' });
  const days = [1, 2, 3, 4, 5, 6, 7].map(day => {
    const dd = day < 10 ? `0${day}` : day;
    return new Date(`2017-01-${dd}T00:00:00+00:00`);
  });
  return days.map(date => formatter.format(date));
}

function getMonthNames(locale = 'en', format = 'long') {
  const formatter = new Intl.DateTimeFormat(locale, { month: format, timeZone: 'UTC' });
  const months = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12].map(month => {
    const mm = month < 10 ? `0${month}` : month;
    return new Date(`2017-${mm}-01T00:00:00+00:00`);
  });
  return months.map(date => formatter.format(date));
}

Each function generates a series of Date objects that align with each day of the week and each month of the year, respectively. Then they loop through each date, passing them to the browser's built-in formatter. The formatter is configured to only output the day/month name, giving us exactly what we want!

["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"]
["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"]

Need them in a different language? Just set the locale argument accordingly. Here's French, for example:

getDayNames('fr');
getMonthNames('fr');
// ["dimanche", "lundi", "mardi", "mercredi", "jeudi", "vendredi", "samedi"]
// ["janvier", "février", "mars", "avril", "mai", "juin", "juillet", "août", "septembre", "octobre", "novembre", "décembre"]

You can even generate short names by setting the format argument to short or narrow.

getDayNames('en', 'short');
getMonthNames('en', 'short');
// ["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"]
// ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"]

While this trick may not alleviate all your i18n woes, it can certainly reduce the size of your translation packs if you're building something that uses them.

And here's another tip — you can generate localized relative times such as "4 minutes ago" using a similar technique, except with Intl.RelativeTimeFormat.

Shoelace 2.0: a forward-thinking library of web components

2020-07-24T00:00:00Z

I've been having a lot of fun with Stencil and web components lately. Back in January, I decided to use it to completely redesign Shoelace, an open source project I created a few years ago.

I recently published Shoelace 2.0 — a collection of professionally-designed, accessible web components.

One really nice feature of web components is that you can use them with any framework. This is an amazing concept, especially for low-level building block components.

Let me explain why this is so amazing with an example.

Imagine you're on one of three teams in an organization, all tasked with building a different product. Team 1 wants to use React, Team 2 wants to use Vue, and Team 3 wants to use vanilla HTML+JS. The one requirement you have from your organization is that the UX must be consistent across all three products.

Obviously, sharing a library of UI components between the projects is the most efficient way to meet that requirement. But if you build your components in Framework A, you can't reuse them in Framework B or Framework C.

Web components solve this problem. They're supported by all modern browsers, they're framework-agnostic, and they're built into the standard, so we know they'll be supported for many years to come.

This is the technology that Shoelace is built on.

"But I only use [insert your favorite framework here]!"

I hear you. You only use React/Vue/Angular/whatever, so why should you care if your components work in other frameworks?

The fact is, at some point your beloved framework will ship a new version with breaking changes, and when that happens, you'll be reworking every button, input, dialog, dropdown, tab group, etc. That's just how software works.

And further down the road, your framework of choice won't be as ubiquitous as it is today. Things change and, like it or not, you will eventually move on or get left behind.

Since Shoelace is built on standardized browser APIs, it will be around long after today's most popular frameworks become obsolete.

TL;DR

I love building UI components, but it really sucks to rebuild them for every new framework (and new framework version). With Shoelace, I'm harnessing the power of web components to bring you a reusable, customizable component library that works with whatever framework you're using today and whatever framework you'll be using tomorrow.

Check it out at shoelace.style

Cory's amazing dot paper

2019-06-03T00:00:00Z

In a world where designers use Sketch, Photoshop, and other apps to create wireframes, I'm here in my corner holding this old fashioned pencil and a stack of dot paper.

Sorry, but for me, these primitive tools do the same thing and I find them easier to use.

I don't know. I guess it's just faster to grab a pencil and paper to transform my thoughts into a wireframe. I also use it for jotting down notes and todos here and there. In fact, aside from GitHub issues, I don't even have a task manager.

I used to use lined paper, but that's distracting. Then I tried graph paper, which was better but still a bit distracting. At some point, I discovered dot paper, but it's incredibly hard to find and usually expensive.

So I created my own.

The dots are intentionally subtle to minimize distraction. I usually print out 20 sheets at a time and use a binder clip to keep them together. A good mechanical pencil is a necessity since it never needs to be sharpened and keeps a consistent edge.

This is the same paper I used to draw wireframes for my free HTML, CSS, and JS beautifier.

Today, I'm releasing my homegrown dot paper for free in two variations:

The version with grid is excellent for wireframes, as it provides a way to measure without counting dots.

Just download, print, and start creating!

A free HTML, CSS, and JavaScript beautifier

2019-05-22T00:00:00Z

Ten years ago, I launched DirtyMarkup to clean up dirty code. It was a fun little tool, but its best feature was that it was easy to use and didn't have intrusive advertisements.

I sold DirtyMarkup a couple years ago, and since then the new owners slapped on a header that makes the page scroll and some banner ads. 😒

I missed having my own tool, so last week I built a new one from scratch that’s even better. 💪

You can find it at: surrealcms.com/beautify

The new tool doesn’t use Tidy. Instead, it relies on Prettier for cleaning up HTML, CSS, and JavaScript code. That means it doesn’t require a binary and the results are instant.

If you’re interested in how I built it, I posted a write-up here.

Let's Encrypt renews but browsers still seeing old/expired SSL certificate

2019-05-10T00:00:00Z

This morning was frustrating. I recently upgraded my VPS from the deprecated letsencrypt client to the newer cerbot client and generated new certificates for all my personal domains. I thought everything was fine — until I kept seeing intermittent SSL errors.

I figured I did something wrong, so I triple checked my Apache configs, made sure each website was pointing to the correct certificate, and restarted Apache...things seemed to work in Chrome, but not Firefox.

Ok, obviously Firefox was caching the certificate, right? I cleared everything. Same error. I reinstalled Firefox. Same error. Then I noticed that, when I refreshed Chrome, I would occasionally see images blocked, then a moment later they would load.

I ran some SSL tests with mixed results. They were seeing both certs intermittently too. 🤔

So I disabled the server with sudo service apache2 stop. To my surprise, my websites were online, but this time the SSL was consistently invalid.

It turns out, when I upgraded to certbot, I somehow launched a second instance Apache that wasn't responding to reloads, so there were two instances handling HTTPS traffic — one serving up the cached certificate from memory.

To solve the problem, I ran:

sudo killall apache2
sudo service apache2 start

Evidently, Chrome is more resilient to this than Firefox. Perhaps when Chrome sees a valid certificate from at least one HTTPS request, it retries any that fail until it gets a valid one.

Either way, mystery solved. 🕵🏻‍♂️

Introducing Surreal CMS 7

2019-04-26T00:00:00Z

Last November was the 10 year mark for Surreal CMS, a content management service I created to manage static (and mostly static) websites.

Last week, I soft launched Surreal CMS 7. This new version is a complete rebuild from scratch using Node.js + Vue.js. I worked on this new app for a long time, and I'm incredibly happy with the result.

Everything has been improved in this version, and there's a bunch of great new features that really make static websites fun to manage. Early feedback from new and existing users has been overwhelmingly positive!

I've also reintroduced the free plan for personal, educational, and non-profit users!

The list of updates and improvements is way too long to list here, but you can check out the official announcement to learn more.

Getting duplicate ids in an HTML document

2019-04-05T00:00:00Z

I needed a way to identify all HTML elements with duplicate IDs. This is a seemingly simple task, but unfortunately, I didn't find anything out there that fit the bill.

I did find a couple functions that returned the duplicates, but they didn't include the first occurrence (I guess they assume the first occurrence isn't a duplicate, but all subsequent occurrences are).

So here's a function that does the job.

function getAllDuplicateIds() {  
  const elements = [...document.querySelectorAll('[id]')];  
  const ids = elements.map(el => el.id);  
  const dups = elements.filter(el => ids.filter(id => id === el.id).length > 1);  
  
  return dups;  
}

This function will return an array of elements in the document that have duplicate IDs. If no duplicates are found, an empty array is returned.

If you only need all occurrences after the first, here's a similar ES6 function for that, too.

function getDuplicateIds() {  
 const elements = [...document.querySelectorAll('[id]')];  
 const ids = [];  
 const dups = [];  
   
 elements.map(el => ids.includes(el.id) ? dups.push(el) : ids.push(el.id));  
   
 return dups;  
}

A clever way to style the element

2019-02-01T00:00:00Z

I was checking out the CashNotify app today and I noticed a beautiful style for highlighting text in their testimonials:

Most textual highlights use a boring rectangle background color, but this stands out and looks gorgeous. I was really hoping they were using a simple <mark> tag to accomplish this and was happy to learn that they are. The markup is as simple as it could be:

Just <mark>highlight</mark> it!

And the styles are simple too:

mark {
  background: linear-gradient(-100deg, hsla(48,92%,75%,.3), hsla(48,92%,75%,.7) 95%, hsla(48,92%,75%,.1));
  border-radius: 1em 0;
  padding: .5rem;
}

Opening a new window after an async operation

2018-08-28T00:00:00Z

I was working on an OAuth implementation the other day and needed to open a third-party auth page in a new window.

However, I needed to fetch the target URL from the server first, then open the window. Kinda like this:

const button = document.getElementById('auth-button');
button.addEventListener('click', () => {
  getAuthUrl().then(url => {
    window.open(url);
  });
});

Of course, this doesn't work in most browsers — the popup gets blocked because the window wasn't opened immediately after the click.

To work around this, we need to open the window immediately after the click, so let's use the well-supported about:blank URL to our advantage.

const button = document.getElementById('auth-button');
button.addEventListener('click', () => {
  const win = window.open('about:blank');

  getAuthUrl().then(url => {
    win.location = url;
  });
});

Now the window opens and redirects to the appropriate URL after the async function executes!

You can take it a step further by opening a special page that shows a loader instead. Just swap out about:blank with your own page.

Zipping multiple folders into separate zip files

2017-07-31T00:00:00Z

Here's a bash script that will zip all folders in the current directory into separate .zip files:

for i in */; do zip -r "${i%/}.zip" "$i"; done

I had to do this to 75+ folders today and this definitely saved me some time. It works on macOS too!

Shoelace.style — A back to the basics CSS starter kit

2017-07-27T00:00:00Z

I spent some time last week working on a free CSS boilerplate I'm calling Shoelace.css. It's kinda like Bootstrap, but a lot leaner and pure CSS. You don't need a preprocessor like Sass or Less to use it, but it's still highly customizable with CSS variables.

I'm calling Shoelace a "starter kit", not a framework. The goal was to create a lightweight, fully customizable, and extensible boilerplate for building websites and web apps.

What makes Shoelace really awesome is that you can <link> to it with just one line of code and start using it. Customizations can be made in your own stylesheet by simply overriding variables:

:root {
  --body-bg-color: black;
  --body-color: white;
}

Shoelace is only ~31KB minified and comes in at about 7.9KB gzipped. For comparison, Bootstrap 4 alpha 6 is 192KB CSS + 47KB JavaScript. And, starting today, you can use Shoelace via CDN courtesy of KeyCDN.

For more info and to grab the source, head over to shoelace.style.

July 24, 2020: Shoelace 2.0 has been released. The library has become a collection of professionally-designed web components and is much different than the original version.

Downloading a list of URLs automatically

2017-07-21T00:00:00Z

I recently needed to download a bunch of files from Amazon S3, but I didn't have direct access to the bucket — I only had a list of URLs.

There were too many to fetch one by one, so I wanted to fetch them automatically. Here are a couple ways I found to do that.

Using curl

Curl comes installed on every Mac and just about every Linux distro, so it was my first choice for this task. Turns out it's pretty easy.

Create a new file called files.txt and paste the URLs one per line. Then run the following command.

xargs -n 1 curl -O < files.txt

Curl will download each and every file into the current directory.

Using wget

If you're on Linux or curl isn't available for some reason, you can do the same thing with wget.

Create a new file called files.txt and paste the URLs one per line. Then run the following command:

wget -i files.txt

Wget will download each and every file into the current directory.

Tip for macOS users: If you want to use wget on macOS, you can install it via Homebrew using homebrew install wget.

Surreal CMS acquires PageLime

2017-07-14T00:00:00Z

Nearly a decade ago, I launched my first SaaS application. It was a new take on content management — a hosted CMS that reads/writes directly to a web server and uses class attributes to define content regions.

It was a great idea. Such a great idea that it inspired others to do the same. One of those apps was called PageLime.

Over the years, I've seen a number of similar services come and go, but PageLime came out swinging. These guys had tons of energy. Hell, they even managed to get featured by Mashable in 2010. It was the first time I was actually worried about my competition.

I never imagined that seven years later I would acquire them.

What happened?

About three years ago, I noticed PageLime's support starting to slip. This was evidenced by users' feedback on Twitter and emails from new Surreal CMS users that were coming from PageLime.

Turns out, for whatever reason, PageLime's founders had moved on to other businesses and someone new had taken over support.

Since then, PageLime remained stagnant. Development stopped. The forum went offline. Then the blog was taken down. Sure, the website and service were still online, but they were just kinda there.

Down for a week

On May 25, 2017, Twitter users began reporting that PageLime was down. Sure enough it was, and it stayed down until June 2 with no official response from support.

I can only speculate as to what happened. I don't know why it took so long to get the service back online. It was upsetting to users, for sure, but it also upset me as a SaaS owner who takes pride in offering top notch support.

The acquisition

In early June, one of PageLime's co-founders contacted me about sunsetting the service. I outlined my vision for migrating users to Surreal CMS and we eventually came to an agreement for acquisition. (Details of the acquisition will remain private as part of the agreement.)

Over the last few weeks, I've worked diligently to create a tool that helps PageLime users migrate their account to Surreal CMS. My goal was to make the transition as seamless as possible for everyone.

Starting today, you can migrate your PageLime account to Surreal CMS in just a few seconds with the automated migration tool available on PageLime's website.

The shutdown

PageLime will officially shutdown on August 31, 2017.

To be clear, I didn't acquire PageLime to shut it down — that was already going to happen. I acquired it to offer users a seamless transition from one service to another, and Surreal CMS is undoubtedly the most qualified alternative for them.

Of course, the migration is completely opt-in. Users can decide if they want to migrate their accounts to Surreal CMS or seek another service. Those who do migrate will receive two weeks free to make sure Surreal CMS is a good fit for their business.

I encourage PageLime users to join the Surreal CMS community forum. It's a great place to ask questions, meet fellow designers, and show the community what you've been working on.

If you have questions about your PageLime account or the acquisition, please visit pagelime.com. If you need to talk to a human, there's a link on the homepage.

Rebuilding your Spotlight index in macOS

2017-07-14T00:00:00Z

I use Spotlight more than I like to admit, usually for launching apps. Recently, some of my apps and files stopped appearing — even ones I access frequently.

After sifting through numerous posts online, I finally discovered one that seems to work. Running this command in the terminal seems to do the trick:

sudo mdutil -E /

If you're having problem with just a certain disk, you can replace / with the appropriate device name (tip: drag the device into the terminal and let macOS input it for you).

Finally, my Spotlight is back to normal!

Thoughts on AMP

2017-05-23T00:00:00Z

Some time ago, a user asked about Google AMP support. At the time, I didn't know much about AMP aside from it made pages load faster on mobile devices. It sounded neat.

A couple weeks ago, I decided to dive in and integrate AMP with Postleaf. But the deeper I got, the more I realized exactly how it works and why it's terrible for the web.

I went on a Twitter rant about some of the issues I encountered, but I think it will be better to highlight why it's such a bad idea and why I ultimately chose not to add AMP in Postleaf. I'm sure I'll be linking people to this post in the future.

TL;DR – AMP is parading around as an open-source initiative that makes the web faster for mobile users, but it's really just Google's way of locking users into their own ecosystem.

The spec

First off, the AMP spec is way too strict:

You must include this exact style block on every page
The first child element in your <head> tag must be a meta tag specifying UTF-8 encoding
The second child element must be the AMP script
You must include a viewport tag with a specific value
You must put all your custom styles on the page using a <style> block
You must not use restricted CSS properties
You must not use scripts
You must convert certain HTML tags (such as <img> and <video>) to AMP-compatible tags
You must convert embedded content to AMP compatible components in order for them to render
The list goes on

I understand the reason behind some of these requirements, but I disagree with many of them and the overall implementation. As a web developer and publisher, I find it inconvenient and unnecessarily restrictive. This isn't how the web is supposed to be.

Components

While experimenting, I couldn't get a single <amp-iframe> to load without an error. For all embed providers I tested, the iframe rendered as an empty box. Turns out, the correct way to embed third-party content is with custom AMP components.

But guess what? If your content incorporates HTML from a third-party website (e.g. via copy & paste or oEmbed), there's virtually no way to convert it to an AMP-compatible component. The spec seems to assume your CMS will be aware of the embedded content's provider, but that isn't always true.

Furthermore, AMP doesn't have components for all content providers. You're stuck using the ones they want you to use. I'll say it again: this isn't how the web is supposed to be.

No scripts

This isn't necessarily a bad thing, but it has a terrible side effect. On one hand, you'll never seeing those annoying popover ads on an AMP page. On the other, you're not allowed to use any scripts. At all.

Want a custom nav menu? Sorry, you have to use the AMP sidebar. Want to build a carousel? Nope, you have to use the AMP carousel. Want a custom widget that AMP doesn't support? Nope, too bad.

If it hasn't become clear by now, AMP is about more than making your pages load faster. It's about locking users into Google's ecosystem.

A closed portal

It may sound like a conspiracy theory, but I'm not the only one who feels this way. Daniel Miessler writes:

[AMP is] a technology that makes mobile page results load very quickly on Google, it displays the content in a more uniform fashion. But there’s a problem.

The content loads off of Google’s own server, not from the website itself.

Think about that. By creating an AMP version of your content, you're effectively publishing it to Google's server and giving them permission to do pretty much whatever they want with it.

Daniel continues:

It’s poisonous to the underlying concept of an open internet.

If this were to become widely adopted, you’d search for something, get results, consume the content, and you’d never leave Google.

They want to be a portal, in other words. A portal that you never leave. And this is coming from the most successful and profitable advertising company in the world.

Who (other than Google) can possibly see this as a good thing?

Exactly. Their homepage claims that AMP is "an open-source initiative aiming to make the web better for all," but AMP isn't a good thing for anyone except Google. According to Scott Gilbertson:

So it's not really about speed. As with anything that eschews standards for its own modified version thereof, it's about lock-in. Tons of pages in Google AMP markup mean tons of pages that are optimized specifically for Google and indexed primarily by Google and shown primarily to Google users. It's Google's attempt to match Facebook's platform. And yes, Facebook is far worse than AMP, but that doesn't make Google AMP a good idea. At least Facebook doesn't try to pretend like it's open.

That's perhaps the worst part. Google has gone out of its way to make AMP seem like an open-source initiative, but the intention is anything but.

Also concerning is this post by Kyle Schreiber that discusses Google's governance policy over AMP:

Google has the ability to further change the AMP HTML specification to keep publishers in their ecosystem. Google already makes deleting AMP pages difficult. Despite touting AMP HTML as an open standard, every one of the AMP Project’s core developers appears to be a Google employee.

That doesn't sound nearly as open as their homepage claims.

Decentralized Publishing

One of Postleaf's founding principles revolves around a decentralized publishing experience. I believe this software should be open and free, just like the web is. Just like the web was intended.

You and only you should own and control your content. It's that simple.

Supporting Google AMP would go against this fundamental belief. It's something I feel very strongly about and it's something I've worked hard to instill into Postleaf.

The truth is, if you really want your pages to load fast, you don't need AMP. Take it from John Gruber:

Yes, AMP pages load fast, but you don’t need AMP for fast-loading web pages. If you are a publisher and your web pages don’t load fast, the sane solution is to fix your fucking website so that pages load fast, not to throw your hands up in the air and implement AMP.

Or, summed up in a tweet by yours truly:

Problem: your website doesn't load fast.

Solution: optimize, remove cruft, ditch 20+ analytics scripts, don't serve page-blocking ads.

— Postleaf (@postleafapp) May 21, 2017

That said, I think it's pretty obvious I won't be adding support for AMP in Postleaf anytime soon.

JSON Feed

2017-05-23T00:00:00Z

JSON Feed is a lot like RSS, except instead of XML it's formatted with JSON. It's a rather new spec, introduced just last week, but it's been getting some major coverage and a number of applications have already started supporting it.

Since Postleaf was built for the modern publisher, I decided to add support for it in alpha 5. It's just like John Gruber says, "easier to generate, easier to parse."

I expect to see a lot about JSON Feed in the coming months. I'm even happier to report that, within days of the spec being released, Postleaf is well-prepared!

Postleaf: reimagined

2017-04-26T00:00:00Z

It's been about nine months since Postleaf debuted as a simple, beautiful, open source, PHP blogging platform. The initial version was well-received, landing an article on TechCrunch and making its way to #1 for the day on Product Hunt. (Thank you so much, everyone!)

Today, I'm announcing something pretty big: A complete redesign, a new platform, and some amazing new features.

From the Ground Up

Postleaf has been redesigned from the ground up. I've moved the project to Node.js, refined the user interface, and added a number of incredible features that just work:

Inline editing
Distraction-free ("zen") mode with day and night support
Automatic responsive images via Dynamic Images
Themes via Dust.js
Fast, database-agnostic built-in search
Integrated file manager
Out of the box support for JSON-LD, OpenGraph, and Twitter Cards
oEmbed support for embedding third-party content
Spotlight-style search from anywhere in the admin panel
Simple backups (including content as easy-to-read JSON files, themes, and uploads in a single zip file)
Custom post templates (no limit to how many a theme can have)
Roles and permissions
And more

Everything you loved about the old version of Postleaf is still there and then some. And it's even more simple and beautiful than before.

You can get the source of the new version on GitHub.

Thoughts on uploads

2017-03-21T00:00:00Z

Uploads management is a concept I've always struggled with in Postleaf, but it's a necessary evil. Users have to be able to view and delete files they upload; but at the same time, I've never felt that it should be an integral part of the app.

Last night I had to face the fact that Postleaf isn't going to ship until it has a damn good uploads manager.

It was time to face the inevitable. I stayed up all night on a sort of vision quest for ideas, and ultimately came up with what I feel is the perfect solution for Postleaf.

The concept involves a panel that slides up from the bottom of the screen when the control is activated. Images and other files are displayed in lightbox-style gallery, along with the ability to search, delete, and download files. The panel can be dismissed by clicking or tapping outside of it or by pressing the escape key.

I created this concept because I don't believe the uploads manager deserves its own dedicated section in the admin panel. People use Postleaf to manage content, not files, so let's stay focused on what we came here to do.

Managing files is a secondary task, and this panel approach suits it well. The uploads manager can be accessed from anywhere in the app by pressing CMD + SHIFT + U. Alternatively, it can be activated by a form control and used as a file picker.

Here's a glimpse of an early prototype:

I chose a dark background because it brings more focus to your photos and files. I think it works really well, and I'm excited to bring this concept to life in Postleaf.

At this rate, I should have the uploads manager ready to roll in a couple days!

Importing plain CSS files with Sass

2017-02-10T00:00:00Z

When I first started using Sass, there was one thing that drove me crazy about it compared to Less. For some reason, including a plain CSS file just wasn't something the compiler wanted to do:

/* Uncaught, unspecified "error" event. (Ignoring local @import of "animate.min.css" as resource is missing.) */
@import 'animate.css';

But, annoyingly, the resource is there. So why does the compiler report it missing?

I may never understand the logic behind this design decision, but the solution is to simply omit the .css extension:

/* Imports animate.css */
@import 'animate';

This works as of version 3.2. And for those using Less, here's the equivalent syntax:

/* Import CSS file using Less */
@import (css) "animate.css";

Determining your app's base directory in Node.js

2017-02-09T00:00:00Z

Determining your app's base dir (or document root if you're from a PHP background) isn't as straight forward as you'd think in Node. Here's a little trick to get a globally available reference to your app's root directory.

Add this somewhere towards the start of your main app file (e.g. app.js):

global.__basedir = __dirname;

This sets a global variable that will always be equivalent to your app's base dir. Use it just like any other variable:

const yourModule = require(__basedir + '/path/to/module.js');

I know what you're thinking: oh no a global! 😫

And I would normally agree, but I think this technique is a fair exception if you're developing an app. Here's why:

There really isn't a consistent way to references the base dir without it.
It's a fair requirement to set if you're worried about reusing modules.
It's a lot easier and more stable than using ../../../file.js all the time.
It shares the same naming convention as __dirname and __filename.

There are, of course, other techniques that may or may not be more appropriate depending on your app. However, in my opinion, this approach is the most elegant.

Hashing Passwords with Node.js and bcrypt

2017-02-08T00:00:00Z

The bcrypt library on NPM makes it really easy to hash and compare passwords in Node. If you're coming from a PHP background, these are roughly equivalent to password_hash() and password_verify().

Bcrypt is the de facto way to hash and store passwords. For a brief explanation of why we use one-way hashes instead of encryption, check out this answer on StackOverflow.

Installing

To use the library, simply install with NPM:

npm install --save bcrypt

Then include it like this:

const bcrypt = require('bcrypt');

Creating and verifying a password hash

Bcrypt supports both sync and async methods. The asynchronous approach is recommended because hashing is CPU intensive, and the synchronous version will block the event loop and prevent your app from handling other requests until it finishes.

Thus, while the sync version is more convenient, it's best to stick with async if you're concerned about performance.

Asynchronous version

Hashing a password is as simple as this. The second argument is the number of rounds to use when generating a salt.

bcrypt.hash('myPassword', 10, function(err, hash) {
  // Store hash
});

To verify the password later on:

bcrypt.compare('somePassword', hash, function(err, res) {
  if (res) {
   // Passwords match
  } else {
   // Passwords don't match
  }
});

Synchronous version

If you prefer a synchronous approach, you can do this instead:

let hash = bcrypt.hashSync('myPassword', 10);

// Store hash

To verify the password later on:

if (bcrypt.compareSync('somePassword', hash)) {
 // Passwords match
} else {
 // Passwords don't match
}

That's it! You've just hashed and verified your first password using Node.js and bcrypt!

Using an ORM

2017-02-06T00:00:00Z

I've never really bothered with ORMs before, as feelings for them tend to be mixed. I've heard that you can spend twice as long learning an ORM as you can coding raw SQL. 🤷🏻‍♂️

I figured it was time to see for myself. For the Postleaf rebuild, I decided to try out Sequelize. I discovered it some time ago and really liked what I saw, but never had a chance to use it. I'm glad I finally did.

The previous version of Postleaf required MySQL. All the models were written from scratch, including CRUD methods (create, read, update, delete) and validation. Believe me when I say that you can waste a lot of time writing your own CRUD methods.

To make matters worse, some of the queries were proprietary, meaning they'd only work with MySQL. I've wanted to remove that requirement for a long time.

An ORM can alleviate these pain points. Sequelize, for example, lets you define models and validation using a simple JSON object. It even creates the database schema and models for you, after which you can query the database without writing any SQL at all.

For example:

// Find the user named Joe
User.findOne({
  where: {
    name: 'Joe'
  }
}).then((user) => {
  console.log(user.name); // "Joe"
});

That's roughly the same as this:

SELECT id, name, email FROM users WHERE name = 'Joe'

It may seem a bit more verbose for simple queries, but once you start associating models the benefits are more easily understood. With just one additional line of code, I can fetch the user along with all of his posts:

// Find Joe and fetch all of his posts
User.findOne({
  where: {
    name: 'Joe'
  },
  include: Post
}).then((user) => {
  console.log(user.name); // "Joe"
  console.log(user.posts); // Posts authored by Joe
});

It gets even more exciting when you realize that Sequelize doesn't just return the raw data, it returns the data as a series of model objects. That means you can do things like this:

// Find Joe and change his name to Bob
User.findOne({
  where: {
    name: 'Joe'
  }
}).then((user) => {
  user.name = 'Bob';
  user.save(); // commit to database
});

Since raw SQL queries are abstracted into code, I don't have to worry about database-specific quirks — Sequelize does all that in the background. As long as I stick to their API (and avoid database-specific features), Postleaf will be able to run on top of any database that Sequelize supports. (Currently SQLite, MySQL, MariaDB, MSSQL, and PostgreSQL.)

For now, I've decided to develop with SQLite. It's fast, and I love having a single database file in a known location that you can quickly duplicate or replace. It's great for testing, but I'm definitely trying to support all five platforms for release!

Solving the search problem

2017-02-06T00:00:00Z

I recently wrote about using an ORM and how it allowed me to support five different database platforms with minimal effort. There is, however, one feature that even Sequelize couldn't tackle for me: full-text search

A full-text search is typically a database feature that lets you locate content just like you would in a search engine. Ideally, the results are ranked by some sort of relevancy score.

The problem is that not all databases support full-text search out of the box, and the ones that do don't necessarily rank results the same way.

Searching with SQLite

I'm using SQLite at the moment for development, and while it supports full-text search, you have to use one of three possible extensions (FTS3, FTS4, FTS5) that must be compiled along with SQLite.

Having three extensions is confusing enough, much less making users compile their own version of SQLite just to run Postleaf. And none of this accounts for the four other database dialects that I'd like to support.

Searching with MySQL

The previous version of Postleaf ran on top of MySQL, which has a built-in full-text search. Once you create an index, you can search against content with relative ease. Results are reasonably relevant, but not amazing.

Some quirks — it ignores any term that's three letters or less. So a search for "cat" will always yield zero results. And if you want to rank a post's title higher than its content (a weighted search), you have to do the math and write the raw SQL yourself. Lame.

Solving Search is hard!

It's true, search is hard, but this problem is much bigger than Postleaf. Ghost has a two year old issue about it and a lot of people complain that WordPress searches lack relevance.

Sure, if you focus on one particular database or avoid full-text altogether, you can achieve a search that will yield somewhat usable results. It will work, but it won't be amazing. I think that's because databases really weren't meant to do this type of thing.

A more effective way to solve this problem is with a dedicated search engine such as Elasticsearch. Elasticsearch delivers fast, relevant results which is just what we're looking for! Except, of course, it's written in Java and can be somewhat difficult to setup.

Making a complex third-party app a dependency of Postleaf was simply not going to happen. And while there are other options out there, they tend to be more complicated than they're worth for the simple search that I needed for Postleaf.

Experimenting with Lunr

After some searching around, I began experimenting with a JavaScript library called Lunr. Lunr can be used with Node.js apps or directly in the browser.

Essentially, you define an index with the fields you want to search. You can weight a field using the boost option:

var index = lunr(function() {
  this.field('title', { boost: 10 });
  this.field('content');
  this.ref('id');
});

Then you add items to the index:

index.add({
  id: 1,
  title: 'Lorem Ipsum',
  content: 'Lorem ipsum dolor...'
});

And then you can search quite easily:

index.search('lorem ipsum');

Lunr is fast, lightweight, and JavaScript. And it's results are spot on! I immediately knew it would be a key component to my full-text search solution, but some challenges still remained.

Implementing Lunr in Postleaf

My initial approach to implementing Lunr turned out to be expensive. I wanted to see how fast fetching, indexing, and searching would be on the fly. It looked something like this:

Fetch id, title, and content of all posts when a request comes in.
Create a Lunr index.
Add each post to the index.
Search the index for the user's query.
eturn all posts that matched the IDs that Lunr had returned.
DesTroy the Lunr index.

This happened on every single request requiring a search. Obviously it wasn't ideal, but I was surprised at how well it performed even for 1,000 posts. At some point after that, the delay became somewhat noticeable (I think it was 2-3 seconds or so per query).

I ended up optimizing my approach so the search index is only built once when the app starts. The index persists in memory and, using Sequelize hooks, it stays up to date when you add, update, or delete posts.

Since the search happens 100% in memory, it's incredibly fast.

The biggest drawback to this approach is, of course, keeping the search index in memory. However, for 10,000 posts I extrapolated a footprint of just under 30MB. If you have that many posts, I hope your VPS is strong enough to handle it. 😆

Needless to say, the Postleaf rebuild is shipping with a fast, relevant, database-agnostic full-text search thanks to Lunr and a very clever Node.js implementation.

Moving to Node.js

2017-02-06T00:00:00Z

The first version of Postleaf was written in PHP and lives on as Leafpub. It's a beautiful piece of software that I'm very proud of, but I decided to move the project to Node.js for a few important reasons. This is by no means a knock on PHP, which will always have a special place in my heart, but more of a changing with the times realization.

If you've ever worked with Node.js before, you'll know that it's fast. Very fast. The beauty of Node is that it's minimal by design. It can do anything you want it to do with the right packages, and this concept aligns very closely with my vision for Postleaf.

You've probably been hearing JavaScript is the Future a lot lately. I think there's a lot of truth to that statement, especially as platforms such as Electron and PhoneGap gain popularity and bring JavaScript to places it's never been before.

In general, I don't think it makes a lot of sense to write the same app three different times in three different languages for three different platforms (think iOS, Android, and Windows Phone apps, for example). We've been doing it for years, but I foresee JavaScript playing a vital role in closing that gap.

By moving Postleaf to Node.js, its foundation is becoming much more nimble, making it easier to pivot and adapt to an ever-changing technology ecosystem. That, unfortunately, is something I don't think PHP will be able to do.

SSH failing on macOS Sierra

2017-01-15T00:00:00Z

For me, upgrading to MacOS Sierra broke a lot of things that use SSH, including Transmit, Sequel Pro, and a handful of other apps. In fact, it seems to break any app that uses an SSH key with a passphrase. 🤔

The solution I found was to tell SSH to use the MacOS keychain. Simply edit ~/.ssh/config and add the following (you can safely create the file if it doesn't exist):

Host *
    UseKeychain yes

That's it! I didn't even have to restart SSH and everything is connecting fine again. 💪

Getting it right

2017-01-14T00:00:00Z

To my awesome users:

I've been taking some time to reimagine what Postleaf should have been. Yes, the betas were pretty awesome, but they weren't what I wanted them to be in terms of design, code, and function. I can do better, and you deserve nothing less than my very best.

The last few months were difficult for me as I struggled to find my place in the world of content management. I thought about giving it up and getting out of software altogether. My vision was cloudy, my passion had faded. Recently, I looked at Postleaf from a completely different perspective and everything started to make sense again.

I have a vision to bring simple, beautiful publishing to the world. And I'm not going to stop until I get it right.

Thanks for giving me the time I needed to find myself.

Postleaf will be back very soon. And it will be better than you ever imagined.

— Cory

SimpleImage 3.0

2017-01-10T00:00:00Z

Back in 2011, I released the first version of SimpleImage for PHP — an open source project for working with images.

Today, version 3.0 has landed, and there's a lot to love about it.

Overview

Here's how it works at a glance:

try {
 // Create a new SimpleImage object
 $image = new claviska\SimpleImage();

 // Magic! ✨
 $image
  ->fromFile('image.jpg') // load image.png
  ->autoOrient() // adjust orientation based on exif data
  ->resize(320, 200) // resize to 320x200 pixels
  ->flip('x') // flip horizontally
  ->colorize('DarkBlue') // tint dark blue
  ->border('black', 10) // add a 10 pixel black border
  ->overlay('watermark.png', 'bottom right') // add a watermark image
  ->toFile('new-image.png', 'image/png') // convert to PNG and save a copy to new-image.png
  ->toScreen(); // output to the screen

 // And much more! 💪
} catch(Exception $err) {
 // Handle errors
 echo $err->getMessage();
}

Requirements

PHP 5.6+
GD extension

Features

Supports reading, writing, and converting GIF, JPEG, PNG, WEBP formats.
Reads and writes files and data URIs.
Manipulation: crop, resize, overlay/watermark, adding TTF text
Drawing: arc, border, dot, ellipse, line, polygon, rectangle, rounded rectangle
Filters: blur, brighten, colorize, contrast, darken, desaturate, edge detect, emboss, invert, pixelate, sepia, sketch
Utility methods: color adjustment, darken/lighten color, exif data, height/width, mime type, orientation
Color arguments can be passed in as any CSS color (e.g. `LightBlue`), a hex color, or an RGB(A) array.
Support for alpha-transparency (GIF, PNG, WEBP)
Chainable methods
Uses exceptions
Load with Composer or manually (just one file)

The readme has a list of changes from the 2.x version of SimpleImage.

Download

Download the latest version on GitHub.

Don't hate on PHP

2016-11-22T00:00:00Z

It wasn't long after launching a major open source PHP project until I started hearing things like this:

I [...] immediately drop interest in a project when I see that it is implemented in PHP.

A lot of people have been hating on PHP in recent years, and frankly, they have every right to. In fact, you can hate on any language you want for whatever reasons you want. I could honestly care less.

But let me stop you from generalizing that opinion and shoving it down everyone's throat.

Sure, there are plenty of things I would change about PHP if I were the one designing it. I could say the same thing about every single programming language in the world, but that's not my job. I'm not engineering programming languages, I'm building web applications with them. And I'm certainly not going to undermine the hard working people who are designing these languages, whether I prefer to use them or not.

It's just a tool

What developers seem to forget is that programming languages are nothing more than tools that help you get something done. Just like the tools in your garage, each and every one has a special purpose. Not every tool will work well for every job, and some tools do the same exact thing in very different ways. Variety is the spice of life.

But nobody tells a roofer his hammer is shit. Nobody tells a plumber his pipe cutter sucks. Nobody tells a carpenter his level is garbage. Each craftsman has their own preference based on their own experience, and that's perfectly acceptable.

If you don't like a tool, put it back in the toolbox. It's that simple. Don't run around telling everyone how shitty a programming language is because you don't like it. It might be your opinion, but it's a subjective, arrogant, and disrespectful opinion. Instead of coming off as a conceited asshole, use your expertise to advise people why a specific tool might be better for a specific purpose.

Even if you're right with your reason, it won't matter if you're wrong with your approach. We're supposed to be professionals — what say we start acting like it? Who knows what tomorrow will bring. For now, let's stop fussing over the tools we're using and focus on the goals we're trying to accomplish.

Thoughts on comments

2016-06-12T00:00:00Z

For as long as I can remember, comments have been a staple of blogging software. After all, what's a good blog post without a relevant discussion to accompany it?

You might find it strange to learn that Postleaf doesn't ship with comments. This is by design, and I'll explain why in this post.

The Comment Problem

Everyone thinks they want comments on their blog. That is, until they have to deal with the problems that those comments create. The biggest problem is by far comment spam. This is such a huge issue that the makers of WordPress established a dedicated service just to fight it.

But why does it happen? Well, spammers post bogus comments, those comments contain links, and those links make them money when people click. Since it costs them practically nothing to do it, they keep posting comment spam. A lot of it.

Fighting Spam

There are many ways to fight comment spam. One is to moderate all comments before they go public. This really sucks because comments don't go live immediately and you have to manually approve every single one. That makes it hard to have a discussion and it can fill up your inbox.

Another approach is to add some kind of crazy CAPTCHA test to your comment form, but these can be difficult even for humans and often discourage visitors from leaving comments.

Perhaps the most effective approach is to require users to create an account, verify their email address, and then let them post. But let's be honest, how many people are actually going to take the time to do that? In my experience, not very many. Most people aren't comfortable typing their email address into a web form, so they're probably not going to give you their name, email address, and a password.

Everyone Has An Opinion

Yes, everyone. And many of them feel invincible hiding behind their keyboard so they're not afraid to force that opinion down your throat in the comments. Which brings us to the next big problem with comments: accountability.

Even if you force users to create an account before posting a comment, there's nothing stopping them from using a bogus name and email address. You're going to end up with a lot of flaming, trash talking, and senseless discussions because there's a huge lack of accountability on the Internet.

So how do we fix that? Well, I could spend the next year trying to develop the perfect comment system for Postleaf, but it's a massive undertaking and, to be honest, it would probably never really be good enough.https://xkcd.com/233/

So what now? Do we ditch comments altogether? 🤔

A Better Way

Some time ago, I got tired of dealing with comment problems and disabled them on my blog. The conversation went quiet, and I started to feel alone in the world. (Ok, not really, but still, not allowing comments at all was pretty lame.)

Eventually, I decided to try out Disqus. I added a small JavaScript snippet to my website and BOOM, comments. But not just any comments, good comments.

Why Disqus Works

The power of Disqus is in its community. Users login to their Disqus account (which they can create from your site if they don't already have one) and they're able to post comments to your blog.

You're probably wondering, "how is this any different from letting them create an account on my website?"

It's very different, because they only need to create one account which can be used on any website that runs Disqus. You have immediate access to millions of registered users that you don't have to bother keeping track of. Furthermore, Disqus lets users login through Facebook, Twitter, or Google, which provides the best form of accountability you're going to get on the Internet.

Since I started using Disqus, I haven't had to deal with comment spam and the conversation has been just that — a conversation. Disqus handles notifications so I know when people post comments and they know when I respond. I can even reply to notifications with various commands to moderate comments by email — a huge time saver! 📫

Update: February 26, 2017

As of February 2017, Disqus converted their free plan into an ad-supported plan. That means, unless you remove Disqus from your website or fork up $10 per month, your website is going to show ads.

I'm in no way opposed to a SaaS making money, but this feels like a bait and switch. Nobody gets to opt out. Nobody gets grandfathered in. You either pay up, stop using Disqus, or your visitors get subjected to whatever ads Disqus wants to show on your website.

Not having control over one's own website is something I'm vehemently against.

Comments in Postleaf

Comments shouldn't be a chore. They should form relevant, civil discussions that engage your visitors. When you spend all your time moderating comments, you end up with less time for the finer things in life.

That's why I intentionally left comments out of the Postleaf core. If you want them, I suggest finding a third-party platform or service that suits your needs for now. They are absolutely the best way to promote relevant discussions on your blog without the hassle of dealing with traditional comments.

Code can change

2016-05-10T00:00:00Z

As a web developer, your code is often visible to anyone who wants to review it. If you're like me, you might get stressed out about the thought of people looking at your work and critiquing or criticizing your app's design.

Take a deep breath, recenter, and remember that code can always change. That's why we have version numbers!

Even the most seasoned developers have their own opinion of what "good design" is. No matter how long you spend engineering or reworking your app's design, there's always, always, always going to be more ways to improve it. In fact, the code you write today will probably look like crap to you a year from now. That's part of the learning process.

Remember, code is dynamic. It's meant to change. So don't obsess about making it perfect. Just make it work, make it easy to understand, and realize you'll probably be changing it one day.

A better way to write config files in PHP

2016-05-02T00:00:00Z

How many times have you seen something like this in a config file?

$db_host = 'localhost';
$db_name = 'somedb';
$db_user = 'someuser';
$db_pass = 'somepass';

Then, of course, it gets included and the variables are referenced as globals:

include('config.php');
echo $db_host; // 'localhost'

A better way

I'm not a fan of using global variables when they can be avoided, so here's an alternative that gives you much more flexibility with your config files.

return [
  'host' => 'localhost',
  'name' => 'somedb',
  'user' => 'someuser',
  'pass' => 'somepass'
];

Simply returning the array allows you to include it into any variable you choose, which is much nicer than cluttering the global namespace with your config.

$database = include('config.php');
echo $database['host']; // 'localhost'

Of course, you can return any data you want with this approach — even a multidimensional array.

return [
  'database' => [
    'host' => 'localhost',
    'name' => 'somedb',
    'user' => 'someuser',
    'pass' => 'somepass'
  ],
  'other-stuff' => ...
];

This is by far my favorite way to write config files in PHP.

How to upgrade or downgrade Node.js using npm

2016-04-05T00:00:00Z

Need to update your version of Node.js? Here's how you can upgrade or downgrade from the command line using npm.

Upgrading to the latest stable version

This will update you to the latest available stable version:

sudo npm cache clean -f
sudo npm install -g n
sudo n stable

Upgrading to the latest LTS version

Node also offers a long-term support (LTS) version. If you need that version (or any other), simply specify the version number you want:

sudo npm cache clean -f
sudo npm install -g n
sudo n 4.4.2

Checking your Node version

To see which version of Node is currently installed, simply run:

node -v

The version number displayed is the one that's currently active on your machine.

Adding and removing virtual hosts on Ubuntu 14.04

2016-03-29T00:00:00Z

Here's a cheat sheet for working with virtual hosts on an Ubuntu server. The instructions assume you're not logged in as the root user. Change example.com to your own domain/subdomain.

Adding a virtual host

Create the directory for your new site and grant permissions. If your user isn't part of the www-data group, you might want to adjust the second line:

sudo mkdir -p /var/www/example.com/public\_html
sudo chown -R $USER:www-data /var/www/example.com/public\_html
sudo chmod -R 755 /var/www/example.com

Add an index page (optional):

vim /var/www/example.com/public\_html/index.php

Create the virtual host config file:

sudo vim /etc/apache2/sites-available/example.com.conf

Here's a very basic example config file you can start with. Paste it in and adjust as necessary:

<VirtualHost *:80>
  ServerAdmin admin@example.com
  ServerName example.com
  ServerAlias www.example.com

  DocumentRoot /var/www/example.com/public\_html
  <Directory /var/www/example.com/public\_html>
    Options -Indexes
    AllowOverride All
    Order Allow,Deny
    Allow from All
  </Directory>

  ErrorLog ${APACHE\_LOG\_DIR}/error.log
  CustomLog ${APACHE\_LOG\_DIR}/access.log combined
</VirtualHost>

Now enable the new virtual host and restart Apache:

sudo a2ensite example.com.conf
sudo service apache2 restart

If your DNS is already configured, your site should be available at example.com.

Removing a virtual host

First, disable the virtual host and restart Apache:

sudo rm /etc/apache2/sites-available-example.com.conf
sudo rm -Rf /var/www/example.com

At this point, the site is disabled and will no longer be accessible.

Now just remove the config file and cleanup the /var/www/ directory to permanently remove the site and all of its files:

sudo rm /etc/apache2/sites-available/example.com.conf
sudo rm -Rf /var/www/example.com

Lessons from a failed Kickstarter

2016-03-28T00:00:00Z

Last week, I launched Particle on Kickstarter. Today, I pulled the plug and canceled the campaign. We had 50 backers and were 5% funded. So why would I do this with 25 days left to go?

The fact is, this campaign failed before it started, and it was all my fault. I became so consumed by building and running the Kickstarter that I lost my focus on the product I was creating. Here are some of the things I did wrong and why I terminated the campaign early.

Not building a following

The most important element to a successful crowdfunding campaign is reaching people. Not just anyone, but people interested in what you have to offer — potential backers. Before launching on Kickstarter, I was well aware that many campaigns spent months or even years building a following prior to launching.

This was my fatal mistake. I thought I could bypass this requirement because I had a network of online properties geared towards web designers and developers (to the tune of 200,000 visitors a month). I went all in hoping to cross promote Particle to people who didn't know what the hell it was and people who weren't even looking for it.

The results of this obviously weren't favorable. In hindsight, I would have been better off buying ad space on the back of milk cartons. Or maybe not...

Relying on advertisements

As a SaaS owner, I'm no stranger to buying banner ads to promote my services. When I realized my first plan of action wasn't performing very well, I figured I'd try a paid advertisement. I knew this was a bad idea, but surely people would see how great my unreleased Kickstarter product was in a 300x125 banner ad and start throwing dollar bills at it!

Yeah, what was I thinking? It only took a couple days to confirm this mistake. Even with a million impressions that ad wouldn't have come close to paying for itself — and this was a highly targeted website too. Fortunately, I was able to switch it to point to my other service so it wasn't a complete waste of money.

In short, if you rely on ads to drive traffic to your crowdfunding campaign, you're gonna have a bad time.

Falling for kickstarter spam

Something I didn't realize until after my campaign launched is that you'll receive a ton of spam through Kickstarter's messaging system. You'll get messages from people who seem legit, but obviously aren't when you look closely at their profile (hint: a signup date of today is a dead giveaway).

People will offer to write and submit press releases for you, "enhance your SEO," send out "social media blasts," and more. They'll promise to boost your campaign's numbers and they'll boast about how successful their services have been with similar crowdfunding campaigns. One clever spammer even took the time to locate my email address and message me outside of Kickstarter's system. Nice try, dude!

These offers may seem tempting, but most of them are scams — some more obvious than others. I only fell for one called BackerClub, which costs $379, but you only pay if you receive $379 or more from backers in their network. Sounds too good to be true, right? It is. Here's how they scam you.

BackerClub pretends to be exclusive. You have to "apply" to be featured in their network. Soon after, you'll receive an email telling you that you've been accepted, but due to some bogus algorithm, they need $79 up front to make it worth their while to feature your campaign. If you're stupid enough to pay it, they'll send out a couple emails (probably just to you, who knows) that will drive pretty much zero traffic to your campaign.

It's amazing how crowdfunding has spawned an entire ecosystem of scumbags who feed off creators that are trying to raise money for projects they've put so much heart and soul into. Trust me, no matter how desperate you are or how good it sounds, it's bullshit.

This goes hand in hand with not building a following, but I did have a little bit of success promoting Particle on Twitter. Obviously, your results will be better if you have a strong network established and you maintain proper etiquette.

The problem with Twitter, however, is that you can't really reach out to people without spamming them. That's sort of the nature of their platform, but it's still freaking spam. Although some backers did originate from Twitter, the whole social media thing went south rather quickly.

It starts with an innocent post that you pin to your profile. Then you reach out to a few people who follow you but you only sort of know. Then you try to insert yourself into relevant conversations with people you don't know. Then you use Advanced Search to look for derogatory things about your competitors and feed on peoples' frustrations by trying to save the day with — guess what — a fucking Kickstarter link asking them for money!

You start crapping out links to your project with every tweet and your whole social media strategy turns into a total shitfest that you're embarrassed to look at the following day.

Don't "promote" your campaign like I did. While I did recruit a handful of backers from Twitter, it wasn't worth the effort or the dent in my reputation. There's a right way and a wrong way to promote things on social media. That was the wrong way.

Hoping for a break

If your Plan B involves sending emails to everyone at TechCrunch, Mashable, and every other big name blog you can think of hoping to get picked up, don't fucking launch a crowdfunding campaign.

I knew this from the start, but I figured I'd try anyway. I spent two days sending out personalized emails inviting journalists, bloggers, or whoever else I thought would be interested in a private, prerelease demo of Particle. Crickets.

It's not that they don't give a shit about Particle, they just have a million emails a day flooding their inbox. You really have to stand out, and even that's probably not enough if you haven't actually launched your product yet.

Honestly, who wants to write about a blogging platform that hasn't launched yet? Not TechCrunch or Mashable, that's for sure.

Not having a shill

Crowdfunding is a tough nut to crack if you're a new creator. It would have helped a lot to have the support of someone reputable openly supporting the project. In Particle's case, a well-known blogger, for example, could have helped spread the word and instill more confidence in potential backers.

Quantum Chess is a great example. They managed to get Paul Rudd to make a comedic video of him and Stephen Hawking playing the game, and that propelled them to exceed their funding goal by almost $3,000. Really, almost $33,000 for a digital chess game (that I'm also guilty of backing). You need a shill.

Letting it consume you

Those are all things I failed gloriously at in terms of promoting the campaign, but that's not the reason I pulled the plug. Even if Particle wouldn't have met its funding goal, it would have been fun to see just how much it would have reached.

By far, what I hated most about running a crowdfunding campaign was how it completely consumed me. I knew it would be a lot of work, and I'm OK with a lot of work, but I wasn't aware of how it eats your soul, shits it out, and then eats it again.

I spent a month and a half building Particle's campaign, obsessing over each and every little detail. I filmed the video twice, then bought a new camera and filmed it at least four more times trying to get it right. I rewrote the script countless times. I added closed captions to both videos. I spent hours looking for the right music, budgeting, planning out rewards, tweaking content, and crafting images to make Particle as sexy as possible on Kickstarter. I did everything except what I actually like to do, and I wasted a lot of time doing it.

I remember looking at the launch button last Tuesday. After so much preparation, was it finally time? I knew I wasn't prepared well enough, but I couldn't afford delaying any longer. Or maybe I just couldn't stand being away from the code as long as I'd been. Maybe I was just fed up with staring at myself and watching screencasts of Particle for hours on end. That stupid music still plays in my head.

With an audible "fuck it," my finger clicked the launch button.

That's when I should have realized I made the wrong decision. I didn't prepare well enough, but I was so ready to be done creating that stupid campaign that I just couldn't stand it any longer. I just wanted to get it over with.

Particle launched when it shouldn't have launched. In fact, it probably never should have been on Kickstarter. I became too consumed by the magic and allure of crowdfunding that I completely lost my ability to think straight. Now, just five days into the live campaign I'm beginning to lose my mind. What has this circus act turned me into? This isn't me. This isn't Particle.

What's next?

I spent a year and a half building this software, so I'm obviously not giving up on it. Particle is a great product. In fact, I'm using it to write this very post on my iPad and it truly is the best blogging experience I've ever had. No bullshit. Inline editing is awesome!

But I've realized that trying to jumpstart this project by crowdfunding isn't as appealing as it once was. Yes, the software is fully functional, but there are still things I'd like to improve before I send it off into the world. Having a big chunk of money isn't worth the added stress of deadlines to meet and backers (micro-investors?) to answer to. More importantly, wasting another month trying to get that chunk of money seems more and more ridiculous with each day I spend emailing Mashable and pissing people off on Twitter. Particle will be ready when it's ready, and that's how it should have been all along.

I would still like to open source Particle and turn it into a sustainable business. On the other hand, I have a family to feed and a lot of time vested in this project. I can't afford to give away nearly two years of work with absolutely no way to monetize it. That would leave us with no food on the table and no money to continue working on Particle, which means we starve, the project fizzles out, and everyone loses.

Particle needs a premium service or some alternative way to make it sustainable before it can be open sourced.

There's a light

I do have some great news: I've teamed up with a good friend who also happens to be one of the best developers I know. After studying Particle's code, he's decided to come onboard to help out with development. This will definitely help speed things up! We'll be taking some time this week to discuss the best approach for releasing Particle, be it open source, SaaS, or a combination of both. Anything is game at this point. Except fucking crowdfunding.

For those of you who backed Particle, please get in touch with me on Twitter or email (cory at this domain) — I have some stickers for you. For everyone else, you can either follow Particle on Twitter or signup for the mailing list to stay up to date.

Even though Particle wasn't a good fit for Kickstarter, we're still going to bring inline editing to blogging. It's coming. It's just a matter of time now.

— Go forth and create!

Update: Particle has been renamed to Postleaf and is now available at postleaf.org.

Democratizing publishing

2016-03-28T00:00:00Z

One of the objectives Matt Mullenweg has for WordPress is to democratize publishing, which is excellent. But the very same article states another objective is to "capture the 75 percent of the internet that WordPress doesn't already manage."

In my opinion, these goals conflict with each other. If Matt truly wanted to democratize publishing, he wouldn't be trying to monopolize it. That's how you destroy a democracy, not create one.

Of course, WordPress will never truly have 100% of the Internet, but the thought of closing in on that goal is very frightening. I've been a developer long enough to remember all too well how Internet Explorer 6 stifled innovation for many years.

The same will happen as WordPress closes in on their goal, and that's exactly why we need more open source options like Ghost.

Some words of wisdom from Nancy Pearcey:

Competition is always a good thing. It forces us to do our best. A monopoly renders people complacent and satisfied with mediocrity.

Now, go forth and create!

Animated CSS hamburger icons

2016-03-07T00:00:00Z

If you need some tasty CSS hamburger icons that animate in fantastic ways, here you go.

Hamburgers is an MIT-licensed CSS library that gives you over a dozen beautifully animated navicons for use in your own projects. Also includes the Sass source so you can customize and compile it yourself.

This is a beautiful little library!

Flushing DNS cache on macOS

2016-03-02T00:00:00Z

Here's the best way to flush DNS cache on macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; say cache flushed

Notice that last part — that's why this is the best method. You get an audible "cache flushed" almost instantaneously, and the whole process becomes that much more satisfying.

Another fun variation:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; say booyah!

Have at it. It may be silly, but it's the little things in life. Now, go flush that DNS!

A clean fade-in effect for webpages

2015-09-23T00:00:00Z

Here's a nice way to fade your pages in using CSS and a bit of JavaScript. The solution is clean and smooth, with no flickering on load. If JavaScript is disabled, the page will still load but the fade effect will not occur.

How it works

This trick works by adding the fade-out class to your body with a script, then removing it when the page is done loading. The fade effect is handled completely with CSS. We're only using JavaScript to add/remove the class, which will ensure the page still displays if scripts are disabled.

The CSS

We start with two very simple styles for the body:

body {
  opacity: 1;
  transition: 1s opacity;
}

body.fade-out {
  opacity: 0;
  transition: none;
}

The JavaScript

Now we need to add the fade-out class to the body as soon as the page loads. We can do this with an inline script right after the opening <body> tag:

<script>
  document.body.classList.add('fade-out');
</script>

The inline script is necessary (as opposed to a script loaded from a separate file) to prevent flickering, as the body would otherwise be briefly visible until the extra script is downloaded by the browser.

Now we just need to remove the fade-out class from the body once the page is loaded.

window.addEventListener('DOMContentLoaded', () => {
  document.body.classList.remove('fade-out');
});

Changing the fade color

By default, the user will see a blank white screen until the page fades in. This is customizable through the html selector:

html {
  background-color: black;
}

Tips

Don't get too carried away with this. It's a useful effect for loading something like a homepage, but it can quickly get annoying if you apply it to every page. Keep it subtle. Users shouldn't actually notice it — it should simply be a pleasant part of their experience.

This is a really helpful trick if you need to wait for an image or video to load. However, in that case you'll probably want to add a loader. To achieve this, simply add a wrapper element around everything except the loader and apply the fade-out class to that instead of the body.

How to remove box shadows from input controls on iOS

2015-09-16T00:00:00Z

Those default box shadows that appear inside of your input elements on iOS can be pretty annoying, especially if you're going for a flat or subtle look. Here's how to remove them.

Unfortunately, it's not as simple as setting the box-shadow property to none. Instead, you have to alter the -webkit-appearance property:

input[type=text],
input[type=email],
input[type=password],
textarea {
  -webkit-appearance: none;
}

That gets rid of the shadow but, for best results, you'll probably want to set your own border, background, and — perhaps ironically — your own box shadow.

Passing data from PHP to JavaScript

2015-03-05T00:00:00Z

Have you ever needed to send a PHP variable, array, or object to JavaScript? It can get complicated trying to escape the output properly. Here's a way that always works — no escaping necessary.

Let's say we have the following variable in PHP:

$name = 'Bob Marley';

And we want to pass it to a JavaScript variable called name. Here's the trick:

echo '<script>';
echo 'var name = ' . json_encode($name) . ';';
echo '</script>';

Using json_encode(), you'll always get a properly formatted JavaScript object.

The same trick can be applied to other data types (e.g. integers, arrays, objects, etc.). The following passes an entire array from PHP to JavaScript:

$shirt = array(
  'color' => 'blue',
  'number' => 23,
  'size' => 'XL'
);

echo '<script>';
echo 'var shirt = ' . json_encode($shirt) . ';';
echo '</script>';

The output looks like this:

<script>var shirt = {"color":"blue","number":23,"size":"XL"}</script>

Don't want it all on one line? Try this instead:

echo "<script>\n";
echo 'var shirt = ' . json_encode($shirt, JSON_PRETTY_PRINT) . ';';
echo "\n</script>";

The output is a bit easier to read:

<script>
var shirt = {
  "color": "blue",
  "number": 1000,
  "size": "XL"
};
</script>

A simple trick, but nevertheless useful.

The HTML5 download attribute

2015-02-19T00:00:00Z

Years ago I showed you how to force a file to download with PHP. Now with HTML5, you [almost] don't have to do that anymore.

The HTML5 download attribute is intended to tell the browser that a certain link should force a certain file to download, optionally with a certain name that might be different than that on the server. Here's what it looks like:

<a href="/path/to/file.txt" download="any-name-you-want.txt">Download</a>

This will tell your browser to download file.txt and prefill the name to any-name-you-want.txt. No fancy server-side code required. As Mozilla notes, you can also use this technique with data URLs.

Now, of course, the caveat. Internet Explorer doesn't support it, and creating a polyfill isn't really possible. Although you could probably use a combination of feature detection and a proxy server to force the download, but that's really more effort than it's worth.

Get comfortable with abstraction

2015-02-18T00:00:00Z

I stumbled across a tweet the other day and it's been resonating in my mind ever since. Mostly because it's something I tend to have a problem with.

You see, I have this thing where I try really hard to understand exactly how something works — all the way down to the last nut and bolt. Deep down I know that those details are usually irrelevant. But it bothers me to know there are things that I don't know.

I have a problem with abstraction.

So I'm posting this comic as a reminder for myself to look beyond the details and focus on the big picture. Maybe you'll enjoy reading it too.

Comic courtesy of Abtruse Goose

Thoughts on being a good manager

2015-02-09T00:00:00Z

Some thoughts I had after conversations with a friend who has a terrible manager. This isn't nearly a comprehensive list, but it highlights many of the problems they were experiencing. Maybe my friend's manager will stumble upon it some day.

When someone has a grievance, take an objective stance. Listen to them, understand what they're trying to tell you, and react accordingly. Don’t deny issues that really are issues, and don’t ignore them in hopes that the problems just go away. They won’t. They’ll just snowball into bigger issues.

You’re the manager. You’re in charge of making sure the organization is running smoothly. If an employee is faltering, it’s your job to step in and help get things back up to speed. Don’t expect everyone else to pick up the slack — they have a lot of work to do too. As a manager, you’ll gain a lot of respect for getting “down in the trenches” when the team really needs you.

Discipline employees when they need to be disciplined. Have a plan in place and follow it for everyone. No exceptions, otherwise you risk enabling abusers.

Don’t be afraid of confrontation. This is a sign of weakness, and cunning employees will take advantage of it time after time. When the moment comes, stand your ground, explain the problem clearly, and be prepared to offer a solution.

Realize when something is out of an employee’s control (e.g. bereavement leave) versus under an employee’s control (e.g. personal appointments). In case of the latter, insist they try to make time for it outside of their normal work schedule. If that’s not possible, require them to make up missed time before work, after work, or during lunch. This compromise asserts the employee’s value to the organization and will significantly reduce absenteeism.

Nobody deserves preferential treatment, no matter who they are or what their situation is. Business is business, and if someone has committed to a position, they should honor that commitment or step down until they have the time and energy to resume their obligations.

When you hire someone and train them for a position, let them do their job. Correct them when mistakes are made, but if the job is being done correctly and with reasonable efficiency, don’t keep stepping in to micromanage them. This is frustrating for employees, and it’s also a trait of poor management skills.

Treat your employees like an investment: pay them well and they will perform well. Don’t tell them that the organization doesn’t have enough money to provide raises — most employees are smarter than that. Give them what they’re worth and set goals for them to earn more. This will motivate them, reduce turnover, and show compassion. Your employees will remember that and will be more apt to stick around and do great work.

A workplace is like a team: you have a group of people working together to achieve a common goal. Each player in a team has a specific purpose. When one of those players is underperforming or absent, the rest of the team has to make up for it. When this happens on a regular basis, morale suffers and players become disgruntled — some may even choose to quit. As the “team captain”, this is your fault — not theirs. Don’t let other players adversely affect the rest of the team. It’s your job to step in and keep everything in line.

Know when to let someone go. It's always better for the organization and the employee to try to work things out. Alas, the time will come when an employee is no longer a good fit for their position and you need to be OK with letting them go. It's not the end of the world. In many cases the employee will find a new job that suits them even better. If nothing else, being let go is an eye opener that can actually help them become a better employee at their next job.

At the end of the day, you're the manager. How your organization operates is a reflection of you. So here's something to keep in mind. It's a quote from Napoleon that I hope will resonate in your thoughts for the rest of your management career: "An army of lions commanded by a deer will never be an army of lions."

I should have been asking my users this from the start

2015-01-20T00:00:00Z

Feedback is critical to an app's success. How will you know what to fix or improve on if your users don't tell you? It seems obvious, but here is something I should have been asking my users from the start.

Getting the right feedback is critical

When someone signs up for my service, they get a nice welcome message that thanks them for signing up and shows them how to login. Inside that message, there's also a line that reads something like this:

If you have any questions or suggestions, hit reply and let us know!

This lets people know that we're open to suggestions (which should be a given for a SaaS app), but it really doesn't produce a lot of useful feedback. I think people are desensitized by lines like that, but the message feels a lot less friendly without it.

I also send follow up emails after a couple days. I'm not trying to sell them something at this point — I'm trying to see if they're having trouble with the app or if they have any questions or feedback for me. This tends to yield a better response, especially when I ask about the user's business and what they expect from my service.

However, the single most important piece of feedback is something that I didn't start collecting until a few days ago.

A simple oversight

In my app, users can cancel their subscription or delete their account on their own — no need to email in a request. I do this because:

I don't believe in retention via guilt (i.e. begging users to give it another try)
It's more convenient for them
It's less to manage for me

But what I was missing out on is the feedback that comes from when a user decides to cancel or delete his account. This is very, very important for a SaaS company. How in the world was I not collecting this data?

The truth is I was trying, but I was going about it all wrong. For awhile now, whenever somebody canceled or deleted their account, the app would send me an email so I could follow up with them to find out why. I thought this would be more personal, as every message I typed was by hand. I almost never got responses to those emails.

Looking back, that's probably because those users had already disconnected from the service. By the time they received my email, they had already moved on and didn't want to waste anymore of their time on it. It was simply too little, too late.

A better way to ask users

It became obvious that I needed to find a better way to ask users for their feedback before they canceled their accounts. So I recently took some time and added a simple text field to the cancel/delete screens. Not a dropdown menu, not radio buttons — just a simple textbox where they can leave one word or 1,000 words. By reaching out to users who are in the process of canceling, I've found that they're much more likely to voice their reasons.

Since I've made that simple change, I went from almost zero feedback to all but one user telling me why they decided to cancel. (For what it's worth, the person who didn't leave a reason had only signed up a few minutes prior to canceling the account — probably just a window shopper.)

Even though it's only been a few days, I've learned a lot about why users decide to cancel their accounts. It gives me a better understanding of how they work, how they think, and what they expect, and it gives them a chance to have their voices heard.

What I found was a better way to ask my users for feedback. It's so ridiculously simple. I just wish I'd thought to do it years ago.

Why developers hate being interrupted

2015-01-08T00:00:00Z

I stumbled across a post today (that unfortunately no longer exists) and I was almost convinced that I had written it myself. Many of the points in it hit home, so I hope it helps people better understand how developers think and what they go through when interruptions arise.

One point talks about how much headwork programming requires:

A huge amount of what a developer is doing is in their head. As we write code we need to keep a mental model of how parts of the application that have already been written and are yet to be written interact with the part that we are writing at that moment. We need to have a solid picture of exactly how the code is working as a whole and maintain that picture. It’s not easy, it requires a lot of concentration and has to remain in place while we think of creative and efficient ways to solve the problem at hand.

Another explains why developers are actually the most productive when they seem unproductive:

Developers can appear very unproductive at times, sitting staring at the screen with our headphones on and very little in the way of keyboard clackety-tap. This however is when we are doing our thinking, when we are building up, adding to and rearranging the mental model of how our code will work. This is the biggest and hardest part of development.

It's so true. Breaking a developer's concentration can be devastating to their productivity.

Social sharing buttons are ineffective

2014-12-16T00:00:00Z

Back in 2012, I wrote an article called Down with the "Share" Widget. In it, I talked about why plastering social sharing buttons all over your website is completely ineffective. This morning, Smashing Magazine all but confirmed my theory.

In today's Smashing Newsletter, they wrote:

Are social sharing buttons really that effective to be placed in the most visible areas of websites, sometimes even as “sticky" notes on the left or on the right side of the page? Are there any case studies which provide proof that these social icons are actually effective? Or are they indeed ineffective, barely used and really just annoying?

While their stance isn't conclusive, the fact that they even raised the question says quite a bit. Are people are finally becoming desensitized to all the Facebook and Twitter logos everywhere? Maybe now that social media is commonplace, we can all get back to writing better content instead of designing trendy new share widgets.

How to use currentColor in your stylesheet

2014-12-04T00:00:00Z

I've had my head buried so deep in code that I hadn't even noticed this existed. It's a simple way to reference the current text color when writing CSS. Works in modern browsers, including IE9+.

If you use Less or Sass then you probably already use something like @text-color. Alas, CSS doesn't have variables yet, but currentColor will come in handy if you're tired of repeating the same hex codes over and over again. Here's how it works:

div {
  color: #00f;
  border: solid 2px currentColor;
}

That will produce a <div> with blue text and a matching blue border around it. If you need to change it later on, you only need to change it in one place.

Of course, you can use currentColor for other properties too. Box shadows, background colors — pretty much anything. You can even use currentColor with pseudo elements:

div {
  color: #00f;
}

div::after {
  /*
     Styles for CSS triangles or anything else
     you'd use a pseudo element for go here
  */
  border-color: currentColor;
}

The resulting border-color will be taken from the <div>, which in this case is #00f.

I switched from tabs to spaces and haven't looked back

2014-11-25T00:00:00Z

Last week I started using spaces to indent code instead of tabs. It's something I swore I would never do, but I'm glad I finally did.

Why I always preferred tabs

Tabs are sensible. They were made to indent things, and code needs to be indented, so it was a good relationship. Probably the two most well-known arguments for using tabs are:

Tabs reduce file size (although this is negligible and I would never argue based on this point)
Tabs allow each developers to choose their own indentation level without changing the actual file (this was always my biggest reason, and I think most pro-tab people agree)

Of course, there are more arguments (and plenty for spaces too), but here's why I've switched.

Soft tabs make it seamless

Most editors support soft tabs, which means you can still use the tab key to indent/outdent and never even notice the difference. Sublime Text 3 is my editor of choice, and it does a superb job of this. It also has some built in tools for converting between tabs and spaces, reindenting, etc. That made it a lot easier for me to switch and update existing files.

And when I "seamless", it really has been. I've been a stubborn tab guy for like a decade. My workflow hasn't changed, the keystrokes I use are identical, the code looks the same, and the universe hasn't imploded yet. That's a good sign for my first week.

Indentation is always consistent

One thing that always drove me crazy about using tabs was the way HTML looks when you view the source. Most browsers render tabs the equivalent of eight or more spaces long. Why they do this, I'll never know. But I do know that I don't have to worry about that anymore. +1 for spaces.

There are other places where indentation varies. In fact, the biggest pro-tab argument ends up being an argument against tabs when you don't have control over how deep indentations go.

Everyone uses them now

Bootstrap is massively popular, and for a good reason. It cuts out the fat and gives you something tried and tested to develop with. It's a solid framework, and the conventions they use make really good sense.

So when Mark Otto (probably best known as @mdo) released his code guide, it of course suggested we use soft tabs (spaces). Another hard blow to tab lovers.

Here's the thing — I normally wouldn't sway and I'd keep doing my own thing code rogue style, but what's the point? If you've ever been on GitHub, it's clear that most developers are using spaces now. As tab lovers, we're pissing into the wind.

So last week I decided to try out spaces while building Particle. I converted all files from tabs to spaces in less than five minutes and just went with it. And I actually liked it. A lot.

My code fits in now

It's refreshing to know that my code fits in better with other people's code now. I don't have to worry about what other developers and projects are using, because most of them are using spaces anyway. I also don't have to worry about contributing to a project and accidentally sending commits with a mix of tabs and spaces.

Call it peer pressure. Call it giving up on my beloved tabs. I really don't care anymore. At the end of the day, I looked past an old habit and, for whatever reason, I decided to try something new.

I switched from tabs to spaces and haven't looked back.

CSS shapes are here

2014-10-16T00:00:00Z

Here's something exciting from the CSS world: shapes!

Ok, it may not sound all that exciting, but you haven't had a chance to see what can actually be done with CSS shapes yet. (Hint: check out the featured image above.)

Razvan Caliman explains it like this:

For a long time, web designers have been forced to create within the constraints of the rectangle. Most content on the web is still trapped in simple boxes because most creative ventures into non-rectangular layout end in frustration.

It's true. We didn't even get "circles" until border-radius came around, and even then you'd have to expect IE8 and below to fallback to a square. We've been confined to boxes for a long time.

So how are things changing? See for yourself over at HTML5 Rocks. It's the best intro to CSS shapes I've seen so far.

CSS reset with box-sizing fix

2014-10-14T00:00:00Z

For ultra lightweight projects where a framework is overkill, I tend to use Eric Meyers' CSS reset. And since I'm not a glutton for punishment, I also throw in the tried and tested box-sizing fix popularized by Paul Irish. Instead of searching for and combining these snippets every time I need them, here's a paste-ready version for convenience.

/* CSS reset with box-sizing fix */
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
 margin: 0;
 padding: 0;
 border: 0;
 font-size: 100%;
 font: inherit;
 vertical-align: baseline;
}
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section {
 display: block;
}
html {
 box-sizing: border-box;
}
*, *:before, *:after {
 box-sizing: inherit;
}
body {
 line-height: 1;
}
ol, ul {
 list-style: none;
}
blockquote, q {
 quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
 content: '';
 content: none;
}
table {
 border-collapse: collapse;
 border-spacing: 0;
}

No attribution necessary, as this code is considered public domain. Just copy and paste it into your new stylesheet and start designing!

What can you do with a single
?

2014-09-05T00:00:00Z

If I told you to make something using only CSS and a single <div>, would you be able to create something incredible?

That's exactly what Lynn Fisher has been doing with A Single Div. Using only a single HTML element and some CSS, she's created some shockingly complex artwork ranging from Super Mario mushrooms to the iPhone's charging indicator. There's also a Bloody Mary, a breakfast plate, a crayon, a digital camera, and more.

It's great inspiration and a heck of an argument against superfluous markup. Check it out and let me know if you think you can create something similar using only a single <div>.

Stop trying to build the next unicorn

2014-09-02T00:00:00Z

So, you're building the next big thing? You say you're going to make millions and have a fancy office building out in the valley? That's cool. By the same odds we'll both be rich, because I'm holding tonight's winning lotto ticket.

Your idea probably won't be the next big thing

It's true. The odds are against you. Whatever you're building probably won't be the next Facebook or Twitter, but that doesn't mean you can't make a living doing what you love.

It sounds discouraging, but I'm really just trying to bring you down to earth. Stop reading all those articles about multi-million dollar funding rounds and IPOs. They're exciting. They trigger ambition. But they're not realistic. You might as well be reading about last night's lottery winner.

You're probably well aware that most startups fail. It's a vicious world out there with entrepreneurs trying desperately to get their ideas funded. They have an exit strategy even before they have a product. Building something great has taken a backseat to trying to become a billionaire.

Success may not be what you think it is

When someone says "success", what do you think of? Is it the money? The fame? The idea of retiring young? Is it having big houses and little cars? What type of lifestyle would you live if you were "successful" by your own standard?

When we're young, we're taught to aim for the sky, but success doesn't have to be so glamourous. In fact, rich people aren't as happy as you think:

If we can get people just a little bit more informed, so they know that getting the $20 million or $200 million won’t necessarily bring them all that they’d hoped for, then maybe they’d concentrate instead on things that would make the world a better place and could help to make them truly happy.

So what makes you truly happy?

Less is more

What if you could live in a comfortable house, have a nice car, work decent hours, enjoy the work you do, have a healthy budget for your day-to-day needs, and be able to spend more time with your family and friends? The average person would kill to have this life. (If you didn't know that already, you must be a very fortunate person.)

The truth is, your success is based on many things that are important to you, not just your work. When you put too much focus on one thing, everything else ends up on the back burner. Working too much can ruin your relationship and even cause you to die young. I wouldn't consider that to be very successful.

So how do you reach that balance yet still be successful? There's nothing wrong with aiming high — just don't aim too high.

There's no shame in a lifestyle business

Some people don't like the term lifestyle business. If you're not familiar with it, a good definition is:

A business that is set up and run by its founders primarily with the aim of sustaining a particular level of income and no more; or to provide a foundation from which to enjoy a particular lifestyle.

That's exactly what I started in 2008, albeit unknowingly. Of course, at the time, I was hoping my service would take off and be the next big thing — but it wasn't. It didn't make me millions of dollars and it didn't attract a group of check-writing VCs. But it also didn't crush my dreams. Rather, it enlightened me.

You see, I ended up starting a sustainable business that's been paying my bills since 2008. I live the life I mentioned above, and I consider myself reasonably successful. I have a great service that I enjoy running, awesome users that I love helping, and there's nobody I have to report to at work. I take most weekends off and have plenty of time for family. In fact, I'll be celebrating my honeymoon for a week in the Caribbean next month. Life is good running a lifestyle business.

Does that mean I won't reach a bit higher with my next project? Absolutely not. I'd love to start another service that's just as (or more) successful than what I'm doing now, but I'm not going to let it dictate my life. The truth is, I'm happy running a lifestyle business. I'm not trying to build the next unicorn and, unless you like being disappointed, neither should you. You'll find much more success in launching something smaller.

If you're stuck with that "go big or go home" mentality, my advice to you is figure out what you're good at, find a niche you enjoy, and start solving a problem. Grow your idea slowly but steadily, be good to your users, and stop worrying about becoming a millionaire. With your focus on building something you believe in, you'll have a much better chance of success and you just might end up with a business that will be around for years to come. That's way better than most startups do.

And who knows? Maybe your idea will take you to the top. But if it doesn't, at least you'll still be doing something you love.

BrowserStack: stop using virtual machines for browser testing

2014-08-29T00:00:00Z

Sick of booting up an entire virtual machine (VM) just to test something in IE? With BrowserStack, you don't need VMware or VirtualBox. Just enter a URL and instantly test on just about any browser you can think of.

This is legit. It's not just another screenshot service or emulator. You have real-time access to an actual machine running your browser of choice. So how does it work? A BrowserStack engineer explains:

BrowserStack.com works by connecting you with a real machine (let us call it server) running somewhere in one of our geographically distributed datacenters via RFB protocol.

We use certain open source tools, modified to suit our needs, running on server side. Client browser runs a flash based client application which receives the input from the users and send it across the server. Server gets this input, does the required operation and sends the changes back to the client.

In other words, it's a clever way of remoting into a machine running the target browser, but you don't have to worry about VMs, memory, OS licensing, software updates, or even launching a browser.

Sound too good to be true? I've used it and it works really well. My biggest concern is that, even with a broadband connection, the remote screen gets a bit choppy (but this can also happen when you run a VM without enough memory). My other concern is the price. At $39 a month for a solo plan, you need to be doing some serious browser testing to make it worth your while.

Either way, it's worth checking out. They offer a free trial that gives you 30 minutes of live testing and 100 screenshots. I think you'll be impressed by what they've built over at BrowserStack.

I'm taking "startup" back

2014-08-28T00:00:00Z

The word "startup" has taken on a very unfortunate meaning over the years. I used to think of my own business as a startup, but as its definition evolved, I quickly realized I didn't fit that description at all.

The word "startup", by definition, means the act or instance of setting in operation or motion. Or, more appropriately, a fledgling business enterprise. Given that, you could assume that just about any up and coming business is, in fact, a startup. But you'd be wrong.

What it means today

While the definition will vary from entrepreneur to investor, there's one thing that most startups have in common these days: many seem to be in it for the money. You see, we're in the middle of a gold rush, and everybody wants a piece of the pie.

Back in the day, running a startup meant that you shared a certain passion and solved a certain problem. It was a culture, one that you submitted to because you wanted to make the world a better place. When you were a startup founder, the last thing on your mind was an exit strategy. Hell, some didn't even have a monetization strategy. You just wanted to build something awesome and feel good knowing people used your product.

That's not to say that making money isn't important — after all, you have to eventually monetize to stay in business — but sustainability is very different than superabundance. The problem now is that most people are taking that million dollar shot. They care less about what they're building, more about how they're going to get rich, and they're indifferent to the quality of their product.

You can thank acquisitions like the $1 billion Instagram deal or the absurdly high $19 billion WhatsApp purchase. Big companies are buying up products and services like they're going out of style, and each high-dollar acquisition just adds fuel to the fire. The idea of becoming a millionaire is poisoning the startup well.

As a result, "startup" has become synonymous with a business whose primary goal is to make a bunch of money through investments, acquisitions, or the holy IPO grail. They're like the new get-rich-quick schemes.

Why I'm taking it back

While my company doesn't share the same traits as those above, I always considered it to be a startup. I started bootstrapping it back in 2007 and, to this day, I haven't taken investments of any kind. To me, that's one of the most beautiful things about the startup world. You can create something from virtually nothing and, the next thing you know, you're running a profitable business.

What starts as an idea evolves into a product or service, and it's made great by the passion you have for building it. But when you start thinking more about the money than the experience, you end up adding to the landfill of half-hearted products that nobody ever wanted. If you have an exit strategy before you have an idea, you're doing it for the wrong reason.

For me, this issue came to light a few years ago when someone made me feel very ignorant for calling my own business a startup.

You run a startup? Who have you pitched your idea to? How much are you seeking for investment? What's your exit strategy?

None of it applied to me, but the questions were asked with such certainty that it felt like they should have. That's become the expectation for startups these days. After I explained that I wasn't doing any of that, he responded with:

Oh, so you're not a startup. You're a bootstrapper.

Suddenly, my product wasn't interesting because I didn't plan on getting acquired or raising millions of dollars.

In hindsight, I should have corrected him. You see, I've come to realize that it's not my version of "startup" that's been skewed. It's those that think startups have only one purpose — to generate multi-million dollar payouts — who are getting it wrong.

A startup isn't a wealth generator. Yes, one of their functions is to sustain a business financially, but that's not the reason you should be in the game. A startup is an idea. It's a passion. It's a culture. It's a business that aspires to make the world better, no matter how large or small.

From now on, when you hear me talk about startups, don't be confused by the people who are starting up just to cash out. Know that when I use the "s" word, I'm referring to those who are doing what they love for reasons that amount to much more than just dollar signs.

I'm drilling a new well. I'm tossing out the trash. I'm taking "startup" back.

Hide the mouse cursor with CSS

2014-08-28T00:00:00Z

I know you can change the mouse cursor using CSS, but I never realized that you can actually hide it altogether.

.no-cursor {
  cursor: none;
}

Of course, that doesn't mean you should, it just means you can. Practical uses for this are definitely limited, but things like mouse-based games come to mind.

What other use cases can you think of for hiding the mouse cursor? If you think of any, let me know on Twitter.

How to leave a console greeting for your visitors

2014-08-27T00:00:00Z

Since my audience consists primarily of web developers, I decided to try a little experiment the other day. I added a console greeting to the site for anyone who decides to look under the hood. Here's how I did it.

What the heck is a console greeting?

Some time ago, I saw a post about a web design agency that advertised a developer job in an HTML comment on their website. The idea was that a developer might be checking out the source and possibly apply for the position. I'm not sure if it worked, but it was definitely a clever idea.

The other day I was updating a script and thought, "how cool would it be if someone left a fun greeting in the developer console?"

Lately I've been trying to write more about my experience running a bootstrapped SaaS business, which I think can be very valuable to developers. To help promote this new section of the blog, I added the following message that will appear in a visitor's console should they happen to open it while visiting my site:

The greeting invites visitors to check out the Business section of my blog, and I've left my Twitter handle in case they want to get in touch with me. The panther is there as a "wow" effect, which I think will help reception. What's nice is that in Chrome and Safari, the link is actually clickable!

How to do it

The idea is simple. When the page loads, leave a message in the developer console. All it takes is a bit of JavaScript:

console.log(
  '\n' +
  'Hi there, fellow developer! Thanks for visiting.\n' +
  'If you’re an aspiring bootstrapper, startup-er,\n' +
  'or business owner, make sure you check out this         ("\`-’-/").___..--’’"\`-._\n' +
  'section of the blog for tips and inspiration!            \`6_ 6  )   \`-.  (     ).\`-.__.‘)\n' +
  '                                                         (_Y_.)’  ._   )  \`._ \`. \`\`-..-’\n' +
  'http://www.abeautifulsite.net/tags/business            _..\`--’_..-_/  /--’_.’ ,’\n' +
  '                                                      (il),-’‘  (li),’  ((!.-‘\n' +
  'I’d love to hear what you think!\n' +
  '\n' +
  '— Cory\n'
);

It's a bit ugly with all the concatenation and newlines, but you get the idea. Of course, if the visitor doesn't have their console open, they simply won't see anything. The script itself is benign and only serves as a clever way to reach out to someone who happens to be browsing with the dev console open.

What do you think of this idea? Silly, fun, annoying, awesome? What other ways can the console be used to charm or impress your tech-savvy visitors? Have you seen any other websites do this?

Subtle Patterns: hundreds of free backgrounds that tile

2014-08-25T00:00:00Z

I've been using Subtle Patterns for quite some time now. All the patterns are great, and their Photoshop plugin is incredibly useful.

I can't remember when it first launched, but I do remember when there was only one or two pages to browse on the site. Now it has over 380 images you can use for free in your own projects. The collection is curated by Atle Mo, who does a great job in maintaining subtle, consistent backgrounds out of the tons of images that users submit.

All of the patterns tile nicely (which you can test by selecting Preview) and all are available under a Creative Commons license. If you're a designer with a knack for tessellations, you might be one of the lucky 3% whose pattern gets accepted.

I bought the Photoshop plugin the day it came out, which I highly recommend if you use Photoshop for web design. It's so much better than tiling the images yourself or going to Edit > Define Pattern every time you want to try out a new background. It also has a slick logo, which always a good reason to buy something.

Seriously, it's an awesome service, so now's a good time to add Subtle Patterns to your bookmarks if it's not already there.

Find a name for almost any hex color

2014-08-22T00:00:00Z

Have you ever wondered what color that certain shade of blue is? Or maybe you've named your Less/Sass variables something like gray, light gray, lighter gray, etc. Here's a tool that will give you more reasonable names for all those colors.

Name that Color lets you enter a hex value (or choose one from the color picker) and gives you a human-readable name for the closest matching shade. There are over 1,500 color names available, ranging from alabaster to zinnwaldite. Others are more common, such as brick red, chocolate, and slate gray. Even if you don't land on a perfect match, the nearest named-color is only a shade or two away.

The author also provided the JavaScript library behind it all under a Creative Commons license. It's really easy to use:

// Find the nearest match
var match = ntc.name("#6195ED");

// The resulting array
var closest = match[0]; // RGB value of the closest match
var name    = match[1]; // The color name
var exact   = match[2]; // True if it's an exact match

What will you do with this handy tool?

Working with HTML5 data attributes

2014-08-21T00:00:00Z

Before HTML5, working with arbitrary data sucked. To keep things valid, you had to stuff things into rel or class attributes. Some developers even created their own custom attributes. Boy, was it a mess.

But that all changed with the introduction of HTML5 custom data attributes. Now you can store arbitrary data in an easy, standards-compliant way.

How do data attributes work?

A data attribute is exactly that: a custom attribute that stores data. They are always prefixed with data- followed by something descriptive (according to the spec, only lower case letters and hyphens are allowed). An element can have any number of data attributes you want.

Here's an example using a list item to store data for a user:

<li data-id="1234" data-email="calvin@example.com" data-age="21">Calvin</li>

Of course, this data isn't very useful to a visitor because they can't actually see it, but it's wildly useful for building web applications. Imagine a delete button in your app:

<button type="button" data-cmd="delete" data-id="1234">Delete</button>

All the data you need is right there to send to your backend script. No more rel stuffing or parsing IDs and actions out of other attributes. Data URLs make your life easier.

What can you store?

One thing to remember when working with data attributes is that you can't store objects in them. Well, you can if you serialize them, but we'll save that for another post.

For now, just know that you're pretty much limited to storing strings.

Reading/writing data attributes with JavaScript

Using the delete button as an example, let's look at how we can access this data with JavaScript.

// Here's our button
var button = document.getElementById('your-button-id');

// Get the values
var cmd = button.getAttribute('data-cmd');
var id = button.getAttribute('data-id');

// Change the values
button.setAttribute('data-cmd', yourNewCmd);
button.setAttribute('data-id', yourNewId);

Pretty simple, right? Now you can pass cmd and id to your app in an AJAX request or do whatever else you need to do with it.

Reading/writing data attributes with jQuery

Here's the same thing using jQuery's .attr() method:

// Get the values
var cmd = $('#your-button-id').attr('data-cmd');
var id = $('#your-button-id').attr('data-id');

// Change the values
$('#your-button-id')
    .attr('data-cmd', yourNewCmd)
    .attr('data-id', yourNewId);

Don't get this confused with jQuery's .data() method. Although there is some overlap in how data attributes and .data() work, they're two totally different things. If you're not familiar with it, just stick with .attr().

Using the dataset API

HTML5 actually has an API just for working with this type of data. Alas, IE10 and below don't fully support it, but it's still worth mentioning.

Using the button example again, here's how to get and set data attributes using the dataset API:

// Here's our button
var button = document.getElementById('your-button-id');

// Get the values
var cmd = button.dataset.cmd;
var id = button.dataset.id;

// Change the values
button.dataset.cmd = yourNewCmd;
button.dataset.id = yourNewId;

Note how there's no data prefix or dashes here. Similar to the way CSS properties work in JavaScript, you'll need to use camel case notation. The dataset API converts each one so you'll always have data-some-attribute-name in your HTML and dataset.someAttributeName in your JavaScript. Magic!

Things you can do with data attributes

The examples above are very basic, but you can do so much with custom data attributes. Here are a few examples off the top of my head.

Filtering

Say you have a list of things and you want to filter them by keyword. Just put the keywords into a data attribute and write a short script to loop through and show/hide them accordingly.

<input type="text" id="filter">

<ul class="cars">
    <li data-models="mustang, f150, 500, fusion">Ford</li>
    <li data-models="corvette, silverado, impala, cavalier">Chevrolet</li>
    ...
</ul>

Here's a quick and dirty filter using jQuery:

$('#filter').on('keyup', function() {
  var keyword = $(this).val().toLowerCase();
  $('.cars > li').each(function() {
    $(this).toggle(keyword.length < 1 || $(this).attr('data-models').indexOf(keyword) > -1);
  });
});

Styling

It's arguably better to use classes, but you can style things against data attributes too. Here's how to apply a style if the element has a certain data attribute (regardless of its value). First, the HTML:

<span class="label" data-warning>

Now the CSS:

[data-warning] {
  background: red;
}

But what if we wanted to style it based on the data attribute's value? This will work for any data-warning attribute that contains the word error:

[data-warning*=error] {
    color: red;
}

Configuring

Bootstrap uses data attributes as an HTML alternative to configuring plugins via JavaScript. Here's an example of a popover:

<button type="button" class="btn btn-default" data-container="body" data-toggle="popover" data-placement="top" data-content="Vivamus sagittis lacus vel augue laoreet rutrum faucibus.">
  Popover on top
</button>

A better way to store data

Custom data attributes are widely used all over the web. The nice thing is that they work fine in older browsers, and they adhere to web standards moving forward. That means you can start using them today knowing that they won't stop working tomorrow.

I've shown you a few common ways to use custom data attributes. What other uses can you think of? Have you used them before? Let me know by commenting below!

Is it possible to be an introverted entrepreneur?

2014-08-21T00:00:00Z

A tweet by Remy Sharp sparked my thoughts about being an introvert and starting a company. I don't hate human beings, but I do tend to keep to myself. How has this impacted my ability to run a successful business?

Launching a product is hard

If you don't have a good network, launching a product is hard. Without an immediate audience to provide feedback and help promote your idea, you're stuck waiting for users to trickle in. That means it takes longer to know what's good, what sucks, and what's missing. The birth of your product is a critical time, so the last thing you want is to have a lot of downtime and lack of feedback during this period.

When I launched my first SaaS product, that's exactly what happened. I promoted the service through my blog, fed some cash into AdWords, and waited for it to get recognized. I was expecting users to pour in, but that didn't happen. It took some time for things to really pick up, and I attribute that to my lack of social interaction.

Being an introvert, I wasn't tapped into social media the way many startups are. I didn't hang out at trendy bars with my tech friends. Working from home, I wasn't good at meeting people with similar interests. I thought I could let technology do all the marketing for me.

It seems that, when you keep to yourself, you end up underestimating the need to connect with people. In hindsight, I made a lot of mistakes because of that. Perhaps the best lesson I've learned out of all this is that you need people, whether you like it or not.

My product should have failed

By most accounts my product should have failed, but I had one thing that saved it. I'm much better at email than I am in person or on the phone. Because of this, I was able to connect with users who asked questions or signed up and build their trust. I had support emails pushed to my phone and would respond at all times of the day. My commitment to fast and friendly support was my saving grace. It kept things going as I learned how to market and grow a SaaS business.

As it turned out, I wasn't actually an introvert. I was just better at typing than I was at talking.

Once I learned to use that to my advantage, everything changed. If I was good at email, why couldn't I be good on Facebook and Twitter, too? That got me out of my shell so I could engage people better online, which has helped significantly. It also encouraged me to get out there in the real world and do the same thing.

Networking is a way of life

A very successful person once told me that networking is the key to success. "It's not what you know, it's who you know." This is unfortunately true in the world of business. If you think you can be an introvert and still be successful, you're in for a rough ride. Of course, nothing is impossible, but why make it harder for yourself? People aren't all that bad.

If you disagree with that last sentence, perhaps you've been hanging out with the wrong crowd. Find like-minded people that share similar interests. Go out of your comfort zone to reach out and meet people that are more like you. This can be difficult if you're no longer in high school or college, but it's not impossible.

That same successful person also told me that networking is a way of life. It's not something you force yourself to do just once a month at a local meet-up. It happens anywhere and everywhere you go. Instead of avoiding people, smile and act friendly. Offer to help them whenever you can. You never know when or where you'll spark up a conversation with someone who will change your life.

It's probably impossible

Is it impossible to be an introvert and an entrepreneur? Unless you're marketing your product directly to cats, I would say your odds of success are unlikely. I wasn't the most outgoing person and I definitely ran into issues. Fortunately, I was able to realize my aversion to social interaction and work on fixing it.

That was years ago. Since then, I've grown comfortable walking right up to people and introducing myself. I've given presentations to small and mid-sized groups of people. I try to be more active both online and in person. I attend local meet-ups, conferences, and other social gatherings a few times a month.

Although I used to be fine with the idea of being an introvert, I've learned that it's not the best personality to have when you're trying to run a business. It's the equivalent of being a lifeguard that doesn't know how to swim. Sure, you might be able to rescue a few people, but your odds of succeeding will be much lower because you're lacking a mission critical skill.

How to use the PHP ternary operator

2014-08-18T00:00:00Z

When I learned how to use the ternary operator years ago, I fell in love with it. What a cool way to simplify assignments based on a condition. If you're not sure what the ternary operator is or how it works, you're missing out on a really cool piece of programming knowledge.

Let's start out with an example and I'll explain how it works below. I'll use PHP, but the syntax is exactly the same for JavaScript. Let's say we want to assign one of two values to $x based on a certain condition. Using a conditional (if/then/else), it would look like this:

if ($valid) {
  $x = 'yes';
} else {
  $x = 'no';
}

That should be pretty easy to read. If $valid is true set $x to yes, otherwise set it to no. But this example is rather long for such a simple assignment. Let's do it in one line with ternary logic:

$x = $valid ? 'yes' : 'no';

This produces the same result as before, but it's much shorter. Read it out loud like this:

If x is valid set it to yes; otherwise set it to no.

It's not that intimidating once you wrap your head around it. You can even nest them if you feel like being dangerous:

$valid = true;
$lang = 'french';

$x = $valid ? ($lang === 'french' ? 'oui' : 'yes') : ($lang === 'french' ? 'non' : 'no');

echo $x; // outputs 'oui'

Try running this script in your dev environment and playing with the values to better understand how it works.

I will, however, caution you to not go crazy with these. Overusing and nesting ternary logic can make your code really hard to read. A good rule of thumb is, if you have to re-read it multiple times to understand it, you should probably use a conditional or a switch statement instead.

Ternary shorthand

This trick only works in PHP 5.3+ and can sometimes make your logic even shorter. Consider this:

if ($start) {
  $start = $start;
} else {
  $start = 1;
}

Granted, you probably wouldn't do that in your code. You'd probably do something like this instead:

if (!$start) {
  $start = 1;
}

But that's still three lines of code. Let's try with the shorthand ternary operator now:

$start = $start ?: 1;

Much better. Just remember that this shorthand trick won't work in JavaScript!

Five things I've learned about taking risks

2014-08-18T00:00:00Z

I had a cush job at a university with great benefits, decent pay, and normal hours. Five years ago, I took a risk and gave it all up to start a company. Here are the five most important lessons I've learned about risk-taking.

1. There are good risks and bad risks

People that jump into things too quickly tend to achieve unfavorable results. They get excited by the potential and become blind to the consequences. On the other hand, people that wait too long end up missing opportunities due to fear and reluctance. Taking risks can be stressful and dangerous, but it can also change your life.

I've learned that there are good risks and bad risks, but figuring out how to measure them isn't easy. Even if you write down all the pros and cons, the answer might still be unclear. Perhaps that's why so many people talk about risks. It's a complicated subject. Look how many books there are about it.

I'd love to say "just go with your gut", but that hasn't always worked for me. You have to be smart enough to recognize opportunity while being cautious enough to realize what's at stake. It's a lot like gambling, but if you understand the game you're playing you have a much better shot at coming out ahead.

Do your research. Run numbers. Consider your best and worst case scenarios. Listen to your gut instinct, but don't let it trump logic. At the end of the day, there should be a little bit of comfort and a little bit of concern when you decide to take a risk. If either is missing, consider it a red flag.

2. The odds are better than you think

When I quit my job, I already had something going on the side to help cover my expenses while the business ramped up. I planned it out so if things didn't go the way I expected, I'd have something to fall back on. I would never recommend risking everything without having some kind of safety net. That's a crapshoot and, if you've ever been to Vegas, you should know there's a good chance that it won't work out in your favor.

The key to taking risks is to take smart ones, which requires a solid understanding of how things work. Of course, there are always uncertainties — that's why it's called a "risk"—but you can stack the deck in your favor by being knowledgeable, timely, and persistent.

When I launched my first product, it was second to market for the type of service it was. That means it wasn't featured on many tech blogs and it didn't get the kind of coverage or hype that its competitor did. Rather than give up, I decided to roll out some key features quickly and promote the service as much as possible anyway. Marketing wasn't my thing back then (it still isn't), but I studied up and kept at it. My persistence ultimately paid off. In November, my service will see its sixth profitable year of operation!

3. Don't listen to people

I talked to a lot of people before quitting my job. I spoke with my parents, my friends, and even some coworkers about it. Their advice was mixed. Some of them told me to go for it and start my own thing, but most of them told me it was a bad idea. While the former fueled my adrenaline, the latter made me very anxious. I wasn't sure how to handle that type of feedback. I mean, these people were all smart and well-educated and I thought my plan was solid. So who should I listen to?

The answer is none of them. While getting advice from smart and experienced people is perfectly fine, you shouldn't let others decide what risks you take in life. No matter how close you are to someone, they'll never fully understand your situation like you do. They don't know your financial status, how motivated you are, or how successful you'll be. They can only tell you what they would do (or what they wouldn't do) if they were in your shoes.

Now that could be valuable advice if you're talking to a successful entrepreneur, but how many successful entrepreneurs do you personally know? I didn't know any, so I had to go with my gut. I listened to everyone's advice, thought it through, and decided to take the risk. Six years later, I have no regrets.

4. The fun is in the journey, not the destination

Oh, the many nights I've spent developing things, writing blog posts, fixing bugs, repairing databases, responding to support tickets, and playing around with new technologies. I'm fortunate enough to do what I love for a living, and I never take that for granted. Even when things get stressful, I never wish I were doing something else.

To keep things moving forward, I have numerous goals: growth, new products, hiring employees, an office building downtown...but there isn't any finish line, nor should there be. With each goal comes new risks, and with each risk my journey gets more exciting. There's no point at which you'll sit down and say, "there, I've done it. It's all over now." Instead, you'll ask yourself, "what can I do next?"

Even if you nailed that goal of $1M in revenue, you don't stop working and that's it. There's always something else you can turn your attention to. When you succeed, remember what works. When you fail, remember what doesn't. Use that to your advantage and you'll make better decisions in the future. If starting a business is like a road trip, then knowledge is your fuel. Don't worry so much about the destination — just enjoy the ride and keep putting gas in your tank.

5. Know when to call it quits

Sometimes, it just isn't meant to be. Even if you've done something once, doing it again can be a completely different experience. I've played around with many ideas, developed prototypes, bought domain names, and most of them are just memories now. You have to know when to call it quits before it drags you down and burns you out.

There was a project I really wanted to develop a few years ago. I had a logo designed, created a website for it, and even had a partially working prototype until I hit a major road block. At the time, I had to make a decision. I already wasted months of resources working on a project that I didn't even know was viable, and another project was already overdue for a major update. Should I spend the next six months trying to get this thing to work while the other (more successful) project suffered? No way. It was time to call it quits.

When you have a lot of time invested into a project — especially your project — it can be very hard to let go. Maybe it's pride or simply the fear of failure. Maybe a bit of both? In the end, I knew I had to give up on it and move on.

The crazy thing is that once I killed the project, I felt so much better. It was a huge weight off my shoulders. I was able to focus on the more successful service and ultimately launched a new version that caused its user base to triple in one year!

A tip to take home

Risk-taking shouldn't be something that scares you — it should be something that excites you. Look for opportunities, but be cautious and plan when to make your move. If you asked me for just one piece of advice I've learned about taking risks, it would be this:

Waiting too long can be just as bad as not waiting long enough!

Using the classList API

2014-08-15T00:00:00Z

jQuery makes it easy to add, remove, and toggle classes on various elements. It's too bad this stuff wasn't built into JavaScript. But wait — it is now!

What your looking for didn't exist until IE10, but it's been in Firefox, Chrome, Safari, and Opera for some time now. It's called the classList API, and it makes working with classes a breeze, even without a library.

For these examples, assume that el is a reference to an element on your page.

// Adding a class
el.classList.add('your-class-name');

// Removing a class
el.classList.remove('some-class-name');

// Toggling a class on/off
el.classList.toggle('some-class-name');

// Checking for a class
if (el.classList.contains('some-class-name')) {
  // has the class
} else {
  // doesn't have the class
}

This is just as easy as any library out there, and you can use it today if you're not worried about IE9 and below. (Actually, you can still use it with a shim.)

TinyPNG: A better way to compress PNG images

2014-08-15T00:00:00Z

By now, you know that optimizing images and other resources can reduce bandwidth and help your website load faster. Perhaps you've even used a tool like Pngcrush before to make your images smaller. Now, there's an even better solution.

TinyPNG uses "smart lossy compression techniques" to make your images smaller. But wait, isn't PNG a lossless format? Yes, and that's the beauty of TinyPNG:

By selectively decreasing the number of colors in the image, fewer bytes are required to store the data. The effect is nearly invisible but it makes a very large difference in file size!

To accomplish this, TinyPNG uses a quantization algorithm to reduce the number of colors in a way that's virtually undetectable to the naked eye. This is the same technique that Color Thief uses to generate color palettes from photos.

Here's how it works in more detail:

When you upload a PNG (Portable Network Graphics) file, similar colors in your image are combined. This technique is called “quantization”. Because the number of colors is reduced, 24-bit PNG files can be converted to much smaller 8-bit indexed color images. All unnecessary metadata is stripped too. The result: tiny PNG files with 100% support for transparency.

And here's a before/after comparison:

It's visually the same, but 74% smaller. Of course, this percentage will vary for each image. I've been using TinyPNG quite a bit lately and haven't found a single instance where the results were unacceptable.

While using their website is free, there are some paid options for TinyPNG. Instead of dropping your images onto their page, you can get the TinyPNG Photoshop plugin for $40. There's also a developer API with both free and paid plans. (If you want a Bash script that uses their API, here's one by @RanyAlbegWein.)

What other techniques do you use to make images smaller? Share them with me below!

What is my browser? This tool will tell you

2014-08-14T00:00:00Z

Last week I wrote about how to get faster and better help from support. One of my suggestions was to tell them what browser, OS, etc. you're using. Here's a free tool that will make that so much easier.

As soon as you visit About My Browser, it will show you what browser and operating system you're using. Scroll down a bit and you'll see more details including:

Whether or not JavaScript is enabled
Whether or not the browser is accepting cookies
Your screen resolution
Your browser's dimensions
Whether or not Flash is installed
Whether or not Java is installed
Your user agent string
Your language preference

The site also gives you a link to copy and paste for a support person or friend. That makes it the perfect tool to hand off to your grandmother who can't get Gmail to load or that annoying guy in the neighborhood who thinks you're tech support because you work on a computer.

It's nothing that a developer would need, but it's so much easier to say "go here and send me the link" than trying to ask someone who isn't comfortable with computers all those questions.

Smaller volume increments in macOS

2014-08-13T00:00:00Z

Ever wish you turn the volume up or down just a tiny bit more on your Mac? Well, you can.

You already know you can increase and decrease your Mac's volume with the keyboard, but sometimes the intervals are a bit too much. I usually end up adjusting my external speakers just to get that perfect volume. But that's silly. There's a better way to fine-tune your volume without leaving the keyboard.

Simply pressing option + shift + volume up/down will result in quarter intervals, which means you can achieve that perfect volume without having to do secondary adjustments.

What other hidden features of OS X have you come across? Give me something post-worthy and I'll write about it and credit you in the article.

Link to a specific page in a PDF file

2014-08-13T00:00:00Z

Both Chrome and Firefox render PDF files in the browser, making them easier for users to view. Today I wanted to send someone a link to a certain page in a PDF user's manual. Here's how I did it.

In HTML, you can link to a specific part of the page this using anchors. For example:

<!-- page.html -->
<h2 id="anchor-name">Deep Linking Rocks!</h2>

<!-- another-page.html -->
<a href="page.html#anchor-name">Go to it!</a>

When you click the link, your browser will take you to the correct location in page.html, no matter how far down it is.

But how do you do that with a PDF file? Well, we don't have access to any IDs so the best we can do is pick a page and link to that instead. Try this:

<a href="document.pdf#page=10">

Per Adobe, this will link the user to page 10 of document.pdf in Chrome and Firefox. Note that we're using a hash instead of a question mark — it's not actually query string even though it looks a lot like one.

Alas, not all browsers open PDFs, so it's best to tell users which page they should look for in case they're using an unsupportive browser.

As of this writing, Chrome and Firefox both handle this beautifully. Although Safari opens PDFs, it doesn't seem to acknowledge the hash. Of course, this will also work if the user has the Adobe Reader plugin installed.

Lessons from my 20s: a presentation by Ryan Allis

2014-08-12T00:00:00Z

Author and entrepreneur Ryan Allis shares 1,264 slides about life, entrepreneurship, and the world.

We all have goals, but sometimes they seem hard to reach. Really hard. Life happens and things get tough, but don't let it get you down. It's not impossible. It just means you'll have to work a little harder smarter.

If you're like me, you're driven by aspiration, but it can be easy to get lost on the road to success. Sometimes, simply writing down your goals can make them that much more obtainable. It may sound silly, but it's been repeated by too many successful people to ignore, and Ryan Allis is one of them.

The first ever goal I wrote down at age 16 was "build a company to $1M in sales by 21. I missed this goal by 18 days.

In this monster presentation, Ryan shares many experiences and provides great inspiration for anyone with an interest in running a successful business.

It's a long read and lots of scrolling, so make sure you save it for later if you don't have the time to absorb it all today.

How to get the dominant colors of an image with Color Thief

2014-08-12T00:00:00Z

You know how Dribbble shows a color palette for each shot users upload? They always look perfect right? Here's a tool that can give you the same quality results using pure JavaScript.

I played with Color Thief a few months ago but surprisingly never posted about it. For me, something that's easy to use and has consistently great results is pure gold. Here's how it works.

Getting the dominant color of an image

var colorThief = new ColorThief();
colorThief.getColor(sourceImage);

// { r: num, g: num, b: num }

Generating a color palette from an image

var colorThief = new ColorThief();
colorThief.getPalette(sourceImage, 8);

// [[num, num, num], [num, num, num], ...]

Learn more about how Color Thief works and try it out with your own photo. The project was created by Lokesh Dhakar and licensed under the MIT license.

What about a PHP version?

It's amazing that JavaScript can do all these great things, but if you're running PHP on the backend then you're out of luck. In that case, there's a PHP port of Color Thief that you can use for similar results.

PlayCanvas: an easy, open source WebGL game engine

2014-08-11T00:00:00Z

Last week I wrote about faster JavaScript animations using VelocityJS. As if that wasn't impressive enough, today I'm giving you a dose of HTML5 and WebGL greatness.

The project is called PlayCanvas, and it dubs itself an open source game engine that brings fun to the web.

PlayCanvas is the world’s easiest to use WebGL Game Engine. It’s free, it’s open source and it’s backed by amazing developer tools.

It also boasts partnerships with Mozilla, Activision, and ARM. How's that for momentum?

So what's the big deal? Here's yet another great example of where the web and HTML is going. What started as a simple markup language has evolved into a platform for just about anything you can imagine. Take Swooop for example, a game built with PlayCanvas whose graphics and gameplay had me convinced I was playing a Nintendo Wii.

The game isn't elaborate — it was made to demonstrate what you can do with PlayCanvas, but it's stunning nevertheless. You navigate a biplane collecting jewels, stars, and fuel while avoiding clouds and other hazards. The plane circles a three dimensional island full of trees, houses, waterfalls, and rocks. In the distances there's even a windmill and a hot air balloon floating around. Here's an actual screenshot I took while playing:

Want to try it yourself? You can play Swooop right now or explore some of the other user-contributed games. Of course, many of these are unpolished games with simple objectives, so don't expect Xbox quality here. Think of it as a proof-of-concept.

Cool, right? Here's one last gem for you: Lego Gangnam Style.

You may laugh, but pretty soon we'll be seeing entire movies in HTML/WebGL — we might even be able to make our own.

box-sizing: border-box explained

2014-08-08T00:00:00Z

It's been over two years since Paul Irish famously posted the box-sizing trick that would bring us back to the days of early Internet Explorer.

The good ol' days

You might remember how Internet Explorer 6 (quirks mode) and below did that whole box model thing wrong. If not, here's a refresher.

You might even remember what a pain it was to develop with. We're not talking about the days of conditional comments, we're talking about the days of horrible CSS hacks littering stylesheets. You know, like this one:

div {
    width: 100px;
}
div {
    \width: 140px;
    w\idth: 100px;
}

This hack tricked older versions of Internet Explorer in such a way that the div would be the same width in IE and W3C-compliant browsers. (I don't think I need to go into detail about why this was a bad idea.)

The funny thing is, we've more or less come full circle to the very model we were fighting against. You see, the border-box trick actually brings us back to the way old IE worked. And it's glorious. There's even a special day for it.

How it works

The border-box trick effectively changes the way dimensions are measured for every element so it includes borders and padding. Here's the code, for reference:

*,
html {
  box-sizing: border-box;
}
*, *:before, *:after {
  box-sizing: inherit;
}

Think of it as a box model reset that will make you enjoy writing CSS. It's a tried and tested method that works all the way back to IE8, and is used in popular frameworks such as Bootstrap. There are no performance issues — it's like a little piece of magic on your webpage.

But some of my plugins look funny now

I've noticed this a few times before. If you're using a third party plugin whose styles rely on the content-box model, things might look a bit strange. To fix this, you can create an override class or apply the following styles directly to a parent element of the plugin:

.content-box,
.content-box * {
  box-sizing: content-box;
}

This resets the container and everything inside to the default box-sizing model, so third-party plugins will render correctly.

Pick your box model

The two most common values for box-sizing are border-box and content-box, but another has been introduced more recently. As it's name implies, padding-box measures the element's width, height, and padding but not its border. (Support for the new property isn't great yet, so avoid using it for anything serious.)

To better understand each property, here's a diagram for reference.

Oh, and before you ask: no, there's no margin-box.

Give your JPEGs alpha channels

2014-08-07T00:00:00Z

If you need alpha transparency on the web, 24-bit PNGs are usually your best bet. The only problem is that PNGs are lossless and can grow in file size very quickly — much larger than your average JPEG. So what if there was a way for JPEGs to support alpha channels?

I discovered this trick on eleqtriq. The author demonstrates how you can embed a JPEG into an SVG and, with the clever use of a mask, simulate a JPEG with alpha transparency. Since browser support for SVG is pretty good, there's nothing stopping you from using this method right now.

Cool trick, right? Check out Dirk Weber's blog to see exactly how it's done.

How to get faster and better help from support

2014-08-05T00:00:00Z

It's tempting to take out your frustrations on the support person answering your email, but don't send out a message raging about their incompetence. Don't tell them how their product sucks or doesn't work the way you expect it to. Don't TYPE IN ALL CAPS to make sure they understand that you're frustrated. It won't get you faster help — it just makes you look like an asshole.
I'm sure you've had your fair share of horrible customer experiences. It happens, but generally speaking, support teams want to help you resolve whatever issue you're having so you can continue using their product — and they want to do it as quickly as possible.

Of course, support isn't an easy job. I've done my fair share in the past, and I still help out my own customers to this day. Let me just be clear about one thing: nobody contacts support because everything is fine.

Here are some tips you can use to better your odds of getting a resolution on your first interaction with support.

Explain the problem clearly

What's obvious to you may not be obvious to the person reading your support ticket. Tell them exactly what's going on. Re-read what you wrote before sending it in and ask yourself if the following questions would make sense to another person:

What were you trying to do?
How did you try to do it?
What did you expect to happen?
What actually happened?

In most cases, this would be enough information for me to resolve a support ticket. Don't have tunnel vision when you submit your request. The person on the other end may not know that you were in a certain screen or trying to do a certain task. A clear, concise explanation will alleviate questions that are otherwise obvious to you and can result in a faster resolution.

Provide step-by-step instructions

When applicable, provide a bulleted list of the steps you took to produce the error or problem. Unless they have a screen-sharing app, support has no way to see what you're seeing. Tell them what you click, type, or do in a simple list:

Open the "User" tab
Select the user named "Bob"
Click the dropdown under "User Options"
Select "Delete User"
An error occurs stating that the user cannot be deleted

Don't say something like, "I tried to delete Bob but couldn't." There could be many ways to delete a user and the way you're doing it could be broken — or you could be doing it wrong. Supports needs to know how you're doing things to replicate and fix whatever the issue is.

Act like a decent person

It should go without saying, but some people still think that hiding behind their monitor and acting like a pretentious asshole is a great way to get help from support. Nothing personal, but the individual you're trying to get help from doesn't care if you're a CEO, a doctor, or the Pope. You're just a number, and reiterating how important you think you are doesn't do anything to get a faster resolution. Neither does sarcasm, name calling, or profanity.

If you want to have a better support experience, just act like a decent human being. Throw a smiley in there to relieve the tension a bit. I guarantee you'll have a better shot at getting help if you don't act like a jerk. (Tip: I almost always pick the "nice" tickets before the "mean" ones and I pay more attention when those names come up again in the future.)

Be responsive

This is absolutely critical if the support team requires additional information or clarification from you. Make yourself available to answer any questions and aid them in resolving the problem. I've seen tickets sit open for weeks because the person who submitted it went on holiday or "didn't have time" to respond.

Once your support ticket is in progress, you'll almost always see faster response times than when you submit a new ticket. Take advantage of it and respond as quickly as possible. The sooner you get back to them, the sooner they can get back to you.

Talk about your technology

If you're having a problem with software or a web app, tell the support team what operating system and version you're running. When applicable, do the same for your web browser. You'd be surprised how many times simply knowing this would have let me close out tickets on the first interaction. Many web apps include this information in their error reporting or ticketing systems — but it still doesn't hurt to provide it.

If you don't know what operating system or browser you're using, you can find out by going here.

If you're submitting an issue about a web app, keep in mind that browser plugins and add-ons can cause mysterious things to happen. I've seen all sorts of seemingly unrelated things happen as a result of third-party plugins. Try disabling them before submitting a support ticket, or at least let the support person know which ones you have installed in case there's a known issue.

Don't paste in huge amounts of text

This is especially true if you're a developer. Don't paste in a megabyte of code or text to "show" support. It just makes the ticket harder to read. I get a certain tingling in my hand when I open a ticket that does this and it makes me want to skip forward to the next one. Please, for the love of everything sacred, use a service like PasteBin. If you don't want the information to be public, create a secure link using Dropbox or even send it as an email attachment.

Whatever you do, don't start pasting globs of text into your support ticket. Keep the message area to a minimum and link to or attach supplemental information as needed.

Know when to mark things as "urgent"

It's true. Not every issue you submit to support is urgent, so think twice before you check that box or litter the subject line with words like "critical" and "important."

So when exactly is something urgent? It really depends on your circumstance. I have a user who puts "urgent" on pretty much every support ticket he opens up, and I would seldom consider any of his requests to be urgent. They're urgent to him, but to nobody else. This desensitizes the word whenever I see it attached to one of his tickets. Remember the boy who cried wolf?

Think of it like this. If you're looking out your living room window and see a suspicious person walking down the street, you'd call the local police to give them a heads up (not urgent). But if you're looking out that same window and see a suspicious person breaking into your neighbor's house, you'd call 911 (urgent).

Is your issue worth dialing your support team's 911 hotline? If so, it's probably urgent.

Don't email your password

A support person should never ask you for your password. They have ways of accessing your account securely without having you send your login credentials through a ticket system or email. Don't volunteer it to them, either, because every time they hit "reply" or "forward" your password might be getting sent across the Internet in plain-text.

In some cases, like Media Temple, you'll need to generate a support pin to verify ownership of your account before calling. That's fine, because the pin is time-sensitive and can only be generated by you. However, they will never ask for your password in a support ticket or email.

If you haven't already, you should probably train your brain to throw a red flag whenever anyone asks you for your password.

Be patient

Last but not least, give the support team time to respond. One of my services promises a 24-hour response time — and we deliver on that 99.9% of the time. That's not an easy feat for a bootstrapped company serving users all over the world, but it doesn't stop people from submitting multiple requests, often less than a couple hours apart.

You have to have patience. Don't submit a ticket and immediately jump on Facebook, Twitter, and every other platform you can find to submit the same request. It's rude, it's annoying, and it requires more time for support to respond. It can also confuse teams who manage support differently through various channels.

Remember, you're speaking with real people out there. Even though support issues can be difficult and frustrating, keep your cool, be responsive, and be polite. I promise, you'll get much better support that way!

Swapping variables with JavaScript

2014-08-04T00:00:00Z

Swapping the value of two variables normally takes three lines and a temporary variable. What if I told you there was an easier way to do this with JavaScript?

Traditional method

The goal is to swap the values of a and b. The textbook method for doing this looks something like this:

var a = 1; 
var b = 2;
var c;

c = a;
a = b;
b = c;

Of course, we've introduced another variable called c to temporarily store the original value of a during the swap. But can we do it without c?

One-line method

This trick uses an array to perform the swap. Take a second to wrap your head around it:

b = [a, a = b][0];

There are a few things happening here, so if you're still having trouble understanding how or why this works, I'll explain:

We're utilizing an array where the first index is the value of a and the second index is the value of b
a is set to the value of b when the array is created
b is set to the first index of the array, which is a
MAGIC

While this trick definitely saves you a few lines of code and a temp variable, be cautious when using it. It's doesn't help that whole code clarity thing.

Want to learn another cool way to swap variables? If you're a math buff, you'll like the xor trick.

The next version of PHP may very well be 7

2014-08-01T00:00:00Z

We've been hearing about PHP 6 since 2005, but nothing has been brought to fruition yet. In fact, the project was so plagued with problems that in 2010, it was abandoned. It almost felt like PHP would be perpetually stuck at version 5.

Except now there's talk about another major release. It could be PHP 6, or maybe PHP 7. Between developers, there's a hot debate over what the next major PHP release will be called.

The reason why this question even comes up, is that there has been a previous attempt at a new major version, which was started in 2005 and abandoned in 2010 due to difficulties in the Unicode implementation. Apart from language-integrated Unicode support, most features added for that version were integrated either in PHP 5.3 or PHP 5.4.

This previous attempt at a new major version was also developed under the name of PHP 6 and as such there are various resources referring to it, including a number of books. There is concern that there might be confusion between the abandoned previous attempt and the work that is currently happening.

If you're not familiar with what happened with the original PHP 6, you can read more its unfortunate demise here.

Given that the entire Internet was anticipating a PHP version that will never actually ship, it's probably better to stick with PHP 7.

SVG has a logo

2014-08-01T00:00:00Z

HTML5 was the first to get an official logo. Web designers rejoiced, some even hacking together matching logos for CSS. But did you know that SVG also has an official logo, and it's — flowery?

The W3C describes it as:

The flower-like structure of the SVG logo evokes creativity and growth, while the connected nodes indicate integration with other technologies.

The logo was based off a design by Harvey Rayner. According to the W3C:

It was selected by the SVG Working Group from among hundreds of entries in a contest conducted in 2006 by supporters and vendors of the SVG format.

It's a very symbolic representation of an otherwise difficult technology to sum up in an image. I'd say it's a decent fit, but the version without text might confuse people.

What do you think of the SVG logo? Have you seen it used anywhere? I have to be honest, I'm on the Internet quite a bit and only stumbled across this yesterday. I wonder what other cool logos I'm missing out on.

A user interface is like a joke

2014-08-01T00:00:00Z

When I hear a simile like this, it's hard to not share. It's not so much an analogy as it is a good rule of thumb:

A user interface is like a joke. If you have to explain it, it's not that good.

And I've heard some websites tell pretty bad jokes...

Parsing URLs in JavaScript

2013-10-24T00:00:00Z

There's an excellent trick to parsing URLs in JavaScript, which was introduced last year by John Long over on GitHub. This technique works great, but the resulting search property will be a raw query string. This isn't very useful if you need to access certain variables in said query string. Thus, the following function expands on this paradigm, providing an additional property that contains an object based on the original query string.

function parseURL(url) {
	const parser = document.createElement('a');
	const searchObject = {};

	// Let the browser do the work
	parser.href = url;

	// Convert query string to object for convenience
	const queries = parser.search.replace(/^\?/, '').split('&');
	for (let i = 0; i < queries.length; i++) {
		const split = queries[i].split('=');
		searchObject[split[0]] = split[1];
	}

	return {
		protocol: parser.protocol,
		host: parser.host,
		hostname: parser.hostname,
		port: parser.port,
		pathname: parser.pathname,
		search: parser.search,
		searchObject: searchObject,
		hash: parser.hash
	};
}

Let's try it!

const url = parseURL('https://example.com/index.html?q=test');

console.log(url);

And here's the result:

{
	protocol: 'https:',
	host: 'example.com',
	hostname: 'example.com',
	port: '',
	pathname: '/index.html',
	search: '?q=test',
	searchObject: {
    q: 'test'
  },
	hash: ''
}

An icon converter that supports multiple sizes and transparency

2013-09-19T00:00:00Z

If you're looking for an online utility to convert JPEG, PNG, or GIF images to ICO format, here's one that does exactly that. It supports full transparency when converting 24-bit PNGs and even lets you combine multiple resolutions into one icon file — perfect for generating favicons.

The name of the tool is ICO Converter and, while the design of the page isn't very flashy, it works exceptionally well. Give it a try and start making some icons!

Validating URLs and email addresses in PHP

2013-09-18T00:00:00Z

This is a simple method for validating both email addresses and URLs. Using PHP's filter_var() function, it's actually very easy and doesn't require regular expressions. The following wrapper functions force a true boolean response, so you can use them safely in your logic.

Email addresses

function is_email($email) {
  return filter_var($email, FILTER_VALIDATE_EMAIL) !== false;
}

URLs

function is_url($url) {
  return filter_var($url, FILTER_VALIDATE_URL) !== false;
}

If you choose to not use the wrappers, just remember that filter_var() doesn't always return a boolean value. It will return the original string on success, and false on failure..

Semantic version numbers

2013-08-21T00:00:00Z

Gone are the days of arbitrarily assigning version numbers to every new software release. With semantic versioning, the question of how and when to bump versions is made simple.

According to semver.org, the syntax for version numbers should go like this: MAJOR.MINOR.PATCH

When you release a new version, it's easy to determine which numbers to increment:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

The entire spec is actually quite short and simple (for a spec), but the concepts therein will [hopefully] change the way developers version their software in the future. While many projects already follow similar conventions, there are still many that don't. This is especially true in the case of smaller projects, where developers seem to arbitrarily bump version numbers without considering the impact such changes may have on their users.

If you don't have an existing standard for versioning your software, help make the world a better place and consider adopting SemVer in your next project!

There's a reason that Bootstrap 3 has ugly buttons

2013-08-20T00:00:00Z

It's true. Everyone loves Bootstrap's buttons...at least they did until 3.0 came out.

But before you get upset at @mdo and @fat for what many mistake to be a move towards the anti-skeuomorphic design trend, you should realize there's more than meets the eye behind the decision to make buttons flat and "ugly" in Bootstrap 3.

As Mark Otto stated on GitHub while Bootstrap 3 was under development:

Gradients and other embellishments have temporarily been removed while I focus on other things. It has nothing to do with skeuomorphism or anything like that.

There were plenty of follow ups, both for and against the flat, gradient-less buttons. Unfortunately, what a lot of folks don't realize is that Bootstrap is intended to be a starting point for their projects, not an end-all solution for front-end development. In other words, Bootstrap is supposed to be customized, and adding gradients and other arbitrary styles to the core simply makes that harder to do.

Aside from that, when things look too good out-of-the-box, people tend to leave them that way. We saw that so much with Bootstrap 2.x that it spawned blog posts imploring people to stop using Bootstrap (or at least start using it right).

Ultimately, Bootstrap 3 encourages people to customize their implementation, and that's a good thing.

A Less Mixin' for Prettier Buttons

If you long for the good ol' days of beautiful Bootstrap buttons, I may have a solution that you'll like. It's a Less mixin' for buttons, designed specifically for Bootstrap 3. It's easy to use and customize. Use it in conjunction with Bootstrap's Less files and you'll have nice, customized buttons with minimal effort. Here's a sample:

This mixin' works in conjunction with default Bootstrap 3 styles, so you can change pretty much anything with ease. Consider this Gist a public domain offering, and use it however you like.

Whipping file inputs into shape with Bootstrap

2013-08-08T00:00:00Z

There are many, many, many ways to hack a file input so it looks and behaves consistently across all browsers. There's even a pretty slick plugin to help get the job done. Unfortunately, most of these solutions are cumbersome, prone to cross-browser issues, and require JavaScript.

Today, I would like to propose a more fundamental approach for file inputs in Bootstrap 3 and 4.

Modern approach (IE9+)

Let's start by nesting a button inside a <label>, adding the appropriate button classes to style it as we want:

<label class="btn btn-default btn-file">
  Browse <input type="file" style="display: none;">
</label>

Legacy approach (IE8 and below)

If you need support for old IE, you can use this legacy approach. Instead of a <label>, wrap your button in a <span>:

<span class="btn btn-default btn-file">
  Browse <input type="file">
</span>

And then apply the following CSS:

.btn-file {
  position: relative;
  overflow: hidden;
}

.btn-file input[type=file] {
  position: absolute;
  top: 0;
  right: 0;
  min-width: 100%;
  min-height: 100%;
  font-size: 100px;
  text-align: right;
  filter: alpha(opacity=0);
  opacity: 0;
  outline: none;
  background: white;
  cursor: inherit;
  display: block;
}

Customizing the button's appearance

So far so good. Whether you're using the modern approach or the legacy approach, clicking on the "button" will trigger the file input. As a bonus, it will also acquire the :hover and :active pseudo classes so it behaves like a real button too.

You can use these buttons like you normally would…by themselves, in a button group, or even in an input group.

Providing feedback

Now with the hard part out of the way, it's a good practice to provide users with a bit of feedback about their selection. A touch of jQuery magic will keep an eye on your file inputs and fire an event called fileselect when a file is chosen:

$(document).on('change', ':file', function() {
  var input = $(this);
  var numFiles = input.get(0).files ? input.get(0).files.length : 1;
  var label = input.val().replace(/\\/g, '/').replace(/.*\//, '');
  input.trigger('fileselect', [numFiles, label]);
});

Here's an example to demonstrate the event:

$(document).ready(function() {
  $(':file').on('fileselect', function(event, numFiles, label) {
    console.log(numFiles);
    console.log(label);
  });
});

You can use the numFiles or label parameter to show users the name of the file that was selected and, if applicable, how many. Alternatively, you could elect to use the standard change event and handle the label yourself.

This method was tested to work in IE8–IE11 and recent versions of Chrome, Safari, Firefox, and Opera.

See it in action

For a live demo that you can tinker with, view the demo CodePen.

May 20, 2016: added the modern approach and updated the demo.

Tips for the aspiring web developer

2012-12-17T00:00:00Z

So you want to be a web developer...excellent choice! It's a very rewarding position that can be a lot more fun than most other programming jobs. However, before you take the plunge into a career in web development, there are a few things you should probably consider.

A different way of life

I'm not going to start by telling you that you'll be working in at least five different programming languages on a daily basis. Nor am I going to talk about the rapidly changing technologies and standards that you'll need to keep up with. And I'm not even going to mention the multitude of browser quirks that will keep you up into early hours of the morning. All that will come with experience. My goal is to help you understand the type of career — or perhaps the lifestyle — that you're about to undertake.

As a web developer, the type of organization you work for makes a huge difference in how your career will evolve. Chances are, if you're seriously considering web development as a career, you've already spent some of your own time dabbling in HTML, CSS, JavaScript, and one or more server-side scripting languages. You probably discovered how much fun it can be to make something that millions of people could potentially see. If so, you have passion...and that's a good thing.

It's ok to be passionate

Passion drives creativity. It's what keeps you working on something for hours on end simply because you want to. It's what eats away at your nights and weekends. It's what sucks the spirit out of your social life. If you don't have that drive, chances are you're not going to enjoy being a web developer.

In my experience, passionate people tend to have their own way of doing things. The countless hours they spend educating themselves outside the realm of academia gives them insight that people without that dedication will never understand. They change their methods as technology evolves, are generally forward-thinking, and appreciate the "laws" of the web. They take their time to do things right. They care about quality, their user's experience, and the final product. Employers don't always like that, but that doesn't mean it's a bad thing.

"Right" is not always right

Over the past decade, I've had the opportunity to work (as a web developer) for a manufacturing company, an academic institution, numerous web design firms (as a contractor), and for myself. I surround myself as much as possible with individuals who are in the same field as I am. Through many experiences and many discussions, I've come to realize that doing the "right" thing is not always what employers want you to do, particularly when budgets and deadlines are involved.

That's a hard realization to come to when you're passionate about what you do. Maybe you wanted to spend extra time refactoring that code you wrote — it "works", but there's a better way to do it — except the budget doesn't allow for it. Maybe the client needed it out yesterday and you don't have time to finish polishing off the interface you've been working on. Everyone's going to know you're responsible for it, but it's not perfect yet and people may think your work is substandard. These things can be hard to deal with as a developer, so be prepared to sacrifice the quality of your work — or put in extra time off-the-clock — when budgets and timelines don't permit.

Never stop learning

Where you work also plays a role in how your skills as a web developer evolve. Organizations tend to have their own standards and best practices in place that may or may not be as current as the rest of the world. I've seen design firms who are at least 10 years behind in their development methodologies. Their employees aren't encouraged and, in some cases, aren't permitted to use modern technologies and techniques. While this is obviously terrible for the organization, it's also detrimental to the development of its employees.

If you find yourself in this position at any point in your career, you should talk to your management about the policies that are holding your organization back. If they're too close-minded to consider anything outside their comfort zone, it may be time to find a position elsewhere. When there's no opportunity to learn new things, you'll likely get burned out and fall behind new trends in technology. That makes you less attractive to future employers, and overall, it's really not much fun.

Additionally, it's OK to make mistakes provided you learn from them. Always, always, always learn from your mistakes. And don't be afraid to admit when you screw up. You're human. It will happen. Owning up to things will garner you far more respect and wisdom than placing the blame on someone or something else.

Be prepared to give up sleep

There have been many, many, many nights where I've watched the sun set, then rise, and then set again. It doesn't happen every day, but it happens. It's something you have to expect as a developer. Whether it's your own product launch or a really long workday that got prolonged because a server crashed, it's going to happen.

Even when I had an eight-to-five job, there were still nights where important things needed to be done. A lot of times that meant working through the night. In fact, many tech positions share this quality, and developers are definitely no exception.

Find a routine

It's not always possible, but following a routine as often as you can will reduce stress, anxiety, and fatigue. Eat at the right times and try to get enough sleep. If you get caught up in a day from hell that shatters your daily routine (which you will at some point), do what you can to get back on track.

I can't stress this point enough.

Put down your phone when it's bedtime. Wake up when your alarm goes off. If you set aside some time for your significant other or your friends, give yourself that time to recenter. This may seem to contradict some of the points I've made previously, but this type of career isn't just a career — it's a lifestyle. You have to know how to balance things. Realize your limits and know when to keep going, but also know when to stop.

It's not as easy as it sounds. In fact, it's something that I continue to have problems with after many years in the field. However, when I do get back into a routine, I notice a clear difference in my attitude, health, performance, and overall well-being. This is really more of an issue for freelancers and startups, but even the eight-to-fiver can benefit from following a good daily routine.

Exercise your mind and your body

This is another thing that a lot of web developers who I meet seem to neglect. No matter how many hours you spend doing it, a code marathon isn't going to make your body healthy. And if your body isn't healthy, your mind will suffer.

Make it part of your routine. Spend at least 30 minutes a day doing some kind of exercise. Even if you just walk around outside for 30 minutes, it's better than nothing.

Get in the zone

Any web developer knows what it's like, and how frustrating it can be when a distraction takes you out of the zone and blows your developmental buzz. Discover what helps you get in the zone and make it happen. Turn on the right type of music (to me, techno does the trick; anything else and I find myself getting caught up in the lyrics). Turn off your email and only check it at scheduled times. Turn off your cell phone (Android and iOS both have awesome do-not-disturb features). Turn off your instant messager.

Find your zen. Become one with your code. And then watch your productivity rage.

Keep your drive

No matter where you work or who you work for, it's important to keep your drive. A successful developer will put in the extra hours to make an amazing product that impresses his manager and clients. Don't get discouraged by a missed deadline — rectify it and explain how you needed the extra time to finish it properly...then try harder to be punctual next time. Learn new things as much as possible and integrate them into your projects when applicable. This keeps you up to date with technology and makes you more valuable to potential employers. If your organization fears new technology, stand up for what you believe in and encourage them to evolve their policies and practices.

Just remember, the job you have now is just a stepping stone in the river of your career. Don't let anyone pull you into the water and drown out your dreams.

Down with the share widget!

2012-12-14T00:00:00Z

In a world dominated by social media, it's natural to want visitors to share your content with friends and followers. This really isn't a bad thing, but how you go about encouraging them can actually be discouraging.

Six years ago, Twitter wasn't all over the news. Facebook had just opened itself up to any user over the age of 13. You didn't see social media logos on television commercials or on every box of cereal at the supermarket. The guy on the radio wasn't screaming at you to "like" this and that. Those were the good old days.

Today, everyone from the kid next door to the pope has a Twitter account. Major retailers and brands are reaching out to their customers through Facebook, providing them with offers and incentives faster than they ever could before. Companies are tackling customer support by responding within hours or even minutes to angry consumers who voice their opinions to the world. Social media is good stuff, and even our technophobic grandmothers are getting on board.

The point is, everyone knows about social media now. It's built into our desktops, tablets, and phones. There are a multitude of apps that make posting content to your favorite service a breeze. So why are we still plastering "share" widgets all over our sites?

I was recently speaking with a good friend of mine about this. We both have websites, and we both had those tacky, distracting "share" widgets on them at some point. We were social when social wasn't cool.

But now, it seems like every site we come across has some kind of obtrusive social-sharing widget included on every single page. Share this, tweet that, blah, blah, blah...it's just as distracting and tacky as a big ugly banner ad — and people become desensitized by that sort of thing.

It's usually not worth it

That's a pretty bold statement, but let's use the very popular tech blog Mashable as an example. Mashable reaches out to tech nuts — people who use social media on an unhealthy basis. There's no shortage of social media sharing in Mashable's audience, so if anyone can pull this off, it would be them.

Considering Mashable boasts 20 million monthly visitors (as well as six million social media followers), you'd think their "share" widgets would have staggering numbers. On the contrary, the average post only appears to get between 500 and 900 collective "shares" in its first 48 hours of existence (an article's prime exposure period). Here's an example from an article posted a couple days ago:

While it's impossible to determine the actual number of visits to each article on Mashable, it quickly becomes obvious that the percentage of visitors who bother sharing them is extremely low.

If a news giant such as Mashable — who garners over 20 million visitors a month — can only pull in a few thousand shares per article, how many do you think your site will be able to pull in?

Encourage them without encouraging them

So how do you encourage users to share your content without slapping an annoying badge or button on your site? The answer comes down to the most fundamental rule of successful bloggers:

Post awesome stuff that people want to read!

No matter how many "like" or "share" widgets you put on your page, if your content sucks, people aren't going to pass it along to their friends. But if your content is interesting, people will share it whether or not those widgets even exist.

If you think it's all about making it easier for users to share your content...think again. Social integration is built right into most devices these days. You can Tweet directly from the Notification Center in OS X. iOS has both Twitter and Facebook integrated right into the operating system. Windows 8 connects with those and many more services through its People App. And all of that goes without mentioning the many, many apps that are available on every platform to do the very same things.

Six years ago, when the average person had no idea what social media was, "share" widgets became a fad. Now, since social media is more than apparent in all our lives, they serve little more than to beg people to do something they would already have done if they really wanted to. Remember, quality is far more important than quantity when it comes to blogging. Besides, wouldn't you rather have people want to share your content instead of begging them to?

Feature detection for CSS transitions via jQuery $.support

2012-12-09T00:00:00Z

When working with CSS transitions, the need to detect whether or not the browser supports them may arise. It can be of particular use when working with the transitionend event, which won't fire in unsupportive browsers.

After finding a number of questionable solutions, I came across this gist that extends jQuery's $.support nicely.

$.support.transition = (function(){
  var thisBody = document.body || document.documentElement,
    thisStyle = thisBody.style,
    support = thisStyle.transition !== undefined || thisStyle.WebkitTransition !== undefined || thisStyle.MozTransition !== undefined || thisStyle.MsTransition !== undefined || thisStyle.OTransition !== undefined;
  return support;
})();

The value of $.support.transition will be true or false depending on the browser's capabilities.

Access pages without the php extension using .htaccess

2012-02-03T00:00:00Z

There are a number of ways to make "clean URLs" work on your site, but this one is pretty straight forward. It allows you to access /any-page.php by simply going to /any-page. Just place the following into your .htaccess file (and make sure that mod_rewrite is enabled):

RewriteEngine On
RewriteCond %{SCRIPT\_FILENAME} !-d
RewriteRule ^(\[^.\]+)$ $1.php \[NC,L\]

The nice thing about this is that it doesn't affect querystrings. With this solution, both of these URLs are effectively the same:

http://example.com/page.php?id=123

http://example.com/page?id=123

Of course, the caveat is that you don't have "clean querystrings", but it's a reasonable trade-off between "clean" and configuration.

Detecting mobile devices with JavaScript

2011-11-23T00:00:00Z

While I understand and value the concept of feature detection over browser detection, sometimes the need for knowing whether or not we're dealing with a mobile device arises. For in-depth device checking, you can rely on a complex library such as The MobileESP Project. But for simpler applications, the following snippet can be useful.

var isMobile = {
  Android: function() {
    return navigator.userAgent.match(/Android/i);
  },
  BlackBerry: function() {
    return navigator.userAgent.match(/BlackBerry/i);
  },
  iOS: function() {
    return navigator.userAgent.match(/iPhone|iPad|iPod/i);
  },
  Opera: function() {
    return navigator.userAgent.match(/Opera Mini/i);
  },
  Windows: function() {
    return navigator.userAgent.match(/IEMobile/i);
  },
  any: function() {
    return (
      isMobile.Android() ||
      isMobile.BlackBerry() ||
      isMobile.iOS() ||
      isMobile.Opera() ||
      isMobile.Windows()
    );
  }
};

While this doesn't account for all mobile platforms, it will pick up the most popular ones out there.

Examples

To check to see if the user is on any of the supported mobile devices:

if (isMobile.any()) {
  alert('Mobile');
}

To check to see if the user is on a specific mobile device:

if (isMobile.iOS()) {
  alert('iOS');
}

Redirecting to and from the www subdomain with .htaccess

2011-11-17T00:00:00Z

Here are a few snippets that will come in handy if you ever need to redirect www.example.com to example.com or vice versa. There are a number of similar methods out there, but I prefer these as you don't need to modify anything between development and production.

# www.domain.com → domain.com
<IfModule mod_rewrite.c>
  RewriteCond %{HTTPS} !=on
  RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
  RewriteRule ^ http://%1%{REQUEST_URI} [R=301,L]
</IfModule>

# domain.com → www.domain.com
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteCond %{HTTP_HOST} !^www..+$ [NC]
  RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

If you plan on using these, you'll need to make sure you have the mod_rewrite module enabled on your server.

The SimpleImage library for PHP

2011-11-16T00:00:00Z

If you love working with PHP but hate the GD library, you'll love the Simple Image PHP class I'm releasing today. This class takes the headache out of dealing with images and features over 25 useful methods.

The class is incredibly simple to use. The following two lines will load image.jpg, flip it horizontally, rotate it 90 degrees, shrink it to fit within a 320x200 box, apply a sepia effect, convert it to a GIF, and save it to result.gif:

$img = new SimpleImage('image.jpg');
$img->flip('x')->rotate(90)->best_fit(320, 200)->sepia()->save('result.gif');

Here's a list of the supported methods:

flip() - flips an image vertically or horizontally
rotate() - rotates an image at the specified angle
auto_orient() - adjusts the orientation based on the image's EXIF data
resize() - resizes an image to the specified width/height
fit_to_width() - proportionally resizes an image to the specified width
fit_to_height() - proportionally resizes an image to the specified height
best_fit() - proportionally resizes an image to fit within the specified width/height
crop() - crop an image from x1/y1 to x2/y2
square_crop() - trim the image to a square and resize to the specified size
desaturate() - convert the image to grayscale
invert() - invert the image
brightness() - adjust the image's brightness
contrast() - adjust the image's contrast
colorize() - apply the colorize filter
edges() - apply the edges filter
emboss() - apply the emboss filter
mean_remove() - apply the mean removal filter
blur() - apply selective or gaussian blur to the image
sketch() - apply the sketch filter
smooth() - apply the smooth filter
pixelate() - pixelate the image to blocks of the specified size
sepia() - apply a simulated sepia effect
overlay() - overlay one image onto another to create a watermark effect
text() - Add text to the image

Download

This project is actively maintained on GitHub. Please submit all issues and contributions to the project page. Licensed under the MIT license.

Download the latest version from GitHub

January 10, 2017: SimpleImage 3.0 has been released. Please refer to the repo for API changes and the latest features.

How to delete a tag on GitHub

2011-11-16T00:00:00Z

In the world of Git, tags are very useful for keeping track of your project's version history. A lot of folks will argue that you shouldn't delete tags, but there are real-world examples in which tags need to be deleted. That said, it's both a good and a bad thing that GitHub hasn't built the ability to delete tags into it's web app.

It can be frustrating, however, if you ever come across that need. If you're one of those individuals, open up a terminal window and navigate to your local Git repository. Once there, simply run these commands, replacing [tag] with the tag name:

git tag -d [tag];
git push origin :[tag]

And if your tag has the same name as one of your branches, use this instead:

git tag -d [tag]
git push origin :refs/tags/[tag]

Of course, these steps assume that you have Git running on your local machine.

August 8, 2016: GitHub now lets you delete releases from its website, but this will not delete the tag. As of right now, to delete the actual tag, you still need to use the command line.

Office 2007 files downloading as ZIP files in Internet Explorer

2010-03-18T00:00:00Z

Today I learned that Microsoft Office 2007 files (you know, the new ones that end in DOCX, XLSX, and PPTX) don't always download properly in Internet Explorer. In fact, IE tends to see them as ZIP files and forces their extension to change to .zip when you select download. This is because IE is checking for the MIME type instead of blindly going by file extensions. Ironically, since it doesn't recognize the new Office 2007 files for what they are, IE renames their extensions to .zip upon downloading.

If you're wondering why the extensions get changed to .zip, it's because the new Office 2007 formats are nothing more than a series of XML documents zipped up with their own special file extensions. Java .jar files and Mozilla Firefox .xpi files do mostly the same thing, so this isn't a new concept, but it does seem to introduce a bit of a problem for Internet Explorer users.

There seem to be a number of "solutions" out there, but many of them involve telling the end user to change a setting in their browser or something like that — definitely not the best solution. Another option is to simply rename the affected file(s) to the appropriate extension(s) and open them up in Office as usual. Although this works, it's still not a great solution since most users won't know to do that.

The best solution I found was on a forum, where a user suggested setting the MIME types manually on the server. This is obviously a better solution, since end users get the expected behavior and are able to download files with the proper extension. For Apache servers, simply add the following to your config file or create an .htaccess file in the root directory of your website:

AddType application/vnd.ms-word.document.macroEnabled.12 .docm
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.document docx
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx
AddType application/vnd.ms-powerpoint.template.macroEnabled.12 potm
AddType application/vnd.openxmlformats-officedocument.presentationml.template potx
AddType application/vnd.ms-powerpoint.addin.macroEnabled.12 ppam
AddType application/vnd.ms-powerpoint.slideshow.macroEnabled.12 ppsm
AddType application/vnd.openxmlformats-officedocument.presentationml.slideshow ppsx
AddType application/vnd.ms-powerpoint.presentation.macroEnabled.12 pptm
AddType application/vnd.openxmlformats-officedocument.presentationml.presentation pptx
AddType application/vnd.ms-excel.addin.macroEnabled.12 xlam
AddType application/vnd.ms-excel.sheet.binary.macroEnabled.12 xlsb
AddType application/vnd.ms-excel.sheet.macroEnabled.12 xlsm
AddType application/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx
AddType application/vnd.ms-excel.template.macroEnabled.12 xltm
AddType application/vnd.openxmlformats-officedocument.spreadsheetml.template xltx

Note that, if you're updating your main config file, you'll have to restart Apache before the changes will take affect. With .htaccess files you shouldn't need to restart the server.

Now your users will be able to download Office 2007 files from your server without any problems. If you've discovered another method for solving this problem, please share it in the comments!

Smoothly scroll to an element without a jQuery plugin

2010-01-22T00:00:00Z

You know that special effect where you click on a link and your browser smoothly scrolls down to the appropriate section of the page? Pretty slick, right? Here are a couple snippets so you can do the same thing on your own website.

Scroll to a specific element

Here's how to programmatically scroll to any element on the page. If you're using jQuery, you don't need a plugin. It's very simple:

$('html, body').animate({
  scrollTop: $("#target-element").offset().top
}, 1000);

This will scroll the page down to #target-element over a period of one second (1,000 milliseconds = 1 second).

Scroll to the selected anchor

You can take things a bit further and animate scrolling for all anchors on your page. The following snippet will watch for clicks on any link that points to an anchor and smoothly scroll down to it:

$('a[href^="#"]').on('click', function(event) {

  var target = $(this.getAttribute('href'));

  if (target.length) {
    event.preventDefault();
    $('html, body').stop().animate({
      scrollTop: target.offset().top
    }, 1000);
  }
});

See it in action

See the Pen cybdG by Cory LaViska (@claviska) on CodePen.

The difference between web designers and web developers

2009-12-22T00:00:00Z

If you've ever worked in, on, with, or around the Internet, you've undoubtedly heard the terms "Web Designer" and "Web Developer". Oftentimes, the two phrases are used interchangeably by someone who is not familiar with the industry. Perhaps the concept is irrelevant to a client who just wants to get their website up and running. Or to a server administrator who has his concerns in the silicon, steel and software that power your website. And what about the nice lady over in Human Resources who blotches up the job posting during the hiring process? I mean — designer and developer — they're the same thing, right?
Let's face it, if you have the word "Web" in your euphemism, you've probably been hammered with questions from both sides of the playing field. Designers will hear things like "how can we add a database to the website?", while developers struggle to answer questions about layout, color selection, image placement, and font styles.

The truth is, however, that most Web Designers don't know a thing about Base64 encoding, MIME types, SOAP requests, regular expressions, or SQL injection. On the flip side, there aren't a lot of Web Developers that can create visually stunning websites which gloat the type of appeal that Rembrandt himself would appreciate.

Due to the demanding nature of the industry, it's all too common to find individuals who are unqualified, inexperienced, or simply not very good at one or the other trying to make their way through a project that requires both creative and technical skills. This is why many underfunded, poorly planned Web-based projects fail. Most of the blame can usually be attributed to the fact that not a lot of people actually understand what the difference is between a Web Designer and a Web Developer. This includes everything from skillsets to the actual role each position plays in the formation of a Web-based project.

Perhaps the most effective way to differentiate between the two positions is to establish a clear line that separates the roles and responsibilities of each position in the context of a Web-based project. This will, of course, vary from project to project and from person to person, but we can define a reasonable boundary which the average Web Designer and Web Developer will be comfortable with.

What exactly is a web designer?

The best Web Designers are of the creative type. They have a knack for getting inside of their clients' heads and realizing their clients' vision. They take this vision and masterfully convert it into an aesthetically pleasing, artistic design that aims to impress millions of potential viewers. Some designers study typography, user interface design, and usability. Most include tools such as Photoshop, Illustrator, and DreamWeaver in their arsenal and frequent sites such as iStockPhoto, Kuler, and a long list of CSS galleries.

It is common, albeit arguable, that a designer's role should also include slicing images, writing (X)HTML, coding CSS, and drafting or editing copy. For the most part, you can think of a Web Designer as a creative expert.

What exactly is a web developer?

Web Developers are usually more technical in nature. They tend to have excellent problem solving skills and are generally good at math. On a daily basis, a developer will write code in five or more different languages including (X)HTML, CSS, JavaScript, [PHP, ASP, ColdFusion, Ruby, Python, Perl, etc.], and some flavor of SQL. Web Developers can usually be found wielding some kind of text editor or IDE, an FTP client, three or more web browsers, and development plugins such as Firebug. They frequent sites similar to the PHP manual, the Mozilla JavaScript reference, and the jQuery Documentation. A developer also knows what an API is and how to develop with it.

Although Web Developers are sometimes referred to as programmers, their skills usually exceed those of a conventional software developer. Think of a Web Developer as more of a technical expert with programming skills.

What about people that do both?

As suggested earlier, it is actually quite common for Web Designers and Web Developers to be expected to take on tasks that are outside of their personal skillsets. In my experience, I would only consider a very small number of people that I've worked with to be proficient in both design and development. In most cases, you'll find a cocky developer that thinks his designs are the greatest thing that ever hit the Internet when, in reality, they're mediocre at best. It's far less common to find a designer who thinks he can code up an entire Web application.

So, which one should i choose?

Which one you choose depends on what exactly you are trying to do, but in many cases your project will require skills from both. If you're looking to start a new website or to redesign your old one, you'll want to look for someone with design talent. If you're looking for some kind of database, E-Commerce solution, or integration with another application, you'll want to look for someone with strong development skills.

Despite the fact that this writing strives to define the difference between Web Designers and Web Developers, the reality is that you're bound to find designers who know at least a little bit about development and developers who know at least a little bit about design. Although both are very different positions which provide entirely different skillsets, the fact of the matter is that most designers and developers have, or will at some point, become factotums — at least to a certain degree. Some may never bother to differentiate themselves as one or the other.

Perhaps the most important aspect of managing a Web-based project is being able to determine what skills a particular project requires, and who is the right person for the job. In this industry it is very clear that, despite a reasonable separation of roles and responsibilities, an individual's job title is not always a reflection of their personal expertise. It is, alas, more often an indication of their position in terms of demand and naivety.

New shortcut keys in Windows 7

2009-11-19T00:00:00Z

I was happy to learn that Windows 7 has some new shortcut keys that let you control certain aspects of window management right out of the box. They're pretty easy to remember too:

Win + Up - Maximize the current window
Win + Down - Restore a maximized window, otherwise minimize it
Win + Left - Snap the window to the left side of the screen
Win + Right - Snap the window to the right side of the screen
Win + Home - Minimize all except the current window
Win + Space - Temporarily make all windows transparent
Win + P - Change the display setting
Win + T - Move forward through items on the taskbar
Win + Shift + T - Move backwards through items on the taskbar
Win + 1 - 9 - Launch or switch to the respective taskbar item (if already open)

If you have multiple screen setup (i.e. dual monitors), these will be helpful:

Win + Shift + Left - Move window to the monitor on the left
Win + Shift + Right - Move window to the monitor on the right

And, similar to the OS X zoom effect, you can zoom in and out using Win + + and Win + - respectively. For reference, here are some of the other useful Windows key shortcuts that have been around in earlier version of Windows:

Win + D - Show / Hide the desktop
Win + E - Launch Windows Explorer
Win + F - Open up a search window
Win + L - Lock the computer
Win + M - Minimize all windows
Win + R - Show the Run dialog
Win + Pause - Launch the System Properties window

If there are other useful Windows shortcuts that you find useful, post them in the comments.

Icon Finder: an awesome search engine for icons

2009-11-13T00:00:00Z

I came across a really awesome icon resource awhile back, but never got a chance to write anything about it. If you're a web designer or developer who always has use for quality icons — especially ones with GPL or similar licenses — this is the website for you. It's essentially a search engine for icons. Everything about this website rocks, especially their logo.

Not only can you filter by license type and image size, you can also download both the PNG and ICO versions on a black, white, or transparent background. You can edit the tags for any icon and, if after all that you still can't find the icon that's right for you, you can opt to purchase a custom icon design.

The website doesn't have a massive selection of icons to choose from yet, but you should find something relevant to what you're looking for. If not, you can always design it and submit it yourself.

JSNES: a Nintendo emulator built in JavaScript

2009-11-10T00:00:00Z

I remember, not too long ago, arguing with people who said that JavaScript would never be as good as Flash. Granted, at the time many people were afraid of JavaScript and, thus, it wasn't used as widely as it is today. With the introduction of popular libraries such as jQuery, Prototype, MooTools and many, many, many others, JavaScript has been on the forefront of the Web 2.0 movement. In fact, it's rare today to visit a webpage that doesn't use JavaScript for at least something. Sure, Flash is still pretty popular, but trends seem to indicate that people are moving further away from it for design and reserving it for videos, file uploaders, online games, and high level web-based applications.

So why bother comparing JavaScript to Flash? Everyone knows Flash is better, right?

And by better, we can pretty much agree that Flash can do smoother animations, higher level programming, awesome 3D stuff...the list goes on. In fact, you can make an entire website out of pure Flash if you so desire, and it will look exactly the same in every browser. Why use anything else?

Well, Flash has its problems, and that goes without even mentioning the fact that it's a closed-source, proprietary technology. (Hint: JavaScript isn't.)

But still, you can't do much when it comes to JavaScript. I mean, it's slow, clunky, and each browser does things just a little bit differently.

Yes, this is very much true. Until now, and even still to some degree, JavaScript remains an emerging technology for more advanced applications such as animation, user interface, and even games, but it is by no means primitive. Proof of this lays with JSNES, an 8-bit Nintendo Emulator that was built purely in JavaScript.

If you're running Internet Explorer right now, don't bother with the link. You'll need to switch to Chrome if you want to play it at near-normal speed. Even Firefox's JavaScript engine is too slow, but it's playable...just really slow.

JSNES

So there you have it. No, JavaScript isn't anywhere near Flash in speed or capabilities, but it's definitely getting there and it's making plenty of waves in the process.

Table cells and max-widths in Internet Explorer 8

2009-09-30T00:00:00Z

I recently came across a little issue with Internet Explorer 8 and max-width. I had an image inside of a table cell and, for some reason, IE8 completely neglected the corresponding CSS max-width property. The result was the image rendering at full size rather than scaled down to the assigned width, as expected.

After a little searching, I found that you can usually resolve this by assigning this to the affected table:

table-layout: fixed;

I'm not a huge fan of quick-fixes like this, but in the case of a blatent browser bug there isn't much you can do without going too far out of your way. I'm sure it will be fixed in an IE8 update soon.

Browser makers: where’s the new tab + homepage option?

2009-08-07T00:00:00Z

Ever since tabbed browsing hit the mainstream I've been hooked. It's rare to see less than a handful of tabs open in my web browser at any time. Whether I'm developing, checking email, or just surfing around, I can never seem to have enough tabs! But there's one thing about this incredible feature that has really bugged me since Day One — one that seems to have gone completely unnoticed by all of the browser makers to-date.

Why can't I see my homepage when I open a new tab?

It may seem trivial or silly to complain about, but to me the idea of anything but my homepage opening in a new tab is counterintuitive. For example, if you open a brand new browser window what do you expect to see? Your homepage. If you open any browser (before Safari 4, Opera 9.2, and Google Chrome) what do you expect to see? Your homepage.

People generally know what to do when they see their homepage because it's familiar to them. Most of them know how to use the address bar to go to another website. Many of them know how to choose a bookmark to quickly get to their favorite places on the web. For the majority of people, having their homepage open up in a new tab is simply what they subconsciously expect to happen.

The tragedy here is that this isn't currently possible in any browser without the use of a plug-in.

It seems as though browser makers each have their own perspective on what should happen when a new tab is opened. Internet Explorer 8, for example, likes to confuse its users with a mostly empty page to stare at. To spice it up a bit, Microsoft decided to add some infrequently used options that users can click on. How many times have you opened up a new tab because you wanted to "Blog with Windows Live" or "Map [something] with Live Search"? How about "Show copied text"?

These are clearly not options that are useful to users, but considering how well they promote Microsoft's services, I can understand how they got there.

Firefox is my browser of choice for both development and day-to-day browsing, but sadly, it doesn't do much better than IE when it comes to new tabs. In fact, I think it does even worse in comparison with IE8. It's a completely blank page.

If I'm not mistaken, Opera was the first to come out with the "smart page" when they introduced Speed-Dial in 9.2. Speed Dial allows users to specify up to nine websites from their bookmarks that will appear in a grid for easy access.

It wasn't long before other browser makers started trying out their own versions of smart pages. Google Chrome made their smart page more useful by adding a search bar, recent bookmarks, and recently closed tabs. As far as smart pages go, this is probably the best of the bunch for functionality, although the nine websites that are automatically chosen aren't always relevant to your actual use of them.

Finally, Safari 4 introduced a really slick "Top Sites" smart page that works pretty well. And, as usual with Apple products, it looks great. The only problem is that it's a little too flashy where it should be more functional. For example, click on the Search History box. The page is instantly replaced by a huge, side-scrolling list of websites. Sure it looks nice at first, but as I search through possible results, I can only see one at a time and it's very jumpy during transitions. I prefer Firefox's searchable history over this any day.

So where do we go from here? Will the world stop because we can't open new tabs and see our homepages? Of course not. It hasn't yet, and we've been dealing with it for years. But why? To me, this seems like a no-brainer that should have made the top of the list for possible "new tab candidates". At the very least, I'd like to see the browser makers add this in as an option somewhere.

What happens if IE8 "breaks" my website?

2009-06-27T00:00:00Z

Last year all of the hype was about IE8 and Microsoft's decision to default the browsers version targeting to "quirks mode" rather than standards mode. This essentially meant that developers would have to opt-in to IE8's standards mode using a proprietary <meta> tag that tells the browser which mode you want it to render your website in.

Needless to say, this was a very frustrating proposal for developers worldwide. At the same time, Microsoft's obligation to not "break" the web was very understandable. It was a catch 22 for the company, but the issue had to be tended to promptly. After much discussion and some encouragement from the community, Microsoft officially reversed their decision to handle version targeting this way.

Now that IE8 has been officially released, one problem still remains for many legacy sites. What if IE8 "breaks" your website? The short-term solution is actually very simple:

Windows Internet Explorer 8 introduces document compatibility modes that allow Web developers to tell the browser to render their pages in the same way as older versions would, thereby allowing the developer to choose when to update.

In short, add this tag inside the <head> of each of your webpages and call it a day:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Wait! Don't actually call it a day and forget about it! Although I'm sure a lot of folks will do just that, the fact is that you really should treat this as the temporary fix that it is and make an honest effort to get those legacy websites and applications up to date. The reality is, however, that many developers will be confronted with compatibility issues as IE8 gets pushed out to millions of users via Windows Automatic Update. Of course, many won't have the time or resources it takes to redevelop or modify all those old sites so, in a pinch, you can at least get by.

Images display in Firefox and Safari, but not in Internet Explorer

2009-04-24T00:00:00Z

I ran into a little "gotcha" today where an image was displaying properly in Firefox and Safari, but not in Internet Explorer. The weird thing is that it wasn't showing up as a broken link (no missing image icon with the infamous red 'X'). Instead, it wasn't showing up at all:

<img src="image.jpg" width="" height="">

As it turns out, if you have the width and height attributes set to an empty string, IE seems to interpret the width and height as zero, which makes the image not appear. All other browsers, of course, seem to discard the empty attributes.

The solution? Simply remove the empty attributes or plug in the appropriate values.

PHP functions to get and remove the file extension from a string

2009-03-12T00:00:00Z

I use these regular expressions all the time, but it's much more convenient to have them both in convenient PHP functions.

// Returns only the file extension (without the dot)
function file_ext($filename) {
  return preg_match('/\./', $filename) ? preg_replace('/^.*\./', '', $filename) : '';
}

// Returns the file name minus its extension
function file_ext_strip($filename){
  return preg_replace('/.[^.]*$/', '', $filename);
}

You can also use the built-in pathinfo function to achieve the same result:

$filename = '/path/to/file.ext';

echo pathinfo($filename)['extension']; // "ext"
echo pathinfo($filename)['filename']; // "file"

Prevent white noise from appearing in images after fading

2009-01-10T00:00:00Z

The first time I ever saw this alleged bug was in Internet Explorer 7 yesterday. Images were rotating on a page in the form of a slideshow, fading in and out for a nice, smooth transition. One problem, though: in Internet Explorer 7 (and 6, as it turned out), one of the images would appear with a small cluster of white pixels around the black areas.

To make sure the image wasn't corrupt, I saved it again using PhotoShop. No luck. Even after saving the image as a GIF instead of a JPEG, the white noise persisted in IE.

Luckily, some research resulted in finding Alex Judd's post, which provided a relatively simple solution to the problem.

To summarize, the white noise occurs in both IE6 and IE7 on some (but not all) images when they fade in or out. This is especially true when you're using a JavaScript library such as jQuery or script.aculo.us.

Evidently, IE mistakes some of the true-black pixels for transparent pixels, which causes the "white" noise (which may not necessarily be white, depending on the underlying background). One work around, as Alex points out, is to adjust the levels of the image in Photoshop very slightly — just enough to eliminate the true-black pixels.

To do this, open the image up in PhotoShop and perform the following steps:

Select Image, Adjustments, Levels
Move the Output Levels slider a few pixels to the right (or type in a small number, like 5)
Save the image

In most cases, there won't be a noticeable difference in color. Alas, this work around does solve the display problem in IE, but not without tampering with the original image. We'll have to keep our fingers crossed in that IE8 finally addresses this issue.

A Beautiful Site becomes "A Beautiful Site, LLC"

2008-10-18T00:00:00Z

Today has been an exciting day. I received documentation from the State of Florida stating that A Beautiful Site, LLC. is officially a limited liability company. This marks the new beginning of a period of growth for ABS, which has been, until now, a sole proprietorship.

In the next few weeks, Surreal CMS will be officially released to the public. This is the first of a number of services that ABS will offer, with hopes of making many lives easier through creative, effective, and intuitive Web-based applications.

To all of our clients, readers, and friends: Thank you for all of your support over the last year and a half. Without your patronage, insight, and encouragement, A Beautiful Site would not be where it is today. I look forward to working with all of you for many years to come.

Import/restore MySQL files from the command line

2008-07-24T00:00:00Z

I don't use this very often, but when I do I always spend a decent amount of time trying to figure it out online. Here are the steps to import a large SQL file from the command line.

Upload the SQL file to the server that your MySQL database is on
Execute the following command from the terminal (command line):
mysql -u [username] -p [database name] < /path/to/file/data.sql
Enter the database password when prompted

Since anything over about 2MB won't paste gracefully into a textarea, this works really well with large SQL files generated by phpMyAdmin. Remember to truncate data and/or drop tables where necessary before importing, otherwise the restore may not work as intended. (For example, CREATE TABLE will not work if the table already exists and INSERT statements will fail if a primary key already exists.)

Parsing a JSON string results in an 'Invalid Label' error

2008-07-17T00:00:00Z

Whenever I work with AJAX, jQuery is my preferred JavaScript library and PHP is my preferred server-side language. I use JSON whenever I can to pass data between JavaScript and PHP. After all, $.get and $.post both process JSON easily, so it's my data type of choice.

Sometimes, however, I can't rely on $.get and $.post to do the dirty work for me. One example is when I'm using a hidden iframe to upload a file via "AJAX". To do this, the form posts the file to a server-side script. The script loads in the hidden iframe, so users don't see what's happening behind the scene. Once the upload is complete, the script outputs some information about the file to the iframe (filename, location, size, etc.). You can then use JavaScript to capture that information.

For the sake of consistency, my server-side script always outputs a valid JSON string. I rely on this data, which gets scooped out of the iframe, to tell me if the file got uploaded successfully and, if not, what the error was. If so, I need to know the filename, size, and location. What ends up in the iframe usually looks something like this:

{"filename":"file.ext","size":"2516582","location":"/path/to/file/file.ext"}

To parse the JSON string into a JavaScript object, I use eval(). (Some people prefer to use a JSON parser, but since the output of the script is controlled, I've never found it necessary for this application.) Alas, when JavaScript evaluates the string it results in an invalid label error.

The error is the result of eval() interpreting the first item in the string as a label. This gets me everytime, but it's extremely easy to fix. Simply wrap the JSON string in parenthesis within eval():

var response = eval('(' + jsonString + ')');

This is one of those JavaScript ""gotchas", so I hope I can save people (and myself) a lot of time by documenting it.

$.postJSON() for jQuery

2008-05-31T00:00:00Z

$.getJSON() is pretty handy for sending an AJAX request and getting back JSON data as a response. Alas, the jQuery documentation lacks a sister function that should be named $.postJSON(). Why not just use $.getJSON() and be done with it? Well, perhaps you want to send a large amount of data or, in my case, IE7 just doesn't want to work properly with a GET request.

It is true, there is currently no $.postJSON() method, but you can accomplish the same thing by specifying a fourth parameter (type) in the $.post() function:

// Send the request
$.post('script.php', data, function(response) {
  // Do something with the request
}, 'json');

This works for $.get() as well, which means $.getJSON() is basically a call to $.get() with 'json' as the fourth parameter.

Generate random passwords in PHP

2008-05-17T00:00:00Z

Here is a function I wrote to generate a random string in PHP. It is probably most useful for generating passwords. You can specify the length of the resulting string, as well as what characters are allowed. The default length is eight and the default character set is alphanumeric.

function random_string($length = 8, $chars = null) {
  if (empty($chars)) $chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
  while (strlen($s) < $length) {
    $s .= substr($chars, rand(0, strlen($chars) - 1), 1);
  }
  return $s;
}

// Usage
echo random_string(10);

Fetching remote web pages with curl and PHP

2008-04-08T00:00:00Z

This is a very brief example of how to use PHP's curl Library to retrieve the source of a remote webpage.

$c = curl_init();
curl_setopt($c, CURLOPT_URL, "http://example.com/");
curl_setopt($c, CURLOPT_RETURNTRANSFER, 1);
$data = curl_exec($c);
curl_close($c);

CURLOPT_RETURNTRANSFER is a predefined constant that tells curl to return the output to a variable instead of displaying it in the browser. Visit the PHP Manual for a list of all CURL predefined constants and their uses.

The source of the remote file will be stored as a string in $data.

Determine file extensions using JavaScript

2008-03-20T00:00:00Z

A quick JavaScript function to determine a file's extension.

function fileExt(path) {
  return path.substr(path.lastIndexOf('.') + 1);
}

But we haven't even mastered Acid2!

2008-03-06T00:00:00Z

Safari was the first mainstream browser to pass the Acid2 Test now. Opera was a close second. Firefox finally nailed it down with version 3. Even Micrsoft, back in December, announced that IE8 passes the Acid2 Test. Web browsers have certainly come a long way towards standards compliance...or have they?

From the WaSP:

The Acid3 Test is designed to test specifications for Web 2.0, and exposes potential flaws in implementations of the public ECMAScript 262 and W3C Document Object Model 2 standards. Collectively known as DOM Scripting, it is these technologies that enable advanced page interactivity and power many advanced web applications such as web-based email and online office applications.

As a series of 100 mini-tests, Acid3 has already been found to expose flaws in all tested browsers, including Internet Explorer, Firefox, Opera, and Safari. WaSP hopes that Acid3 will prove useful to browser makers during the development of future versions of their products.

Just as no browser properly rendered the Acid2 Test when it was released, no browser currently renders the Acid3 Test properly. Will history repeat itself, or will Opera, Firefox, or maybe even IE8 take the lead and pass the Acid3 test first?

Netscape support ending in February 2008

2008-01-03T00:00:00Z

On December 28th, 2007, the Netscape Blog announced that AOL is ending support for Netscape web browsers effective February 1, 2008. This doesn't come as much of a surprise, considering the significant decline in Netscape's marketshare over the past decade to more competative browsers such as IE, Firefox, Opera, and Apple's Safari. Nevertheless, it is upsetting to see what was once the technical leader among web browsers become a thing of the past.

Although Netscape has been Mozilla-based since version 6, AOL claims that their "transition into an ad-supported web business leaves little room for the size of investment needed to get the Netscape browser to a point many of its fans expect it to be." Netscape users are being encouraged to migrate to Mozilla Firefox. Nostalgic Netscape users can download the Netscape theme and extensions for Firefox from the Mozilla website.

A bit of history

Netscape Navigator became extremely popular in the mid-1990's during the consumer Internet revolution. Their success was seen as a threat by Microsoft who promptly responded with Microsoft Internet Explorer. The two companies began an agile battle for marketshare that would eventually be coined the Browser Wars.

During this time, the rival companies implemented a number of proprietary features in an effort to out perform each other and gain marketshare. Consequently, development was focused more on features than on bug fixes, security, and standardization which led to frustrating and confusing times for consumers and developers alike.

In 1998, as Internet Explorer grew increasingly more popular, Netscape released most of its source code under an open source license which became known as the Mozilla Project. After being purchased by AOL, Netscape released version 6.0 which was based on the Mozilla browser, but its success was minimal at best. Netscape continued to use the Mozilla framework through 2008, at which time it was officially discontinued.

IE8 burns the Acid 2 test

2007-12-21T00:00:00Z

An internal build of IE8 is reported to have passed the Acid 2 test. This is great news, as Microsoft is showing more and more progress towards incorporating web standards into Internet Explorer, even though IE7 has remained dormant since it's release back in October 2006.

The entire post was a breath of fresh air, but I was very impressed by one statement in particular:

With respect to standards and interoperability, our goal in developing Internet Explorer 8 is to support the right set of standards with excellent implementations and do so without breaking the existing web. This second goal refers to the lessons we learned during IE 7. IE7's CSS improvements made IE more compliant with some standards and less compatible with some sites on the web as they were coded. Many sites and developers have done special work to work well with IE6, mostly as a result of the evolution of the web and standards since 2001 and the level of support in the various versions of IE that pre-date many standards. We have a responsibility to respect the work that sites have already done to work with IE. We must deliver improved standards support and backwards compatibility so that IE8 (1) continues to work with the billions of pages on the web today that already work in IE6 and IE7 and (2) makes the development of the next billion pages, in an interoperable way, much easier. We'll blog more, and learn more, about this during the IE8 beta cycle.

A lot of people argue Microsoft's ability to create a browser that is standards compliant, but the preceding paragraph highlights a few important points. Whether they want to or not, Microsoft has an obligation to make their software backwards compatible. This is understandable to a reasonable degree, especially considering the fact that a significant number of websites would suffer considerably if they didn''t.

A Beta version of IE8 is expected to be available in the first half of 2008.

Select all, select none, and invert selection with jQuery

2007-12-09T00:00:00Z

A demonstration of selecting checkboxes using jQuery.We start off with a bunch of checkboxes:

<fieldset id="group_1">
  <input type="checkbox" name="numbers[]" value="0" />
  <input type="checkbox" name="numbers[]" value="1" />
  <input type="checkbox" name="numbers[]" value="2" />
  <input type="checkbox" name="numbers[]" value="3" />
  <input type="checkbox" name="numbers[]" value="4" />
  <input type="checkbox" name="numbers[]" value="5" />
  <input type="checkbox" name="numbers[]" value="6" />
  <input type="checkbox" name="numbers[]" value="7" />
  <input type="checkbox" name="numbers[]" value="8" />
  <input type="checkbox" name="numbers[]" value="9" />
</fieldset>

Now, we add some links:

<a rel="group_1" href="#select_all">Select All</a>
<a rel="group_1" href="#select_none">Select None</a>
<a rel="group_1" href="#invert_selection">Invert Selection</a>

The rel attribute is equal to the ID of the containing element of the checkbox group. In this example the containing element is a fieldset, but it could be a DIV, P, UL, etc.

Now, we add behaviors using jQuery:

<script type="text/javascript">
  $(document).ready(function() {
    // Select all
    $("a[href='#select_all']").click(function() {
      $("#" + $(this).attr('rel') + " input[type='checkbox']").attr('checked', true);
      return false;
    });

    // Select none
    $("a[href='#select_none']").click(function() {
      $("#" + $(this).attr('rel') + " input[type='checkbox']").attr('checked', false);
      return false;
    });

    // Invert selection
    $("a[href='#invert_selection']").click(function() {
      $("#" + $(this).attr('rel') + " input[type='checkbox']").each(function() {
        $(this).attr('checked', !$(this).attr('checked'));
      });
      return false;
    });
  });
</script>

To add the same functionality to another group of checkboxes, create more links and adjust the rel attribute accordingly:

<a rel="group_2" href="#select_all">Select All</a>
<a rel="group_2" href="#select_none">Select None</a>
<a rel="group_2" href="#invert_selection">Invert Selection</a>

<a rel="group_3" href="#select_all">Select All</a>
<a rel="group_3" href="#select_none">Select None</a>
<a rel="group_3" href="#invert_selection">Invert Selection</a>

External popup links using jQuery

2007-11-15T00:00:00Z

With the deprecation of the target attribute in XHTML Strict, opening links in new windows has become a bit trivial, if not annoying, to standardize. I always look for a consistent, unobtrusive approach that degrades gracefully; and since I use jQuery quite frequently, this is how I usually handle them.

The solution is a small piece of jQuery code in your $(document).ready() section:

$(document).ready(function() {
  $(document).on('click', 'A[rel="external"]', function(event) {
    event.preventDefault();
    window.open($(this).attr('href'));
  });
});

Now, add rel="external" to all of the links that you want to open in a new window:

<a href="http://domain.com/" rel="external">Domain.com</a>

From here on out, users that have JavaScript enabled will receive external pages in new windows, while those without JavaScript will still be directed to the appropriate location.

I use rel="external" because it's generally a good practice to limit popup links to external websites only. You could very well use rel="popup" instead, but I prefer the former for semantics.

Convert arrays to CSV with PHP

2007-10-03T00:00:00Z

The following snippet will convert a simple PHP array into CSV (comma-separated values) format.

function csv($array) {
  $csv = "";
  for ($i = 0; $i < count($array); $i++) {
    $csv .= '"' . str_replace('"', '""', $array[$i]) . '"';
    if ($i < count($array) - 1) $csv .= ",";
  }
  return $csv;
}

Output

$a = array("item 1", "item 2", "item 3");

echo csv($a); // "item 1","item 2","item 3"

Getting proportionally-resized dimensions of an image

2007-09-17T00:00:00Z

This is extremely useful when you need to scale down an image within a certain pair of dimensions.

get_resized_dimensions()

Parameters

$width - The width of the image to be resized
$height - The height of the image to be resized
$max_width - The maximum allowed width of the resized image
$max_height - The maximum allowed height of the resized image

Return values

The function outputs an array containing two elements: width and height

$new_dimensions = get_resized_dimensions(640, 480, 200, 200)
echo $new_dimensions['width'] . ', ' . $new_dimensions['height'];

The output for the above code will be: 200, 150

Code

function get_resized_dimensions($width, $height, $max_width, $max_height) {
  // Check for bad values
  if ($width <= 0 || $height <= 0) return false;

  // Determine aspect ratio
  $aspect_ratio = $height / $width;

  // First check width
  if ($width > $max_width) {
    $new_width = $max_width;
    $new_height = $new_width * $aspect_ratio;
  } else {
    $new_width = $width;
    $new_height = $height;
  }

  // Now check height
  if ($new_height > $max_height) {
    $new_height = $max_height;
    $new_width = $new_height / $aspect_ratio;
  }

  return array('width' => $new_width, 'height' => $new_height);
}

JavaScript functions for basename and dirname

2007-09-16T00:00:00Z

Here are two JavaScript functions that mimic their PHP cousins.

basename()

function basename(path) {
  return path.replace(/.*\//, '');
}

dirname()

function dirname(path) {
  return path.match(/.*\//);
}

Unlike their PHP cousins, these functions do not support paths separated with backslashes.

Avoiding timestamp errors when calculating dates in php

2007-08-29T00:00:00Z

When calculating dates in PHP, it is easy to add millisecond values such as 60 * 60 * 24 to increment the time by one day. This can become problematic for two main reasons.

Issues with leap years

A year has approximately 365.25 days, hence a leap year occurs once every four years. If you start on Tuesday April 1, 2003 at 12:00:00 the timestamp would be 1049198400. Adding the length of one day (60 * 60 * 24, or 86,400ms) would give us 1049198400 + 86,400 = 1049284800, which is the same as Wed April 02, 2003 12:00:00. No problem here.

Using this same methodology, we realize that adding one year (60 * 60 * 24 * 365, or 31,536,000ms) to Wednesday April 02, 2003 12:00:00 would result in 1049284800 + 31,536,000 = 1080820800. This is problematic because 1080820800 is the timestamp for Thursday 01 April 2004 12:00:00 (we were expecting the next day, 02 April).

Even if we used 60 * 60 * 24 * 365.25 (or 31,557,600ms) to compensate for the quarter-day phenomenon, we would end up with 1049284800 + 31,557,600 = 1080842400, which is Thursday 01 Apr 2004 18:00:00. This "miscalculation" is due to the leap day that occurred on 29 February 2004.

Issues with daylight saving time

Another issue involves Daylight Saving Time (DST). The calculation is affected similarly and a one hour shift forward or backward will occur if your version of PHP is configured to account for DST. This can turn out to be more drastic than a one hour shift, however. Consider this:

$current_date = "2007-11-04";
$timestamp = strtotime($current_date);
$timestamp += 60 * 60 * 24; // one day increment
$new_date = date("Y-m-d", $timestamp);

On 04 November 2007, the time "falls back" one hour, thus $new_date contains the same value as $current_date when $current_date is equal to 2007-11-04. Here are some sample outputs surrounding 04 November 2007:

$current_date	$new_date
2007-11-01	2007-11-02
2007-11-02	2007-11-03
2007-11-03	2007-11-04
2007-11-04	2007-11-04
2007-11-05	2007-11-06
2007-11-06	2007-11-07

Consequently, if we were outputting hours, minutes and seconds as well, every day after the DST change would be exactly one hour off (until, of course, the next DST change canceled it out).

A Better Way to Calculate Dates

Fortunately, we can overcome both of these hurdles simply by using the strtotime() function. Instead of adding one day to a timestamp like this:

$date += 60 * 60 * 24;

We can successfully add one day like this:

$date = strtotime(date("Y-m-d", strtotime($date)) . " +1 day");

Similarly, we can use the same method for weeks, months, years, etc.:

$date = strtotime(date("Y-m-d", strtotime($date)) . " +1 week");
$date = strtotime(date("Y-m-d", strtotime($date)) . " +2 week");
$date = strtotime(date("Y-m-d", strtotime($date)) . " +1 month");
$date = strtotime(date("Y-m-d", strtotime($date)) . " +30 days");

Using the strtotime() function to add relative blocks of time results in accurate calculations where the previously shown method sometimes fails.

What if you wanted to add one month to $date? Using the previous method, you would be forced to estimate the duration of a month or create a really smart algorithm to figure out the exact duration of the given month. Since each month varies in length, the first option is unreliable. The second option has already been incorporated into the strtotime() function, so why not use that instead?

More examples

You can use the following examples to experiment with. For further documentation, see the PHP Manual's section on strtotime().

$date = "2005-05-10";
echo date("Y-m-d", strtotime(date("Y-m-d", strtotime($date)) . " +30 days")); // output is 2005-06-09
echo date("Y-m-d", strtotime(date("Y-m-d", strtotime($date)) . " +4 weeks")); // output is 2005-06-07
echo date("Y-m-d", strtotime(date("Y-m-d", strtotime($date)) . " +1 month")); // output is 2005-06-10

DaFont: an excellent free font resource

2007-07-31T00:00:00Z

I came across an excellent website for free fonts online. No annoying pop-ups, minimal banner ads, and the best feature of all — custom previews for all their fonts.

Check 'em out at dafont.com.

Forcing file downloads in PHP

2007-07-08T00:00:00Z

I've seen a number of methods to force file downloads using the PHP header() function which, essentially, sends a raw HTTP header to the browser. Depending on your browser, some files won't be downloaded automatically. Instead, they will be handled by the browser itself or a corresponding plug-in. This is often an issue with PDF files, TXT files, CSV files, LOG files, multimedia files (MP3, WAV, MOV, MPEG, AVI, etc.), and, for many users, Microsoft Office files. As a developer, being able to force the download of any type of file is extremely useful.

To force, or not to force?

The argument of whether or not it is considered "good practice" to force users to download files rather than letting their browser handle them as exepected does not really have a place in this article. In some cases it is appropriate while in others it is probably not.

It has been a convenience the many times I have used it to push CSV files out to end users who wouldn't know enough to copy and paste the data from the browser window into a file and then save it.

It is also handy for when you generate PDF files and want to push them to the user as a download rather than have it open up inside the browser window. Not only does this make the PDF easier for the user to download, it also provides consistency for the way downloads are handled regardless of what browser plug-ins the user has installed.

Again, in some cases it is appropriate to force a download, in others it is not.

The force download script

After rigorous browser testing and code tweaking, here is the script I ended up with. All of the unnecessary stuff has been stripped out and it has been simplified as much as possible.

$file = "filename.ext";

// Quick check to verify that the file exists
if (!file_exists($file)) die("File not found");

// Force the download
header("Content-Disposition: attachment; filename="" . basename($file) . """);
header("Content-Length: " . filesize($file));
header("Content-Type: application/octet-stream;");
readfile($file);

Using the script

Although you can implement this script practically anywhere you want, it is easiest to copy the code into a file named something like force_download.php and pass an identifier via query string, POST form data, or session variable. Users who are directed to the script will be prompted to download the appropriate file regardless of their browser and plug-in settings.

The PHP readfile() function reads files verbatim, including PHP files. This opens up a major security hole if you are passing the actual filename using GET or POST form data (or anything else that the user can spoof). A curious user could easily gain access to sensitive database connection information or other system data by entering something like ?file=../includes/db_connection.php. You should always use some kind of identifier to prevent unauthorized access to sensitive information.

Compatibility

This script has been tested to work in IE6/7, Firefox 2, Opera 9, and Safari 3.

Browser issues

Safari & filenames

Surprisingly, all of the force-download scripts I researched online failed to work properly in Safari. The download occurred, but the resulting file was named after the script (i.e. force_download.php). If I renamed the downloaded file to its correct name, it would open just fine. This, however, was a terrible inconvenience. A bit of testing revealed the culprit. Most of the scripts had a line similar to this:

header("Content-Disposition: attachment");

Others went a step further and had something like this:

header("Content-Disposition: attachment; filename=" . basename($file));

But the correct way to specify the filename requires that you put double quotes around the filename attribute:

header("Content-Disposition: attachment; filename="" . basename($file) . """);

By simply adding quotes around the filename, Safari correctly names the resulting download.

Caching problems

Many of the scripts I found included header calls to tell the browser not to use a cached version of the file. Caching wasn't an issue with any of the browsers I tested, but if it becomes problematic, add the following lines to the script (above the call to readfile()).

header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

The above lines are from the PHP Manual and are expected to work in most browsers.

Internet explorer & https

Certain versions of Internet Explorer will generate the following error message when downloads are forced using this technique:

Internet Explorer cannot download file from server. Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.

To get around this, whenever you are forcing a download over HTTPS append the following two lines of code to the force download script (above the call to readfile()).

// IE fix (for HTTPS only) header('Cache-Control: private');
header('Pragma: private');

You can find more information about this bug on the MSDN Help & Support website.

Web standards are just "minor details"

2007-07-02T00:00:00Z

A friend of mine recently graduated and spread his wings by venturing into the corporate world. He obtained a position as a junior project manager for a web consulting firm in Atlanta. Their work is very professional and their designs are great, but it was immediately evident that they had no understanding of web standards whatsoever. I asked my friend about his company's stance on the matter.

I asked about that. The sites we build are for industrial use, non-computer people, so we make em work and don't fuss about the minor details — web standards anyway. We focus on functionality.

[Jeffrey Zeldman](Jeffrey Zeldman) would pop a blood vessel if he had heard that. After all, isn't that what web standards is all about? Seems like someone is missing the point here. Mark my word, web companies that worry more about the appearance of their work than the framework that supports it will soon find themselves struggling to keep up with the rest of the world.

That said, I'd like to recommend a very good book called Designing With Web Standards. Whether you want to give a hard-headed employer some insight about the future of the web or you just want to learn a little bit about it yourself, this book will provide you with a complete understanding of what the web was meant to be, and how we're going to get it there.

An equal opportunity disease afflicts nearly every site now on the web, from the humblest personal home pages to the multi-million dollar sites of corporate giants. Cunning and insidious, the disease goes largely unrecognized because it is based on industry norms. Although their owners and managers might not know it yet, 99.9% of all websites are obsolete.

Well said, Mr. Zeldman. Well said.

Creating stylesheets for handheld devices

2007-05-30T00:00:00Z

It's not uncommon so see someone surfing the net with their cell phone or PDA these days or, at least, trying to. Unfortunately, portable technologies still have a long way to go before they conquer the web with their tiny screens. The good news is that, with a little help from stylesheets, your website can look presentable even in the palm of somebody's hand!

Handheld stylesheets

Similar to the way that print stylesheets make your webpages ready for paper, handheld stylesheets make your webpages ready for portable devices. This is often necessary due to the fact that most websites aren't designed for small screens. Fortunately, with a little extra effort, this obstacle is easy to overcome.

Linking the handheld stylesheet

We start off by linking to what will become our handheld stylesheet:

<link href="your_handheld_style.css" rel="stylesheet" type="text/css" media="handheld" />

Notice how the media attribute is set to handheld instead of screen.
Now it's time to create your_handheld_style.css.

Creating the handheld stylesheet

You could use the normal screen stylesheet as a starting point to make your handheld stylesheet. Depending on the complexity of the CSS, it may be better to start from scratch or just copy and paste one section at a time, modifying the styles little by little and testing as you go. You could even choose to make a completely different look and feel for the handheld version of your website. The key thing to remember here is that you're creating a design that is meant to display on small screens, often no larger than 240x320 pixels.

Which ever route you take, the fact that you will eventually need to preview the "portable" version of your website is inescapable...but what if you don't have a handheld device?

Testing the handheld stylesheet without a handheld device

Using the Opera web browser

There are a lot of features I really love about Opera, one of them being the Small screen feature. By clicking on View → Small screen or by pressing Shift + F11, you can preview any website in a simulated "handheld" mode. This is usually how I test my handheld stylesheets when I don't have a portable device laying around:

During testing in Small screen mode, it may be helpful to add the following code to your stylesheet. This will simulate the screen width of many common portable devices. Just remember to remove it before you upload!

html {
  width: 240px;
  border: solid 1px #000000;
}

Another thing I would recommend using in your handheld stylesheet is this:

* { max-width: 100%; }

This will prevent elements such as images and textareas from exceeding the width of the device's screen.

Using Opera Mini

Another method to test your handheld stylesheet is with Opera Mini. The program itself requires a mobile phone, but no worries! There's also an online simulator you can try out on any website. Here is what A Beautiful Site looks like on it:

A note about handheld stylesheets

An important thing to remember while you're coding up a handheld stylesheet is the fact that most handhelds will not display your site exactly the way you intend them to. It sounds kind of ironic that you just spent the time writing up a completely different stylesheet just to find out that it's not going to work on the media you intended it to work on. Well, all is not lost. Let me explain...

Due to hardware and software limitations, most handheld devices are designed to display certain elements of webpages in ways that work for both the device and the user. For example, it wouldn't be of much use if a PDA with a screen resolution of 240x320 pixels displayed a full-size image that was 800x600 pixels. In most cases, the device will automatically scale the image down so the entire image can be viewed. Similar adjustments are made to text, links, form elements, floated elements, etc.

So what good is a handheld stylesheet if they aren't really supported? Well, they provide a foundation for the design which you intend the portable version of your website to have. Not only that, support for handheld stylesheets is growing rapidly as technology advances. For the little time and effort they actually require to produce, I'd say they're worth the effort.

What if I don't have a handheld stylesheet?

A good question indeed. Most portable browsers will either make a good attempt at using your normal stylesheet or ditch the styles altogether. The benefit of using handheld stylesheets is that you are, to some extent, guaranteed your website will reflect at least a little bit of the design which you intended.

The future of handheld stylesheets

Some portable browsers, such as Opera Mini and Apple's anticipated iPhone version of Safari, do a fairly good job of rendering websites based on their default screen styles. Aside from the low resolutions that portable devices commonly suffer, it makes me wonder if handheld stylesheets will even be necessary in years to come. Since the path is still unclear, however, it can't really hurt to have them.

Creating a printable website using print stylesheets

2007-05-28T00:00:00Z

I frequently see little printer icons all over the web that clearly mean I can print out a clean version of the webpage that I'm looking at. These little icons are indeed a beautiful sight from the user's perspective. No more having to modify printer settings or copy and paste certain content areas into a word processing program just to get it on paper. In fact, I used to be quite the fan of printable versions on the web until I realized what a pain it can be to develop them.

One method I've seen involves creating a separate version of each page that doesn't have the header, footer, and navigational elements. By doing this, one could nearly double the size of their website without even trying, and who knows how many people are actually going to print all those pages. It seems like a wasted effort, if you ask me.

A somewhat better method that a lot of database-driven websites use is to create a separate version of the content dynamically. This involves using a special page to generate a printable version of the content, again without the header, footer, and navigational elements. This is a lot better because it doesn't involve duplicating content on extra, unnecessary webpages. It still requires, however, extra effort to develop that special page to render the printable content; and who's to say that all the data is coming from just one table in the database? Another potential development nightmare.

To add insult to injury, both of the aforementioned methods result in the user dealing with an annoying pop-up window or being redirected to the printable version of the page. Oftentimes I thought to myself, "why can't I just hit CTRL+P and print this?" That would be the ultimate user experience. After all, if nothing else is consistent in web browsers it's the ability to click on File | Print to print a webpage. "This has to be possible", I thought. There must be a way to prevent content from printing like this:

Enter print stylesheets

With the web standards revolution going at full force, more and more people are understanding the need for semantic markup and stylesheets. The benefits are many compared to what little old-fashioned development techniques have to offer. In fact, there are millions of articles on the web that outline the very benefits I'm referring to.

This article will cover one aspect of standard CSS that is becoming more and more popular in everyday development practice: print stylesheets.

A new way of printing

When I began developing A Beautiful Site's Notebook, one of the things I really wanted people to be able to do was print the articles. After all, what good is an article if you can't print it out and take it with you? Another thing I wanted was for the printouts to look clean and professional, which is what I ultimately achieved. If you don't believe me, print this page and see for yourself. I think the before & after results are rather convincing:

Notice how the version without print styles has the website title, navigation menu, and sidebar content cluttering up the first half of the page? In the styled version, these elements are removed and the page almost looks as if it were printed from a word processing program. The font styles and sizes still match that of the original design, with one exception: I decided to style the main text as Times New Roman, since serif fonts are easier to read on printed media. Most books and magazines use this style of font, so it should give readers a more comfortable feeling when reading the article on paper.

Note that, compared to the previous examples, the non-styled version of A Beautiful Site's webpages are still clean and easy to read. One of the benefits of using semantic markup means that, print styles or not, your pages will be more legible when they come out of the printer.

Minimal effort

Linking the print stylesheet

It really doesn't take much time and effort to apply this technology to your website. In fact, all you need to do is create an additional stylesheet and link each page to it. I typically add this line directly below the normal stylesheet link:

<link href="your_print_style.css" rel="stylesheet" type="text/css" media="print" />

Notice that the media attribute is set to print instead of screen.

That was easy, now we need to create your_print_style.css.

Creating the print stylesheet

You could simply start from scratch and attempt to recreate the entire look and feel of your site in a printable version. Considering the amount of time it would probably take to do this, it seems rather silly to start from the ground up. My technique for creating print stylesheets is much faster and easier.

First, I copy the normal stylesheet to the new stylesheet. That's right, select all → copy → paste.

Second, I decide which elements I don't want to appear on the printed version. For this example, let's pretend we have the following elements: header, nav-menu, sidebar, content, and footer. The only essential element for the printed version will be content, which contains the information that the user is actually trying to print.

Next, I disable all of the unnecessary elements from appearing using standard CSS:

#header,
#nav-menu,
#sidebar,
#footer {
  display: none;
}

Note: To avoid confusion, it's a good idea to delete or comment-out the old CSS that affects these elements.

The final step is to remove any styles that apply to the content element that may affect the way it appears in the printed version. This may include paddings, margins, borders, or anything else that hinders the appearance. If you're using a sans-serif font, you may also wish to style the main text as a serif font, as I did above.

The final design

You can preview your design without having to print it out using the Print Preview feature in your browser. As with normal stylesheets, feel free to make any adjustments to your print stylesheet to optimize the appearance of the design. Now that you have beautiful, no-hassle, printed versions of your webpages, your users will thank you.

CSS drop caps

2007-05-23T00:00:00Z

Traditionally found in printed media, drop caps are created by emphasizing the size, color, weight, or style of the first letter in the first sentence of a paragraph. We can easily reproduce this effect on webpages by using the :first-letter pseudo element.

Writing the styles

Let's start by creating a class called drop-cap and adding a bit of style to it:

.drop-cap:first-letter {
  float: left;
  font-size: 4em;
  line-height: 1;
  margin: .125em .25em;
}

As you can see, the size of the first letter will be significantly larger then the rest of the text. A typical drop cap will line up with the top of the first line of text and the left margin of the paragraph. Horizonal alignment occurs naturally, but we need to account for vertical alignment. By default, it appears slightly higher than we want it to, so the margin-top attribute offsets it enough to get it in line. Depending on font size and unit, this number will vary.

You'll also notice that the first-letter is floated. This allows the letter to sink into the text instead of remaining inline.

Applying the class

Now that we've created the CSS drop-cap class, it's easy to apply it to any paragraph element:

<p class="drop-cap">
  Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
  tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
  veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
  commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
  velit esse cillum dolore eu fugiat nulla pariatur.
</p>

Which produces something like the image above.

Find and replace hyperlinks and email addresses in PHP

2007-05-15T00:00:00Z

These two PHP functions use regular expressions to add the appropriate HTML anchor tags around hyperlinks and email addresses in $string.

PHP code

function parseHyperlinks($string) {
  // Add  tags around all hyperlinks in $string
  return ereg_replace("[[:alpha:]]+://[^<>[:space:]]+[[:alnum:]/]", "\0", $string);
}

function parseEmails($string) {
  // Add  tags around all email addresses in $string
  return ereg_replace("[_A-Za-z0-9-]+(.[_A-Za-z0-9-]+)*@[A-Za-z0-9-]+(.[A-Za-z0-9-]+)*(.[A-Za-z]{2,3})", "\0", $string);
}

Output

Using parseHyperlinks(), http://domain.com/index.htm becomes:

<a href="http://domain.com/index.htm">http://domain.com/index.htm</a>

And using parseEmails(), email@domain.com becomes:

<a href="mailto:email@domain.com">email@domain.com></a>

What are favicons?

2007-05-11T00:00:00Z

A favicon (pronounced "fave-icon") is a small, iconic image that represents your website. Favicons are most often found in the address bar of your web browser, but they can also be used in lists of bookmarks in web browsers and feed aggregators.

Well-designed favicons are styled to match the logo or theme of your website, that way users have a quick and easy way to recognize your website at a glance.

Here is our favicon, displayed in the Firefox address bar:

What type of image is a favicon?

Although most modern browsers will recognize PNG, GIF, and JPG formats for favicons, Internet Explorer currently does not. It is recommended to use the Microsoft ICO format, which works in all browsers.

What size should my favicon be?

Another good reason to use the ICO format is because it can contain multiple favicons of different sizes in one ICO file. It is best to have, at minimum, a 16x16 pixel version. I usually include 32x32 and 48x48 versions as well. That way, if users drag the bookmark to their desktop they will see a nicely scaled version of the icon instead of the 16x16 version stretched out. To learn how to create a favicon with multiple sizes, see How to create a favicon below.

Below: 16x16, 32x32, and 48x48 versions of A Beautiful Site's favicon. Each image is embedded in one favicon.ico file.

The most common sizes for favicons are:

16x16
32x32
48x48
64x64
128x128

How to create a favicon

Although there are many ways to create favicons, the easiest is to use an online tool. We happen to have a favicon generator that's entirely free. It's called Favikon. To create your favicon using Favikon, simply upload an image, crop it, and then download the resulting icon.

How to link to your favicon

Now that you've created a nice little favicon, you need to tell web browsers and other applications where to find it. Adding this line to the <head> section of your HTML will ensure that your favicon will be found:

<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />

The location of the favicon isn't really important, as long as the href attribute is accurate. Most favicons, however, are placed in the root directory (the directory that contains the homepage). Keep in mind that it is not necessary to have multiple instances of the same favicon on one website.

If you add a favicon without linking to it within your HTML, you may notice that some browsers will still find and display it. This only occurs if the favicon is in the root directory. It isn't good to rely on this method, so if you want to make sure that applications will see your favicon, <link> to it!

Using JavaScript to prevent comment spam

2007-05-05T00:00:00Z

Comment spam (also known as 'link spam', 'blog spam', and 'wikispam') occurs when people or spam bots post comments on someones blog, guestbook, or wiki for the sole purpose of boosting traffic and promoting better search engine rankings for their site. Like email spam, it can be particularly annoying and troublesome to deal with.

Common Solutions

Many companies and organizations have put forth efforts to prevent comment spam. The well-known search engine Google, who owns the popular blog site Blogger, announced back in 2005 that it would no longer index anchor tags with the rel="nofollow" attribute in them. Web developers were encouraged to make their software automatically add this attribute to all user-contributed hyperlinks. Although this method will discourage a lot of spammers from wasting their time, it doesn't actually prevent them from posting spam comments.

Other efforts to combat comment spam focus on the fact that most spammers use automated scripts to submit their messages. These scripts work very much like traditional spam bots but, rather than harvesting email addresses, they target comment forms. Once spammers have a list of comment forms and know the fields that each one asks for, they can use programs like curl to forge comment submissions. This is an effective way to spam many blogs in a short period of time, so it's used quite commonly.

A reasonably good method of preventing this type of spam is called CAPTCHA. CAPTCHA typically displays an image of a word or phrase with obscured lettering that OCR scanners can't read. This means that, to successfully submit a comment, the user has to provide the correct response to the CAPTCHA test. Since a human is typically required to pass the test, spam bots can't post bogus comments to sites that use this technology. Unfortunately, this method requires users to take additional steps in order to post comments.

Of course, you could require that all comments be approved before they are posted, but that requires a lot of extra time and effort, especially for busy sites.

A Better Method?

I've decided to share a method that I've been using on my personal site for a few years now. I used to get lots of guestbook and comment spam on a daily basis when my forms were left wide open. Since I've applied this technique, I haven't recieved any comment spam at all. That's right, not one. Of course, once I post this there will be nothing stopping spammers from tweaking their bots to work around this solution. At least, for now, it works extremely well.

How it works

It's really quite simple. You start with a basic comment form:

<form id="comment-form" action="add-comment.php" method="post">
  [other input fields here]
  <input type="submit" value="Post Comment" />
</form>

Now, to prevent comment spammers, we make a few basic adjustments:

<form id="comment-form" action="NO-BLOG-SPAM.PHP" method="post">
  [other input fields here]
  <input type="button" value="Post Comment" onclick="submitCommentForm();" />
</form>

Notice I changed the form action to NO-BLOG-SPAM.PHP. This could be anything, really, as long as it's not a valid page. Next, I changed the submit button to a regular button and added a JavaScript onclick event. I'll show you the submitCommentForm() function in a minute. First, I want to explain my reasoning for doing all this.

It makes sense to me to have a bogus action so that, when a spam bot indexes the form information, it is indexing a submission page that doesn't exist. If the spammer was trying to use curl to submit the comment, they would receive a 'Page Does Not Exist' error.

It also makes sense to me to change the submit button to a regular button. If the spam bot is trying to submit the form from the within the page, it won't know which field triggers the submission. In fact, it would have to be smart enough to follow the JavaScript events for every form element that has one (which, in our case, is only one).

Now, here's the submitCommentForm() function. Note that I am including this function from a separate file, which means the spam bot would not only have to be able to follow the JavaScript, but also support including scripts from other parts of the page.

function submitCommentForm() {
  // Change the form action to the real submission page
  document.getElementById('comment-form').action = "add-comment.php";

  // Submit the form
  document.getElementById('comment-form').submit();
}

As you can see, the when the user clicks on the button labeled 'Post Comment', the submitCommentForm() function is triggered. This changes the form action to the real submission page, allowing the user's submission to post. Of course, this still won't prevent a real human from submitting comment spam, but humans aren't usually into wasting countless hours of their time typing in comment spam. As I stated before, this method has prevented automated comment spam on my personal site for well over two years.

Pros

A lot less comment spam — possibly none
Users aren't required to take any extra steps in order to post a comment

Cons

Requires JavaScript, otherwise users won't be able to post comments

Password protection using .htaccess and .htpasswd

2007-04-29T00:00:00Z

The simplest way I know to password protect files and directories using Apache's .htaccess and .htpasswd files.

.htpasswd

Create a text file with the following text:

username:password

The usernames and passwords are stored in this file, one per line, separated by a colon. To allow multiple users:

firstUser:password
secondUser:password
thirdUser:password
...

Now, for each password, you have to encrypt it using the htpasswd program (included with Apache). If you don't have this program, you should be able to find a tool on the web that can do it. If you have Apache installed on your local system, I strongly recommend using it (You can also generate the entire file with this program, saving you the hassle of creating it in a text editor. Visit Apache's website to learn how).

Windows users

Open a command prompt (Start | Run | command.com)
type htpasswd -nb username password, replacing username and password with the appropriate values

If you get an error message, you'll have to navigate to the directory containing htpasswd.exe (usually Apache[version]bin). If you're not sure where it is, do a search on your system to find it. Once you're in the right directory, try the command again.

Linux users

Open a terminal
type htpasswd -nb username password, replacing username and password with the appropriate values

The program will output something like: username:password. Copy this into your .htpasswd file and save it as .htpasswd (windows users will have to save it as htpasswd.txt and rename it to .htpasswd after uploading).

.htaccess

Now you're ready to write your .htaccess file. This will let Apache know that you want it to use your .htpasswd file for authentication. You can protect one or more directories and/or files this way. To create your .htaccess file, create a new text file:

Protecting an entire directory

AuthUserFile /[path]/.htpasswd
AuthType Basic
AuthName "Login to access this folder"
require valid-user

Protecting a single file

AuthUserFile /[path]/.htpasswd
AuthType Basic
AuthName "Login to access this file"
Allow From All
require valid-user

AuthUserFile is the server location of the .htpasswd file you have just created. You will need to adjust the path according to your directory structure so that it points to the correct location. THIS IS VERY IMPORTANT!

Save it as .htaccess (windows users will have to save it as htaccess.txt and rename it to .htaccess after uploading).

Uploading

Upload both of the files to the appropriate directories on your webserver. Open a browser and navigate to the respective URL. You should get a login dialog that prompts you for a username and password.

Troubleshooting

If the authentication doesn't work, I would suggest:

Checking the path you set after AuthUserFilein .htaccess
Verifying that AllowOverride Noneis not present in the section of your Apache config file (usually called httpd.conf) that corresponds to the correct host. In some cases, you may have to specify AllowOverride All before it will work (even though this is default setting).
If you used a web-based password encryptor instead of the htpasswd program, try another one. I found that many would return encrypted strings that Apache could not authenticate for some reason.

Good luck!

GIF, JPEG or PNG? Using images on the web

2007-04-29T00:00:00Z

This article aims to describe the difference between the three most popular types of images used on the Web, and how to use them effectively in your websites.

JPEG

JPEG files are compressed images that maintain a balance of size versus quality. For example: More compression = less image quality = smaller file size. In contrast, less compression = more image quality = larger file size. Since JPEG files do not maintain 100% of the original image's pixel data, it is not considered a lossless image format.

Usage

Due to this sensitive balance, JPEGs are best suited for photographs where slightly depreciated quality is not very noticeable. JPEG is not typically a good format for logos, icons, and other simple images.

GIF

The GIF format was developed by CompuServe specifically for use online. GIF, sometimes pronounced "GIFF", is a lossless, 8-bit image format. Lossless means that 100% of the original pixel data is maintained. The term 8-bit refers to color depth — an 8-bit image can only have up to 256 colors.

Usage

Because of these limitations, GIFs should not be used for photographic images. Instead, use them for things like:

Logos
Icons
Layout images (such as corners, borders, etc.)
Any other small, simple image with only a few colors

Transparency

GIF supports basic transparency, which means that certain pixels in the image can be "invisible", so you can see whatever lies behind them. This is especially useful for making icons that are intended to sit on top of a varying background.

Compression

The GIF format uses the LZW compression algorithm, which is patented by Unisys. For a time, this meant that the authors of image-editing programs were forced to pay Unisys for the rights to include GIF support in their programs. The patent, however, expired on June 20, 2003 in the United States.

Interlacing

GIF also supports interlacing, which makes the image appear to load faster in web browsers. This could be helpful for people browsing your site on a slow dial-up connection.

Animated GIFs

An animated GIF is a single file that contains multiple variations (frames) of an image. These frames are drawn over and over again to create the illusion of animation. When used appropriately, animated GIFs can be catchy and impressive. Unfortunately, many people tend to overuse them on the web, creating a very annoying experience for their users.

PNG

PNG files, pronounced "PING", were developed as a freeware alternative to GIF files which, at the time, used a patented compression algorithm. The PNG format is also lossless but, unlike GIF, PNG can support 8-bit and 24-bit images.

8-bit PNGs

An 8-bit PNG can have up to 256-colors with basic transparency. This format is very similar to that of GIFs, except for the compression method.

Usage

8-bit PNGs should be used the same way as GIFs:

Logos
Icons
Layout images (such as corners, borders, etc.)
Any other small, simple image with only a few colors

24-bit PNGs

24-bit PNGs can have up to 16 million colors and can support alpha-transparency. This means that a partially transparent image with anti-aliasing can blend smoothly into the background.

PNG support

PNG support is becoming more widespread as browser developers become more conscious of Web Standards. Fortunately, PNGs are currently supported by all popular web browsers including, IE*, Firefox, Safari, Opera, and Konqueror.

*Unfortunately, IE6 messes up alpha-transparency in 24-bit PNGs and displays a grayish-blue background color instead. IE6 has also been known to render some 8-bit PNG colors slightly off-hue (a gamma correction error). Although the alpha-transparency issue has been resolved in IE7 beta 2, Microsoft hasn't addressed gamma correction yet.

Business cards

2007-04-29T00:00:00Z

VistaPrint delivered 1,000 “A Beautiful Site” business cards the other day, and I couldn't resist playing with them.

I decided to go conservative with the design, relying a bit on curiosity to draw attention to the business. Nevertheless, I am pleased with the way they turned out.

An Event Apart, Boston

2007-04-29T00:00:00Z

The plane took off from Orlando as I sat half asleep in my seat. With my laptop at my feet, I wondered what kind of intriguing things I would learn at the web conference I had signed up for. I anticipated this day for months now and it was finally here. I was on my way to An Event Apart, Boston. Wow!

I have always been an avid reader of A List Apart. They never fail to produce really great articles in regards to every aspect of web design. When I first saw an advertisement for An Event Apart online, I was stoked. I gathered all the information possible and practically begged my employer to fund the trip. A few weeks later, it was said and done. On March 26th and 27th I was in Boston listening to some of the web's greatest voices. It was awesome. No, that's an understatement. It was incredible!

The hotel

The conference was held at the Marriott Copley Place, where I stayed on the 33rd floor. The rooms were very nice, the food services were excellent, and the location was perfect — walking distance to anything you could possibly need and a Shaw's 24-hour supermarket across the street. Nice.

Day 1

On the first day I got to put some familiar names with faces. Specifically Jeffrey Zeldman (zeldman.com), Eric Meyer (meyerweb.com), and Dan Cederholm (simplebits.com). Other speakers who spoke that day were Jason Santa Maria (jasonsantamaria.com) on design, Steve Krug (sensible.com) on usability, and Andrew Kirkpatrick (Adobe) on accessibility.

Lunch was sponsored by Adobe and the opening night party was sponsored by Media Temple at Restaurant 33. I hear everyone had a killer time, but due to a stomach bug I wasn't able to attend the party. ~ sigh ~

I did get a chance to speak with Dan Cederholm, however. He signed my copy of Bulletproof Web Design and we talked briefly about running a web design business. Dan's a great guy. His willingness to talk with you and his attitude towards those who are interested in the web really impressed me. I hope I have an opportunity to meet with him again in the future.

Day 2

On the second day I got to meet Molly E. Holzshlag (molly.com), who has authored over 30-something books about the the web and currently works for Microsoft. Specifically, on the IE7 team. Her speech was entitled, "Building Better Browsers". After she spoke, I had a chance to meet with her one-on-one for a while. We talked about some of the issues that Microsoft had to face to get IE7 up to speed with the web standards movement. In a nutshell, I'm happy to say that my opinion of Microsoft's recent efforts to improve IE7 has changed for the better. She also assured me that gamma corrections in PNGs is "on the way". That put a smile on my face.

Other speakers on Day 2 included Cameron Moll (cameronmoll.com) on design, Ethan Marcotte (sidesh0w.com) on web standards, Eric Meyer on CSS and IE7, and Jeffrey Zeldman on selling design.

We wrapped up the second day with critiques. A lot of people submitted websites to be critiqued by the speakers, but only a handful were chosen to be reviewed. I didn't submit a site for this...I don't know why.

Afterthoughts

An Avent Apart was an experience I won't soon forget. It was worth every penny (even if I had paid for it out of my own pocket). Next time, I think it would be good to see a bit more on design and possibly some hands-on activities. I really liked having the opportunity to meet some of the speakers in person. It was also nice to find out that my understanding of good web practice was on par with the rest of the world.

A special thanks goes out to all the speakers from An Event Apart, Boston.

A Beautiful Site launched

2007-04-29T00:00:00Z

I'd like to introduce my new web design studio. After considering a list of potential names and designs, I finally came up with a name that I thought fitting for the kind of web design business that I want to run.

After a few pencil and paper sketches, a few hours in Photoshop, and a couple of late nights staring into two LCD monitors, A Beautiful Site was born.
A Beautiful Site is built on a foundation of web standards, user-oriented design, and excellent development practices. These values follow through from the first keystroke to the final pixel. Pride is something that comes at no extra cost to our customers, and that's guaranteed.

So please feel free to look around. Read some articles, send us a message, or tell a friend about us. I can't wait to hear from you!

Update: It's been awhile since this website first launched and things have changed quite a bit. Here's a glimpse of the original design from 2007.