Just the other day Kilian Valkohof wrote this great piece about how to create a full-bleed layout effect where an element like an image breaks out from the grid you’ve established.
Kilian shows us how he does that with plain ol’ CSS:
body > *:not(img) {
position: relative;
max-width: 40rem;
margin: auto;
} The :not pseudo-class above will set the max-width of every element on a page that isn’t an <img> to have a max-width of 40rem. So you get something like this:
This isn’t the only way to create this full-bleed effect where images stretch across the whole page. A while back Josh Comeau wrote about how to create a full-bleed layout using CSS Grid and the whole post is absolutely worth reading.
But! Kilian argues that if the :not selector works, without having to setup a complex Grid solution to this problem then we should use it because his code abides by the principle of least power. Kilian then describes that principle like this:
When I build websites, I try to stick to the principle of least power. This states that you should use the least powerful language that does the job. In other words, don’t go straight for the more complex language (like JS) if a simpler language (like CSS or HTML) can also do the same thing. The simpler language will be more maintainable, more robust and easier to understand.
I think about this all the time, especially when it comes to design systems. Whenever I create a new component or a new design my thinking goes something like this:
- Can I use HTML?
- If not, can I get away with lightly styling the markup?
- Can I change the design to make this easier to implement?
- Dangit okay, if I can’t do that then I’ll hand-write some JavaScript to solve this problem.
- Eff it—okay, this is annoying—I’ll pull in a third-party library.
It’s all too easy to jump straight to step 5 here and pull in a third party library to solve our problems, or npm install something because we don’t want to have to go through the pain of the trying the first four steps. But with almost every codebase I’ve worked on I’ve found this—the principle of least power—is definitely the right way to approach web development in general.
All of this ties neatly into what Jim Nielsen mentioned just the other day when it comes to cheating entropy with old projects:
HTML, CSS, and JS are, in a semver sense, still at version 1.x. Whatever you wrote in 2018 or 2008 will still work. On the other hand, a project built on abstractions from native web technologies—frameworks, tooling, language sub/supersets—will contain innumerable dependencies with countless major version changes over time. Updating a single dependency often requires updating everything. Building on top of base web technologies, where possible, is a way to cheat the entropy and churn of modern web technology abstractions.
All that can be summed up like this: the principle of least power is progressive enhancement.
Beautiful CSS Transform Examples
Over on the Polyplane blog, Kilian also captured examples of great CSS 3D transforms and provided the code to show us how to pull these off.
I particularly like example no.11 that can be found on the Augmented AI website, where three shapes overlap each other and then on hover they stack together like this:
This is a really great collection of animations, and so it’s definitely worth scrolling through the whole lot here.
Animating Number Counters
Carter Li shows off some pretty snazzy tricks here by animating numbers with CSS variables, just like in this example below:
The trick is to declare the CSS custom property as an integer; that way it can be interpolated (like within a transition) just like any other integer.
The code example that Li shows off looks something like this and has this rather peculiar beginning that I want to dig into a little bit:
@property --num {
syntax: '<integer>';
initial-value: 0;
inherits: false;
}
div {
transition: --num 1s;
counter-reset: num var(--num);
}
div:hover {
--num: 10000;
}
div::after {
content: counter(num);
}But wait… what is that weird @property --num thing on the first line? Well, is something Chris wrote about not so long ago and it’s the CSS version of JavaScript’s CSS.registerProperty that we use to declare CSS custom properties as a particular type. Otherwise, custom properties are strings are far more limited in how they can be used. Thanks Houdini! (Blink-based browsers only for this one so far).
I have a feeling that this CSS.registerProperty stuff is going to open up a whole new world of possibility for us web developers, from animating background-gradients to animating counters, to…?
On the Web Share API
Have you heard of this API before? The idea is to let web developers pop open this drawer like you see in iOS:
And that feels a whole lot better than adding a ton of widgets and custom JavaScript what-nots for things like Twitter and Facebook, etc. that we saw especially prevalent on news sites.
So Chris has written this handy post about the current state of the Web Share API and how he goes about using it. This feels very principle of least power to me.
The Widening Responsibility for Front-End Developers
“The moment I fell in love with front-end development was when I discovered the style.css file in WordPress themes,” writes Chris in this rather lovely essay all about how our jobs as front-end developers appears to be expanding.
This is something I felt powerfully learning about the float CSS property when I was in my teens—being able to move anything in the browser at the drop of a hat felt so powerful to me. All of a sudden, browsers felt like something that I could control and learn and wield. Front-end development is one of those things that encourages entry into it because of this very feeling and because it’s so gosh darn accessible. Pop open DevTools in your browser and voila—you are now a front-end developer.
Well, Chris argues that it gets a lot more complicated from there. Once you’re hooked into front-end development there’s so many different frameworks and stacks and ways of doing things. Chris continues:
CSS will always be my favorite and HTML feels like it needs the most love — but JavaScript is the one we really need to examine the last decade has seen JavaScript blossom from a language used for a handful of interactive effects to the predominant language used across the entire stack of web design and development. It’s possible to work on websites and write nothing but JavaScript. A real sea change.
I absolutely believe that the HTML language needs the most love from us right now. And I’ve argued before that we need a new movement from developers to vastly expand the toolset available to us. Just think about the last decade and how CSS and JavaScript are fundamentally different now. But HTML has been in this sort of…stasis the whole time? Maybe that’s unfair. That’s certainly what it feels like though.
Either way, us front-end developers have a responsibility to care for every part of the web browsing experience—and that responsibility is growing.
Sponsor
WooSesh
A (free) two-day virtual conference for WooCommerce store builders that will help grow your business on October 13-14th, 2020. Learn from loads of WooCommerce experts on how to improve your WooCommerce store, including a big State of the Woo update from the WooCommerce team themselves.
[Chris]: Jeremy:
If you’re a web developer, there are two possible reactions to hearing this. One is “Duh! Everyone knows that!”. The other is “What‽ I never knew that!”
He’s talking about a reaction to learning something about browsers. I have found this exact same dichotomy of reactions to be true. Here’s the rub:
Safari is the only browser on iOS devices.
I don’t mean it’s the only browser that ships with iOS devices. I mean it’s the only browser that can be installed on iOS devices.
You can install something called Chrome. You can install something called Firefox. Those aren’t different web browsers. Under the hood they’re using Safari’s rendering engine. They have to. The app store doesn’t allow other browsers to be listed. The apps called Chrome and Firefox are little more than skinned versions of Safari.
We don’t know exactly why Apple does this. As far as I know, they’ve never clearly explained themselves on why this is the case. We can guess. We could guess that Apple is worried about other browsers performing badly and chewing up battery power and making the mobile devices look bad. We could guess that browsers do so much, that securing them on the OS becomes a lot of work and essentially Apple’s job and they just don’t see enough of an upside to go through that. We could guess that Apple thinks, hey, there already is a browser engine on these devices, we think it works great, why bother with the effort needed to allow alternatives?
I find the stance of: it’s our device, we make the rules, if you don’t like the rules, don’t use the device fairly understandable. At one billionth of the scale, I help make the rules at CodePen. It only supports some languages and has rules about behavior. If you don’t like what we support or those rules, then don’t use CodePen. At Apple’s scale, it’s different. The law gets involved with anti-competitive behavior. Jeremy:
Microsoft got fined for anti-competitive behaviour when they pre-bundled their web browser with Windows back in the 90s. You could still install other browsers, but just the act of pre-bundling was seen as an abuse of power. Imagine if Windows never allowed you to install Netscape Navigator?
And yet that’s exactly the situation in 2020.
I certainly don’t understand the law well enough to know if it applies here. I wonder if the Epic vs. Apple stuff will reveal anything as that lawsuit goes on. We’re certainly getting that vibe from Apple so far: our device, our marketplace, our rules.
I know what I do want: for Apple to explain exactly what their position is on alternative browser engines on iOS or iPadOS in no uncertain terms.
Sponsor
Testim
Software test automation has existed in one form or another for many decades. The benefits of test automation are huge in terms of increasing product quality while reducing costs and time to market. Get started on Test Design Strategy today.
