Chris Coyier Founder, writer, designer, spam-deleter, email personality
Novelty site with a message (and reference articles) by Rob Lafratta.
David Gilbertson:
Removing the focus outline is like removing the wheelchair ramp from a school because it doesn't fit in with the aesthetic.
So David shows how you can remove it unless you detect that the user is tabbing, then show it. Essentially you add "user-is-tabbing" class to the body when you detect the tabbing, and use that class to remove the focus styles if it's not there (plus handle the edge cases).
Nicky Case's games are a damn treasure in this world. Most importantly, they are fun and compelling to play. They also make gameplay the vehicle for education on tricky, intricate, and important issues. Issues that would be much harder to learn about by just reading. They are also a masterclass in design: clear calls to action, clear onboarding, meaningful interactions and animations, and good copy.
At first the title made me think of Git conflicts, but that's not what this is about. It's about namespacing selectors for components. Ultimately, they decided to use a Webpack loader (not open source, it doesn't appear) to prefix every single class with a hashed string representing the version. I guess that must happen in both the HTML and CSS so they match. Lots of folks landing on style-scoping in one way or another to solve their problems.
It makes me think about another smaller-in-scope issue. Say you have an alternate version of a header that you're going to send to 5% of your users. It has different HTML and CSS. Easy enough to send different HTML to users from the server. But CSS tends to be bundled, and it seems slightly impractical to make an entirely different CSS bundle for a handful of lines of CSS. One solution: add an additional attribute to the new header and ship the new CSS with artificially-boosted specificity to avoid all the old CSS. Then when you go live, remove the new attribute from both.
.header[new] {
}
A great intro by Dan Callahan on why IntersectionObserver is so damn useful:
What do infinite scrolling, lazy loading, and online advertisements all have in common?
They need to know about—and react to—the visibility of elements on a page!
Unfortunately, knowing whether or not an element is visible has traditionally been difficult on the Web. Most solutions listen for scroll and resize events, then use DOM APIs like
getBoundingClientRect()to manually calculate where elements are relative to the viewport. This usually works, but it's inefficient and doesn't take into account other ways in which an element's visibility can change, such as a large image finally loading higher up on the page, which pushes everything else downward.
The API is deliciously simple.
At its heart, Wufoo is a form builder. If you need any type of form, you can build it super quickly by selecting and customizing the fields you need in Wufoo's fantastically easy to use form builder. I can hardly imagine a more useful web app for web designers and developers.
But what is a form, at its essence? Just a means to collect data. The important part is what you do with that data. You can do all the obvious stuff. You can have entries emailed to you. You can build reports from the data. You can explore the data inside Wufoo, or use the API to access the data outside of Wufoo.
Those things are just the tip of the iceberg of what you can do with data you collect with your Wufoo forms. There are built-in integrations! For example, say you have a form that includes an email address field, and you'd like to ship that email address over to MailChimp or Campaign Monitor into a particular mailing list. That's just a few clicks away. Or say the form has some element of lead generation and you want to send the details to Salesforce. Or you want to tweet data from the form upon submission. Same deal, just a few clicks.
One of my favorites is that Wufoo works tremendously well with Zapier. That's the whole point of Zapier, you can use it to connect services together! For example, the Ask a Question form over on the ShopTalk website not only emails Dave and I but adds the question to a Trello board for us to organize into shows. We could easily have it integrate into Evernote, dump into Google Sheets, or work with any of hundreds of other services. Wufoo is such a great source of data for integrations, it begs for playing with.
The story of FOUT is so fascinating. Browsers used to do it: show a "fallback" font while a custom font loads, then flop out the text once it has. The industry kinda hated it, because it felt jerky and could cause re-layout. So browsers changed and started hiding text until the custom font loaded. The industry hated that even more. Nothing worse than a page with no text at all!
Font loading got wicked complicated. Check out this video of Zach Leatherman and I talking it out.
Now browsers are saying, why don't we give control back to you in the form of API's and CSS. You can take control of the behavior with the font-display property (spec).
This came up the other day. I forget where, but I jotted it down in my little notepad for blog post ideas. I wrote it down because what I was overhearing was way over-complicating things.
Say you have a form like this:
<form action="/submit">
<!-- inputs and stuff -->
<input type="submit" value="Submit"/>
</form>When you submit that form, it's going to go to the URL `/submit`. Say you need another submit button that submits to a different URL. It doesn't matter why. There is always a reason for things. The web is a big place and all that.
Let's say you took on a client, and they wanted something very specific from you. They wanted a website that without any changes at all, would still look good in 10 years.
Turns out, when you pose this question to a bunch of web designers and developers, the responses are hugely variant!
Just a bit of forking fun, kicked off by Tim Van Damme and the inimitable Party Parrot.