We're not going to be looking at CSS in this post but we are going to talk about tricks for taking paid vacations when no one is paying you to take time off. I suspect that there are a number of us in the front-end development community who face similar situations and addressing is one way we can figure it out together and hopefully glean ideas that make our work-life balance much healthier.
Last week's ShopTalk Show was all about HTML Email. It's such a fascinating subject, as technically it is front-end web development, but it almost feels like a bizarro alternate universe.
We have dozens of browsers to worry about, they have hundreds of clients to consider. We worry about whether fancy new APIs are supported, they worry about whether padding is supported. We have grid layout, they have.... grid layout?!
It's tempting to make the joke: "It's coding like it's 1999!", but as we talk about in this episode, that's not really true.
Aside from all that, another thing I thing fascinating are all the tools involved. Lemme think this out.
React provides two standard ways to grab values from
<form></form> elements. The first method is to implement what are called controlled components (see my blog post on the topic) and the second is to use React's
Controlled components are heavy duty. The defining characteristic of a controlled component is the displayed value is bound to component state. To update the value, you execute a function attached to the
onChange event handler on the form element. The
onChange function updates the state property, which in turn updates the form element's value.
(Before we get too far, if you just want to see the code samples for this article: here you go!)
Exactly as I did the other week, Laurie Voss saw a tweet about the complication of front-end development and responded.
From the outside, front end development in 2017 looks pathologically overcomplicated. Is this a fair perception? If so, why is it happening?
— Pinboard (@Pinboard) May 21, 2017
The replies to Maciej's tweet are interesting to read. They fall roughly into two camps:
- Older/not front-end developers: because the web is shit!
- Current front-end developers: because shit is hard!
As is often the case, both camps are correct! The web is a shitshow of wheel reinvention and bad APIs. It's also a blizzard of innovation.
Expectations for what a website should be able to do have evolved enormously. Users expect snappy, desktop-like responsiveness and rich presentation in web apps. They also expect those same web apps to work equally well on mobile devices. And they expect these apps to load basically instantly.
Still here? Cool. Let's do this.
Manton Reece and Brent Simmons have just published their thoughts on JSON Feed which is a new standard for making a feed, like a collection of blog posts. The format itself is similar to RSS and Atom but since it's in JSON it's easier to read and a lot more familiar to developers:
For most developers, JSON is far easier to read and write than XML. Developers may groan at picking up an XML parser, but decoding JSON is often just a single line of code.
Our hope is that, because of the lightness of JSON and simplicity of the JSON Feed format, developers will be more attracted to developing for the open web.
My favorite part about this project? The spec is just so gosh darn easy to read.
I find Media Temple to be a perfect fit for a mostly-front-end person like me. I'm not an idiot, I'm pretty experienced with web work, but I don't really wanna be in charge of setting up and configuring a server. That's a specialized set of knowledge that I think is well suited to the people that own, sell, and support servers. (I think that would be a pretty good career choice, FWIW, kids.) That's what Media Temple does in spades. They own, sell, and support the heck out of servers.
That's true at all levels. They have super affordable WordPress-tuned servers and shared servers that cost less than a dollar a day that can host more sites than you'll ever need (500!). You can scale up from there with virtual servers (that's what I have) and up to dedicated servers and even fully managed AWS stuff, if that's the kind of power you need.
There is no such thing as one-size-fits-all styling. An image gallery with three images might need to be styled differently than an image gallery with twelve. There are some cool tricks that you can use to add some number-based logic to your CSS! Using
:nth-last-child, you can get some surprisingly complex information without ever leaving your stylesheet.
This post will assume that you have a basic understanding of how the
:nth-child pseudo-selector works. If you need a quick refresher, Chris has a great post covering that topic.
I know there are a ton of pure CSS cube tutorials out there. I've done a few myself. But for mid-2017, when CSS Custom Properties are supported in all major desktop browsers, they all feel... outdated and very WET. I thought I should do something to fix this problem, so this article was born. It's going to show you the most efficient path towards building a CSS cube that's possible today, while also explaining what common, but less than ideal cube coding patterns you should steer clear of. So let's get started!
I bet you have a style that you write CSS in, for the most part. You like 4-spaces, say. You always have a space after braces and colons. You always put a space after rulesets. You only ever put one declaration on a line, and the only declarations that can be multi-line are when they are big blocks like a gradient or a comma-separated box-shadow.
You might take this a little further and codify this. Perhaps you have a team meeting about it and decide on how you want to style code. You write up a guide and make it available for everybody on the team to see.
Webpack is so hot right now! Webpack is great when it comes to module bundling and working with frameworks like Vue or React, but it is a bit more awkward when handling static assets (like CSS). You might be more used to handling your static assets with something like Gulp, and there are some pretty good reasons for that.
I am a huge fan of Sublime text editor and whenever I go and try other text editors I come back to Sublime crying: "Forgive me I'll never, ever, leave you again!" But I'm not here to praise Sublime. In this post I'm rather going to share some of the Sublime plugins I've been using a lot and which are really helpful and fun to work with. You may find them for your favorite text editor as well.
Let's dive into the first one.
A little while back, Nicolas Bevacqua wrote the fantastic article Making a Simple Site Work Offline with ServiceWorker. We kinda tag teamed the idea. Nicolas did all the work, but I put forth the idea (and designed the crappy little website) that we were going to make work offline. I wanted a site that wasn't as complicated as a major web app with loads of resources and API usage, but wasn't as simple as a single HTML page.
Everything in that article is up-to-date and serves as a great reference to getting started with offline capabilities for a site. Just a few notes:
- I updated the repo to make sure it was all working properly. Again the example isn't totally barebones, but simple. It has a little build script that represents fairly normal modern web development: Sass, asset concatenation/minification/sourcemaps, SVG icon system, and... shuffling things around to make a production offline version.
- I moved the demo to a CodePen Project. Now it's easier to see the code and the site itself together, and easier to fork and play around.
- I also tossed the site up at simpleoffline.website so you can see it all alone, which makes use of CodePen Projects ability to use Custom Domains.
Nice find by Ian Devlin:
:focus-withinpseudo class becomes active when an element itself has focus or if any of its descendants does.
Selecting a parent element based on children is lonnng awaited. The crown jewel of that is
:has(). I wonder if that's getting closer.