Now that we’re out of the ‘dark times’ where CSS was so limited that we spent countless hours developing hacks, tricks, and workarounds… Sacha Greif wonders if the pendulum has swung the other way:

we are now faced with an embarrassment of CSS riches, and it can be hard to catch up. CSS Grid started being supported in major browsers almost five years ago, yet I still check a reference every time I use it. And as cool as subgrid seems, I’ve yet to even try it out.

Perhaps CSS is even starting to reach over into areas best handled by HTML or JavaScript?

This is a nice round-up of some new(ish) HTML and JavaScript features related to forms. Now that Safari 16 is out, good stuff like requestSubmit and showPicker are looking pretty green!

Daniel Schwarz runs down 6 web browser hacks to aid your web development workflow.

1. Activating design mode
2. Applying a background to everything
3. Simulating events
4. Setting cookies
5. Toggling classes
6. Color widget bookmark

Chris does a great job answering what will surely be the most common question about this acquisition in his announcement post:

1. What happens to CSS-Tricks?
2. Will you still be running CSS-Tricks?
3. Why now?

The amount of value this team has given to the web world over the years is immeasurable.

I sincerely hope DigitalOcean turns out to be a worthy new steward of this precious resource and the site’s best years are ahead of it. 🤞

The linked post is about a new book by Jeremy Wagner, but I just wanted to highlight the excellent aside on book writing by Chris Coyier near the end:

Write a blog post first, or maybe a whole bunch of blog posts. That’ll prove you clearly have words to say about this. Plus it will get the energy of your idea into the world. You might get feedback and constructive insights on the idea as it is shared. Then, hopefully, you can turn that blog post into a talk. That’ll really get you thinking deeply about your idea while getting even more comfortable with the idea of sharing it clearly. And, if all goes well, turn all of that into a book!

Looks like Jeremy did just that.

Chris Coyier does a great job rounding up and summarizing conversations around #AppleBrowserBan:

Just last week I got one of those really?! 🤨 faces when this fact came up in conversation amongst smart and engaged fellow web developers: there is no browser choice on iOS. It’s all Safari. You can download apps that are named Chrome or Firefox, or anything else, but they are just veneer over Safari. If you’re viewing a website on iOS, it’s Safari.

Chris Coyier on some of the new(ish) CSS compilers (such as Assembler) and how they’re flipping the script:

The popular Tailwind framework supports it. It kind of flips the mental model of Tailwind on its head, to me. Rather than providing a huge pile of CSS utility classes to use — then “purging” what is unused — it only creates what it needs to begin with.

Chris Coyier is not too pleased about browsers changing the way cross-origin iframes handle certain native JavaScript calls such as alert and confirm:

Cross-origin iframes are essentially the heart of how CodePen works. You write code, and we execute it for you in an iframe that doesn’t share the same domain as CodePen itself, as the very first line of security defense. We didn’t hear any heads up or anything, but I’m sure the plans were on display.

The change is about security and performance, it seems. There’s a workaround using postMessage, but that comes with its own problems that Chris details. Overall, it seems the way this change is being rolled out is more of a concern than the change itself…

Believe it or not, I generally am a fan of Google and think they do a good job of pushing the web forward. I also think it’s appropriate to waggle fingers when I see problems and request they do better. “Better” here means way more developer and user outreach to spell out the situation, way more conversation about the potential implications and transition ideas, and way more openness to bending the course ahead.

I believe Chris Coyier put that period at the end of this post title for a reason:

Putting images on websites is incredibly simple, yes? Actually, yes, it is. You use <img> and link it to a valid source in the src attribute and you’re done. Except that there are (counts fingers) 927 things you could (and some you really should) do that often go overlooked. Let’s see…

He goes on to list 15 bullet points of things to consider. This images situation is actually a microcosm of the web (and all software?) itself: it appears easy/simple at first, but the deeper you go, the more dizzying the depth.

Ashley Kolodziej speaking directly to HTML:

You are the foundation of the Internet. You are the bridge between humans and information. When we say HTML isn’t an expertise in and of itself, when we take you for granted, we leave behind the people and systems who access that information using web crawlers and accessibility technology.

and CSS:

There is a time and place for specificity, and I cherish your ability to manage that. I love your system of overrides, of thinking ahead to what should and shouldn’t be modifiable by another developer easily. I find the appreciation of specificity and !important and contrast and all the beautiful little things you do well increasingly lost in the pursuit of the newest and shiniest frameworks.

A lovely love letter to two of my favorite technologies. 💚

Sarah Drasner:

I’ve been a manager for many years at companies of different scale. Through these experiences, I’ve done my share of learning, and made some mistakes along that way that were important lessons for me. I want to share those with you.

The four mistakes that Sarah details, which we can all learn from:

1. Thinking people give feedback the way they want to receive it
2. Trying to do everything yourself as a manager is the best way to help
3. Communicating something one time is enough
4. You have to have everything together all the time

The TL;DR answer is yes (when it comes to layouts), but the full answer is longer, more annoying, and well-explained in this post by Robin Rendle for CSS-Tricks.

Chris Coyier rounding up recent frontend moves (by Basecamp and React, specifically) back to server-side rendering techniques of old:

So: servers. They are just good at doing certain things (says the guy typing into his WordPress blog). There does seem to be some momentum toward doing less on the client, which I think most of us would agree has been taking on a bit much lately, which asset sizes doing nothing but growing and growing.

Let’s push those servers to the edge while we’re at it.

I agree. Servers are cool. Clients are cool, too. But so are servers.

Sean C Davis writing on CSS-Tricks:

A colleague of mine built a static site generator evaluation cheatsheet. It provides a really nice snapshot across numerous popular SSG choices. What’s missing is how they actually perform in action.

