There’s been a run of tools, articles, and resources about color lately. Please allow me to close a few tabs by rounding them up here for your enjoyment.
Curated colors in context
Happy Hues demonstrates a bunch of color palettes in the context of the site itself. That’s a nice way to do it, because choosing nice colors isn’t enough — it’s all about context. It can go bad, as the Refactoring UI blog demonstrates.
Dynamic, Date-Based Color with JavaScript, HSL, and CSS Variables
Rob Weychert shows off how he created date-based color schemes (so that every single day of the past 30 years would have a unique color scheme, each day looking slightly different than the day before).
Calculating Color: Dynamic Color Theming with Pure CSS.
Build a site on a single domain, but detect mobile, and render a separate mobile site
Build a separate mobile site on a subdomain
It’s funny how quickly huge industry-defining conversations fade from view. This was probably the biggest question in web design and development this past decade, and we came up with an answer: It’s #1, you should build a responsive website. Any other answer and you’re building multiple websites and the pain from that comes from essentially doubling the workload, splitting teams, communication problems across those teams, inconsistencies across the sites, and an iceberg of other pain points this industry has struggled with for ages.
But, the web is a big place.
This emailer specifically mentioned imdb.com as their example. IMDB is an absolutely massive site with a large team (they are owned by Amazon) and lots of money flying around. If the IMDB team decides they would be better off building multiple websites, well that’s their business. They’ve got the resources to do whatever the heck they want.
The most likely answer from the thread: DOS was a massive operating system for PCs for a long time and it had a three-character limit on file extensions.
Interesting that the first book on HTML covers this specifically:
Where my mind went was server software. I know that web servers automatically do different things with different file types. In a test on my own server (set up to serve a WordPress site), I put some files at the root that all contain the exact same content: <h1>Cool</h1>
file.text = file is rendered as plain text in browser (Content-Type: text/plain)
file.html = file renders as HTML in browser (Content-Type: text/html)
file.htm = file renders as HTML in browser (Content-Type: text/html)
file.fart = file is downloaded by browser (Content-Type: application/octet-stream)
You can write code to serve files with whatever content types you want, but in lieu of that, file extensions do matter because they affect how default web servers choose to serve file type headers.
Is it harder or easier to build a website now than 10 years ago? Has the bar gone up or down? I don’t have any data for you, but I can shell out some loosey-goosey opinions.
HTML
HTML5 was the only big HTML change in the last decade, and it wasn’t particularly dramatic. It’s cool it’s the looser variant (instead of getting XHTML3 or something). More compatible this way. Maybe I’ll close my <br /> and maybe I <br> won’t. Having better semantic tags (e.g. <article>) is great. Input types are wonderful. But none of this pushes HTML to be significantly easier or harder.
Same.
CSS
CSS has gotten easier. We use way fewer „hacks” all the time. I can literally feel it. The CSS we write today feels so intentional and direct. 10 years ago I feel like every other element had some kind of weird hack on it, and today, almost none. If CSS feels any harder, I’d wager it’s because the sites we’re building are bigger and more complex so the styling systems for them need to be all the more robust and the dangers of getting it wrong more stark.
Easier.
JavaScript
I’m sure there are strong arguments to be made both ways here. The language, perhaps, with all its recent syntactic innovation… perhaps easier. But what JavaScript is being asked to do, and what we’re doing with it, is so astronomically larger that more difficulty comes along for the ride. It’s similar to CSS in that way, but even more pronounced since we’re not just doing what we were before on a new scale; we’re building entire interfaces with the language in a way we just weren’t before.
Harder.
Domains
I mention this one because it’s such a crucial step in any given person’s ability to go from zero to actually having a website.
I don’t think buying a domain name is any easier. Domain names are a commodity market, so the companies selling you them are selling you them for some other reason, meaning the incentive is very high for them to push other products on you. For someone entirely green, I can imagine the confusion is either high or they don’t know enough for the confusion to settle in yet. Do I buy it through this page builder thing? Do I have to buy it through this page builder thing? Do I need the WHOIS protection? Oh god, what even is DNS? I guess I do want email, right? Or is that like some weird special hosted email? Ughjakd. I’m gonna call it a wash. Nothing has made this any easier or harder in a decade.
Same.
Hosting
There is so much money in hosting it kind of blows my mind that we don’t see deeper innovation here. I might argue it’s a little easier these days. But commodity low-end hosting isn’t terribly different or being any more or less helpful than it was a decade ago. We’re still largely stringing together our own bespoke build and deployment processes like we were 10 years ago.
Large-scale stuff might have seen a lot of innovation, a la AWS, but nobody is going to argue that stuff is anywhere near easy.
The most innovation we’ve seen is from companies like Netlify and Zeit who are looking at the developer experience wholistically from helping you run things locally, to testing builds in staging, to immutable deploys. I’d love to see all hosting companies realize that every single one of their customers needs to get their code onto their platforms and they have a massive opportunity to help us do that directly.
Slightly easier.
How people actually do it
I like thinking about HTML, CSS, and JavaScript. But of course, precious few people actually start with those technologies to build actual websites from scratch. Really they end up being treated as underlying technologies you dabble in amongst a slew of other tech.
You can build a website from just an index.html file. I’d argue more people should. But people reach for more „complete” solutions and customize from there. I know I did. The first websites I ever created were WordPress because it was a whole website in a box (with its own struggles) and I customized it. People still do that today, probably more now than 10 years ago, and I don’t feel like it’s significantly easier or harder. Or they reach for something familiar. I made a one-page index.html site not long ago, only to have it picked up by another developer who turned it into a create-react-app site but otherwise changed nothing. They just didn’t know how to work on it without React.
Or they use WordPress.com, or Squarespace, or Wix, or Shopify, or BigCommerce, or you know what I mean. This isn’t about what people can do, it’s about what people do do. And for most people, these apps significantly lower the bar of creating a website.
So, for the average person, is it easier or harder to go from zero to having some kind of website?
Much easier.
Can people actually do it?
If we’re talking about creating from scratch, it’s interesting to see who feels like they even hold those keys anymore. The whole idea for this post came from a conversation I had with someone who has been a front-end developer and was asked to build a website by a friend. They declined because they didn’t know how.
Chatted with someone who’s been working at a company as a front-end developer for 3 years. Their friend asked them to help build a website, but they had to decline. They didn’t know how.
Some part of that doesn’t surprise me. As I write, the world is awfully full of React-specific developers working on huge sites (partially due to boot camps, partially due to market demand). They understand that very specific ecosystem and are perfectly productive within it, but don’t have a wider understanding of how it all comes together to make the complete site.
Specialists are specialists!
Them: What do you do? Me: I’m a web designer Them: Cool! Can you help me build my website? Me: [laughing] Oh god no, I have no idea how to do that
Another part of me is surprised. You know an index.html file with „Hello, World!” in it can be a website, right? Even React devs are generally highly aware of create-react-app and how that scaffolds out a ready-to-rock site. Tools like Stackbit slap together a JAMstack site for you that can go anywhere. For developers, it seems to be going from zero to website is a heck of a lot easier these days.
If you were starting out as a front end dev in 2020, what would you say is the first thing you would learn and why?
You need to put yourself in a position where it’s your job to create and take care of a website. Even if that feels like a stretch for you early on. Get the domain, get the website on the public internet. Put your name on it. Now you’ve given yourself stakes, and you’ll learn technology because you must make your ideas come to life.
For me, 650 years ago, that was putting up a website for the ol’ college band. We needed a website! That sounded like fun to me, and I managed to struggle through buying a domain, hosting, and putting up a WordPress website. Then, over time, I learned front-end web technologies because I wanted to change up the design, change up the templates, add cool features, etc.
Get yourself a project and learn through the project.
How do you determine what you want to turn into a blog post and what you leave as a simple Tweet?
I usually won’t avoid the tweet. The tweet is usually a good proving ground for the blog post anyway. If nobody cared, eh, maybe not that good of a post. If it does get good engagement, it’s like the conversation around it is useful in the creation of the blog post. Plus, tweets are so easy to kick out the door. Blog posts, for me, on purpose, have a longer schedule that includes editing and scheduling and such.
Here’s an example tweet. Just a silly little UI experiment. I didn’t feel like waiting to blog about it to drop the demo. But from the Twitter thread, I got some interesting technical feedback, info about what parts people were most suprised by, and some other related ideas. That will, hopefully, lead to a much more robust blog post.
Do you have a favorite CSS-Trick, where you were just like „wow”?
I think „scroll shadows” in CSS is one of my favorite CSS tricks of all time. It’s originally by Roman Komarov, but explained and improved by Lea Verou. I saw a tool the other day around the idea by Stefan Judis.
It’s a real mind-bender involving four-layered gradient backgrounds, each positioned, sized, and colored differently, and then behaviorally different regarding scrolling.
It’s not just a neat trick because it has real UX implications. Showing a shadow of where you can scroll is important UX. Consider this story of a recent design update in iOS that led to complete confusion around UI actions hidden behind a place you could scroll to, but had zero affordance on how to get there. (Happens to me all the time in Spotify, for the record.)
What would be your top 3 pieces of quick advice for developers trying to follow a similar path to growing their influence and exposure?
I think writing is literally the only way.
I can’t think of a developer with influence who has that influence for anything other than writing. Or if it’s not writing, then it’s a YouTube channel or some other form of creating public stuff.
How much do you see yourself personally playing with Houdini APIs as they are released? Which API are you most excited about (Painting, Layout, Typed OM, …)?
This super-low level stuff sometimes feels over my head. It’s hard for me to picture the industry implications of stuff like this just by looking at specs, ya know?
To me, it seems the Layout API has the most powerful potential.
What I’m imagining right now is that Houdini doesn’t affect normal day-to-day front-end developers like me that much. I won’t be writing much Houdini code. But I’ll use fancy things that other people create, because it does something useful for me. Just like most people don’t write their own libraries or have published npm packages — they just use them.
What is your favorite thing about working at CodePen and/or CSS-Tricks?
You know what I really like? I like getting into the office every day and having a pretty decent amount of freedom of what I’m going to do that day. I’ll probably have meetings. I’ll probably have some stuff on the ol’ calendar. I’ll probably have some team expectations I’m trying to meet. But I also usually have plenty of time to pursue things that are interesting to me at the moment.
Sometimes I’m in the moment to drill through some emails. Sometimes I want to tinker with some demo that sounds like fun. Sometimes I want to write up a thought or record a video. Sometimes I want to plan something out or document something. Sometimes I want to talk something out with other people or do some pair programming.
I’m fortunate that I’m the boss (lol) and I put myself in that position on purpose so I have that freedom.
What is something that you wish we could add in CSS?
I feel like every time someone asks this we all should take every opportunity to scream Container Queries! until we get them.
The idea is that we should be able to write CSS that says, „When this element is this wide, this CSS should take effect.” And not just width, but whatever media queries we have at the page level already.
I want to write a card component that shuffles itself around based on how wide it is, not how wide the page is, because there isn’t always a direct connection between those two things (e.g. a card component can show up in a narrow sidebar on a large screen, but be full-width on a tablet or something).
Every component can be in a situation like that, so for the love of CSS, let me write media queries scoped to those components. I echo a lot of other people when I saw that if we had this, the vast majority of media queries we write would be these, not page-level.
Do you think it’s worth suggesting a { position: above-fold; }?
I’m not sure I’ve ever made a big fold-based decision once in my career. Not a big fan of that thinking. THERE IS A LINE IN WHICH THIS IMPORTANT MODULE MUST NOT CROSS, haha. Prioritizing the most important stuff to be higher up the page, sure. Websites don’t fold like newspapers.
Plus, we’ve got viewport units now, so if you absolutely need to position something in the top visible viewport area, you can.
Since you’ve been writing blog posts for so long, have you developed a process for writing one?
Sorta! It still feels pretty casual to me (let’s call my writing medium quality), so it’s not like I’m renting a cabin in the wilderness and finding inspiration in the sunsets and cheap whiskey.
I write down every blog post idea that comes to me. I try to keep that list fairly public but I also have a personal list where I can be even sloppier.
I put as much context into those lists as I can, so I can hope to summon up the same emotion that made me write it down in the first place. If I revisit the idea a week later and can’t, it’s probably not a very good idea.
I write up the post with as much context as I can. Light research is typically involved.
We have a lead editor on CSS-Tricks, so it’s reviewed by at least one person before being scheduled.
CSS or CSS-in-JS?
I see a ton of cool stuff happening in CSS-in-JS. I think it solves a lot of interesting problems for certain websites. For example, I very much like the idea of having the option to write styles that are scoped to a component programmatically, and thus are tree-shaken when the component isn’t used automatically.
But the web is a big place, and dare I say most websites aren’t built with JavaScript-powered component models. Thus, CSS-in-JS isn’t necessary or appropriate for a lot of sites.
Although, two things to be clear:
You can’t have CSS-in-JS without CSS. CSS-in-JS is still styles that are applied to elements. It doesn’t absolve you from learning CSS.
The CSS-in-JS landscape is wide. It’s a little hard to talk about so vaguely. Each project in the bucket of CSS-in-JS handles things a bit differently and how the styles are applied to the site is even quite wide. I think it sometimes gets lost in the arguments that some of the approaches literally make a CSS stylesheet that you link up like you would any other CSS — even Sass-produced CSS — which there doesn’t seem to be much argument about anymore.
This seemingly simple task had me scratching my head for a few hours while I was working on my website. As it turns out, getting the current page URL in Gatsby is not as straightforward as you may think, but also not so complicated to understand.
Let’s look at a few methods of making it happen. But first, you might be wondering why on earth we’d even want to do something like this.
Why you might need the current URL
So before we get into the how, let’s first answer the bigger question: Why would you want to get the URL of the current page? I can offer a few use cases.
Meta tags
The first obvious thing that you’d want the current URL for is meta tags in the document head:
I’ve seen it on multiple websites where a link to the current page is displayed next to sharing buttons. Something like this (found on Creative Market)
Styling
This one is less obvious but I’ve used it a few times with styled-components. You can render different styles based on certain conditions. One of those conditions can be a page path (i.e. part of the URL after the name of the site). Here’s a quick example:
Here, I’ve created a styled Layout component that, based on the path, has a different background color.
This list of examples only illustrates the idea and is by no means comprehensive. I’m sure there are more cases where you might want to get the current page URL. So how do we get it?
Understand build time vs. runtime
Not so fast! Before we get to the actual methods and code snippets, I’d like to make one last stop and briefly explain a few core concepts of Gatsby.
The first thing that we need to understand is that Gatsby, among many other things, is a static site generator. That means it creates static files (that are usually HTML and JavaScript). There is no server and no database on the production website. All pieces of information (including the current page URL) must be pulled from other sources or generated during build time or runtime before inserting it into the markup.
That leads us to the second important concept we need to understand: Build time vs. runtime. I encourage you to read the official Gatsby documentation about it, but here’s my interpretation.
Runtime is when one of the static pages is opened in the browser. In that case, the page has access to all the wonderful browser APIs, including the Window API that, among many other things, contains the current page URL.
One thing that is easy to confuse, especially when starting out with Gatsby, is that running gatsby develop in the terminal in development mode spins up the browser for you. That means all references to the window object work and don’t trigger any errors.
Build time happens when you are done developing and tell Gatsby to generate final optimized assets using the gatsby build command. During build time, the browser doesn’t exist. This means you can’t use the window object.
Here comes the a-ha! moment. If builds are isolated from the browser, and there is no server or database where we can get the URL, how is Gatsby supposed to know what domain name is being used? That’s the thing — it can’t! You can get the slug or path of the page, but you simply can’t tell what the base URL is. You have to specify it.
This is a very basic concept, but if you are coming in fresh with years of WordPress experience, it can take some time for this info to sink in. You know that Gatsby is serverless and all but moments like this make you realize: There is no server.
Now that we have that sorted out, let’s jump to the actual methods for getting the URL of the current page.
Method 1: Use the href property of the window.location object
This first method is not specific to Gatsby and can be used in pretty much any JavaScript application in the browser. See, browser is the key word here.
Let’s say you are building one of those sharing components with an input field that must contain the URL of the current page. Here’s how you might do that:
If the window object exists, we get the href property of the location object that is a child of the window. If not, we give the url variable an empty string value.
If we do it without the check and write it like this:
const url = window.location.href;
…the build will fail with an error that looks something like this:
failed Building static HTML for pages - 2.431s
ERROR #95312
"window" is not available during server-side rendering.
As I mentioned earlier, this happens because the browser doesn’t exist during the build time. That’s a huge disadvantage of this method. You can’t use it if you need the URL to be present on the static version of the page.
But there is a big advantage as well! You can access the window object from a component that is nested deep inside other components. In other words, you don’t have to drill the URL prop from parent components.
Method 2: Get the href property of location data from props
Every page and template component in Gatsby has a location prop that contains information about the current page. However, unlike window.location, this prop is present on all pages.
Quoting Gatsby docs:
The great thing is you can expect the location prop to be available to you on every page.
But there may be a catch here. If you are new to Gatsby, you’ll log that prop to the console, and notice that it looks pretty much identical to the window.location (but it’s not the same thing) and also contains the href attribute. How is this possible? Well, it is not. The href prop is only there during runtime.
The worst thing about this is that using location.href directly without first checking if it exists won’t trigger an error during build time.
All this means that we can rely on the location prop to be on every page, but can’t expect it to have the href property during build time. Be aware of that, and don’t use this method for critical cases where you need the URL to be in the markup on the static version of the page.
So let’s rewrite the previous example using this method:
This has to be a top-level page or template component. You can’t just import it anywhere and expect it work. location prop will be undefined.
As you can see, this method is pretty similar to the previous one. Use it for cases where the URL is needed only during runtime.
But what if you need to have a full URL in the markup of a static page? Let’s move on to the third method.
Method 3: Generate the current page URL with the pathname property from location data
As we discussed at the start of this post, if you need to include the full URL to the static pages, you have to specify the base URL for the website somewhere and somehow get it during build time. I’ll show you how to do that.
As an example, I’ll create a <link rel="canonical" href={url} /> tag in the header. It is important to have the full page URL in it before the page hits the browser. Otherwise, search engines and site scrapers will see the empty href attribute, which is unacceptable.
Here’s the plan:
Add the siteURL property to siteMetadata in gatsby-config.js.
Create a static query hook to retrieve siteMetadata in any component.
Use that hook to get siteURL.
Combine it with the path of the page and add it to the markup.
Let’s break each step down.
Add the siteURL property to siteMetadata in gatsby-config.js
Gatsby has a configuration file called gatsby-config.js that can be used to store global information about the site inside siteMetadata object. That works for us, so we’ll add siteURL to that object:
module.exports = {
siteMetadata: {
title: 'Dmitry Mayorov',
description: 'Dmitry is a front-end developer who builds cool sites.',
author: '@dmtrmrv',
siteURL: 'https://dmtrmrv.com',
}
};
Create a static query hook to retrieve siteMetadata in any component
Next, we need a way to use siteMetadata in our components. Luckily, Gatsby has a StaticQuery API that allows us to do just that. You can use the useStaticQuery hook directly inside your components, but I prefer to create a separate file for each static query I use on the website. This makes the code easier to read.
To do that, create a file called use-site-metadata.js inside a hooks folder inside the src folder of your site and copy and paste the following code to it.
Make sure to check that all properties — like title, description, author, and any other properties you have in the siteMetadata object — appear in the GraphQL query.
Use that hook to get siteURL
Here’s the fun part: We get the site URL and use it inside the component.
On Line 3, we import the useSiteMetadata hook we created into the component.
import useSiteMetadata from '../hooks/use-site-metadata';
Then, on Line 6, we destructure the data that comes from it, creating the siteURL variable. Now we have the site URL that is available for us during build and runtime. Sweet!
const { siteURL } = useSiteMetadata();
Combine the site URL with the path of the page and add it to the markup
Now, remember the location prop from the second method? The great thing about it is that it contains the pathname property during both build and runtime. See where it’s going? All we have to do is combine the two:
`${siteURL}${location.pathname}`
This is probably the most robust solution that will work in the browsers and during production builds. I personally use this method the most.
I’m using React Helmet in this example. If you haven’t heard of it, it’s a tool for rendering the head section in React applications. Darrell Hoffman wrote up a nice explanation of it here on CSS-Tricks.
Method 4: Generate the current page URL on the server side
What?! Did you just say server? Isn’t Gatsby a static site generator? Yes, I did say server. But it’s not a server in the traditional sense.
As we already know, Gatsby generates (i.e. server renders) static pages during build time. That’s where the name comes from. What’s great about that is that we can hook into that process using multiple APIs that Gatsby already provides.
The API that interests us the most is called onRenderBody. Most of the time, it is used to inject custom scripts and styles to the page. But what’s exciting about this (and other server-side APIs) is that it has a pathname parameter. This means we can generate the current page URL “on the server.”
I wouldn’t personally use this method to add meta tags to the head section because the third method we looked at is more suitable for that. But for the sake of example, let me show you how you could add the canonical link to the site using onRenderBody.
To use any server-side API, you need to write the code in a file called gatsby-ssr.js that is located in the root folder of your site. To add the link to the head section, you would write something like this:
We require React on Line 1. It is necessary to make the JSX syntax work. Then, on Line 2, we pull data from the gatsby-config.js file into a config variable.
Next, we call the setHeadComponents method inside onRenderBody and pass it an array of components to add to the site header. In our case, it’s just one link tag. And for the href attribute of the link itself, we combine the siteURL and the pathname:
`${config.siteMetadata.siteURL}${pathname}`
Like I said earlier, this is probably not the go-to method for adding tags to the head section, but it is good to know that Gatsby has server-side APIs that make it possible to generate a URL for any given page during the server rendering stage.
If you want to learn more about server-side rendering with Gatsby, I encourage you to read their official documentation.
That’s it!
As you can see, getting the URL of the current page in Gatsby is not very complicated, especially once you understand the core concepts and know the tools that are available to use. If you know other methods, please let me know in the comments!
GraphQL has all kinds of awesome tooling built around it. But like everything on the web, it ultimately comes down to data shootin’ across the ol’ network and responses coming back. If you need to talk to a GraphQL API endpoint, you don’t absolutely have to use some kind of framework or library to make requests against it. As a matter of fact, you can do it pretty cleanly in vanilla JavaScript.
From that page, you can execute queries and see the results. You can also poke into the Network tab in DevTools and see the payload for requests it sends off, and see that it’s just a bit of JSON that is POSTed.
We can make our own JSON in that format too! First, we’ll make it an object in the right format, utilizing template literals to make the GraphQL query look nice (which is actually required because the query syntax is dependent on white-space). Then we JSON-ify it with the native JavaScript API and POST it via the also-native fetch API.
November 30th, the official „Blue Beanie Day,” has come and gone. I’m not sure I ever grokked the exact spirit of it, but I’ve written about what it means to me. Last year:
Web standards, as an overall idea, has entirely taken hold and won the day. That’s worth celebrating, as the web would be kind of a joke without them. So now, our job is to uphold them. We need to cry foul when we see a browser go rogue and ship an API outside the standards process.
Building off that, I’d add the need to prevent browsers from breaking things that have worked for half a decade, like iOS 13 did with CSS parallax.
Mainly, though, Blue Beanie Day is receding from view because our industry as a whole thinks less and less about accessibility (not that we ever had an A game on the subject), and talks less and less about progressive enhancement, preferring to chase the ephemeral goal posts of over-engineered solutions to non-problems.
It’s people who won the browser wars, so I suppose it’s fitting that people are going to let it slip away.
I think Adam’s first prediction is his boldest, even beyond his Hail Mary prediction. CSS grid is awesome and gap is perhaps one of its best qualities, but gapsuperseding spacing things out in other ways (e.g. margin) is a bold prediction indeed, especially with Firefox being the only browser supporting it in flexbox.