Sean set out to test 6 of the most popular SSGs on the market today. The results are somewhat expected (Hugo is the super fast), but there are some surprises in there as well (Hugo scales poorly, but it doesn’t matter so much because it’s super fast)

Chris Coyier:

This is an extended version of my essay “When front-end means full-stack” which was published in the wonderful Increment magazine put out by Stripe. It’s also something of an evolution of a couple other of my essays, “The Great Divide” and “Ooops, I guess we’re full-stack developers now.”

This is a lengthy, sprawling piece on the evolution of frontend development by someone who really gets the web. It also has its own art-direction and design so you’ll want to read it onsite vs in an Instapaper-alike.

Chris Coyier:

You might reach for <input type="number> when you’re, you know, trying to collect a number in a form. But it’s got all sorts of issues. For one, sometimes what you want kinda looks like a number, but isn’t one (like how a credit card number has spaces), because it’s really just a string of numbers. Even more importantly, there are a variety of screen reader problems.

(We discuss the uncanny valley of number inputs on this JS Party episode about the stale parts of browsers.)

Turns out the best practice (just use text inputs) has a twist to it: inputmode!

Mike Turley for CSS-Tricks:

JavaScript developers have realized that by defining a page’s structure in JavaScript instead of in HTML (using frameworks such as React), they can simplify the development and maintenance of user interaction code that is otherwise much more complex to build. Of course, when you tell someone that the HTML they wrote needs to be chopped up and mixed in with JavaScript they don’t know anything about, they can (understandably) become frustrated and start asking what the heck we’re getting out of this.

I get this question occasionally and I often have trouble answering it. All of the materials I’ve found on this topic are written for an audience that is already familiar with JavaScript — which is not terribly useful to those who focus on HTML and CSS. But this HTML-in-JS pattern (or something else that provides the same benefits) will likely be around for a while, so I think it’s an important thing that everyone involved in web development should understand.

Chris Coyier:

The “official website” changed their language from JAMstack (evoking the JavaScript, APIs, and Markup acronym) to Jamstack. It’s nothing to be overly concerned about, but I care as someone who has to write the word in a professional context quite often. If we’re going to “Jamstack,” so be it.

I prefer JAMstack, myself, but I think the Ajax analogy he quotes is an apt one. Aside: if this trend continues, Chris and the team might need to rename the site to “Jamstack-Tricks” soon.

Oh, and while we’re here: It’s Changelog not ChangeLog 😄

When you add anything with user-generated content or dynamic data to a static site, the complexity of the build process can become comparable to launching a monolithic CMS. How can we add rich content to static sites without stitching together multiple third-party services?

Every time I get into the nitty gritty of JAMStack implementations with anything but static content sites I end up saying (or merely thinking to myself), “This sounds like a whole lot of work to avoid some server-side rendering…”

This piece on CSS Tricks appears to back up that premonition:

Despite my enthusiasm, I’m often disheartened by the steep complexity curve I typically encounter about halfway through a JAMstack project. Normally the first few weeks are incredibly liberating. It’s easy to get started, there is good visible progress, everything feels lean and fast. Over time, as more features are added, the build steps become more complex, multiple APIs are added, and suddenly everything feels slow. In other words, the development experience begins to suffer.

The good news is there are many smart, talented folks working on solving the various challenges that JAMStack sites face.

Our friends at CSS Tricks are doing an awesome year-end series where they ask builders they admire the question, “What about building websites has you interested this year?” and each person writes a post about it. What gets Sameera Kapila excited resonates with me:

I realize we’re moving from a place where we’re not just sharing what we have, we’re working to build and improve on what others have built. And then sharing that, and the cycle continues. In a way, we’ve been doing this all along but it feels more noticeable now. In a way, we’re not just building websites, but building and iterating the way we build websites, and that is exciting.

The thing I love the most about this bundler: it doesn’t need any configuration. Literally, none at all! Compare that to webpack where configuration can be strewn across several files all containing tons of code…

Nice rundown and tutorial on getting started with Parcel.

Chris Coyier can’t help but chime in after listening to our recent debate episode of JS Party.

I enjoyed all the stumbling around the terminology of “web apps” and “web sites” (web things!). This is such a weird one. It’s so easy to picture the difference in your head: it’s like facebook versus a blog! But when you start trying to define it exactly, it gets really murky really quickly and the distinction loses any value, if it had any to start with. Here’s more on that.

Chris has a lot of great insights here. Whether you agree or disagree, I think we can all get on board with one thing: we make web things!

This article is Chris Coyier doing what Chris Coyier does best: pulling on people’s views from around the community, then sprinkling in his own take as he goes.

I’ve always felt a little put off by the clip-path property, thinking it was rather obscure and probably not worth learning. Boy was I wrong. In this article Travis Almand takes us through how incredibly powerful this property is, and how by animating it you can create a range of beautiful transition effects with a few simple lines of CSS.

Even though there’s a promise of native lazy loading with the launch of Chrome 75, between now, then, and the time period for the other browsers to adopt it as well, we have to continue developing our own lazy loading implementations using JavaScript. From Phil Hawksworth on CSS Tricks:

In this post, we’ll look at an implementation that’s already been covered in brief detail in this post by Preerhi. We’re going to expand on that so you can add your own implementation of lazy loading to your site site as I’ve done on this little demo site.

Phil covers these topics…

• The HTML markup for lazy loading
• Spotting when to load images with Intersection Observer
• Adding support for responsive images with picture and source elements
• Creating an attractive initial state with small images and CSS
• Mass-producing image assets
• Creating helpers to generate the required HTML