Author: Chris Coyier

CodePen is a place where you can make demos. A Pen can be anything (a painting, a game, a landing page), but by and large, Pens today are demos. Why would you make a demo? Fam, why wouldn’t you make a demo? Demos are one of the most powerful tools we have as designers and developers. But the reason behind making one can be very different. That’s why it always made it hard for me to elevator pitch CodePen: I’d want to list a dozen reasons you’d want to use it, and I’d come across as unfocused. Well, too bad. I like that there is lots of reasons to use CodePen and make demos.

Let’s make an incomplete list of reasons to build a demo:

• Prove something to yourself. You’ve seen a new library, a new web platform API, or just some kinda something you wanna try. It’s one thing to read a little something about it. That’s good, it helps you slot the [new thing] into some brain bucket where you might be able to find it later. But does it really do what you think it does? Does it? Really? Prove it with a demo.
• Get everyone on the same page super quickly. I was just in a meeting the other day where a teammate of mine highly encouraged the meeting to start with the design comp. We actually had planned it the other way around. We wanted to go over the requirements and take a look at how the data structures were coming along, then see if the early design was on target. But after switching that up to see the design first, it immediately got everyone engaged and thinking about the same thing. How it ends up on the page is the end goal, after all. There is something about interactive visuals that gets everyone perked up. Come to that next meeting with a demo.
• Demonstrate a concept in the most minimal way possible. If you’re trying to learn or teach something, removing the extraneous can be an effective way to focus on the core idea. Contextual demos are useful later once the ultra-focused demo has made its point. For example, see how effective Gabi’s Flexbox Playground is. After you understand that core concept, then you can move on to real-world usage.
• Do it in a sandbox. The concept of a sandbox is usually referencing security. It’s a safe place where you can’t screw up. Cool; useful. But it also can imply that it is untethered. Like prototyping a component without the baggage of the rest of the site. Doing work free from the usual constraints can be freeing — you might think of things you wouldn’t have otherwise.
• Help fix someone’s bug or help them fix their problem. When someone is stuck while coding, answering them with code is the best. You aren’t just running your mouth, you’re putting money in it. There is a lot of good karma to be had here — answering a question or fixing a bug with a public demo will help that person today, and more people tomorrow.
• Whimsy. A coding job can be awfully serious. You’re doing important work. Work that affects people’s lives with things they are trying to do. You should take that seriously. But that doesn’t mean everything you do has to be so sober. Get loose. Get weird. Shake it up. Let it all hang out. Code doesn’t always have to be useful. A freaky demo might be just the catharsis the doctor ordered.
• Build a variation on something. Great artists steal, they say. Grab it, tweak it, make it yours. Could be anything you see on the internet (I use the browser extension CSS Pro to do this sometimes: with it, you can select an element and click a button to whisk it over to CodePen with all the HTML and CSS intact). From a design systems perspective, component libraries are most useful when they have variations you can choose from that serve the needs of anyone using the system.
• Relax. People like to knit, ya know. And crochet and cross-stitch and sew. Oh, and do crosswords and su-do-ku and that game where you spot the differences across two images. Those things require your brain to be turned on a little bit, but it’s still relaxing. It’s not weird to relax by building a little demo just for the fun of it.
• Nothing shows you care more than a reduced test case. If you need help with code, the best thing you can possibly do is showcase your problem with as little in the way as absolutely possible. Strip away unrelated code as much as you can. Not only might you solve the problem yourself that way, anyone looking to help will be appreciative that you’re respecting their time.
• Show off. The kids call it flexing, I think. Make something so cool people just have to stop and look. Everybody deserves a little vanity. You know plenty of people have gotten jobs based on demos they’ve made on CodePen, right? It’s true. Show the world what you can do.
• Treat it like school. The secret goal of schools is getting you to learn how to learn. I’ll break it to you: if you’re building demos of your own volition outside of an educational context, school worked on you. Good on ya. If you wanted, you could work through a curriculum building code demos. That’s basically what coding schools are.
• Test something. Does it work how you think it does? Is it actually possible? How do you know if it works if you don’t test it? And equally important: is it worth it?
• Prep a hiring exercise. Live coding interviews are a little controversial, but asking someone to demonstrate that they can do the job of design and/or development during the hiring process for a job that is design and/or development is a good idea. Perhaps it’s an async thing. How much would you learn about someone if you asked them to think out the considerations around a hamburger menu? What if you asked someone to spend two hours building a tic-tac-toe game playable across two browser tabs using web sockets?
• Write some code you know doesn’t really matter. There is a good chance you got into this field because you like code. A demo you know you’re going to throw away is proof you still like that journey. You’re a musician taking pleasure in practicing some scales.

If you look at all the wonderful demos above in this very newsletter, some of them will have been created for some of these reasons. But honestly, most demos are a little more throw-away than the ones that make it into The CodePen Spark. You’ll have your own reasons.

I was thinking about all of this after reading Andy’s The art of the demo, which starts:

Nothing enhances written content quite like a well-crafted demo, or collection of demos. They don’t have to be complex either — in fact, it’s better if they’re not complex. The most important thing is that good quality demos can help people really get what you’re trying to explain, especially if reading isn’t the most effective way for them to learn.

❤️

¹ Demtaos? Nah.

Yuri Mikhin and Travis Turner over at Evil Martians implore us: Don’t wait, let’s use the browser Contact Picker API now. As I write, it’s only available essentially on Chrome for Android. But the spec exists and iOS also has an experimental flag for it. I’m an iOS guy so I flipped it on. I actually didn’t even know you could do that! (Settings > Safari > Advanced > Experimental Features).

Now if you’re in a browser that supports it…

The select method will show users a modal UI to select contacts, and it will then return a Promise. If the promise resolves, it will return an array (even if only one contact was selected) filled with ContactInfo interfaces.

I’m sure you can imagine it. You tap a button or something, and it launches a contact picker. You select a contact from your device’s contacts. It returns data from those contacts, like names, emails, and phone numbers.

Not every app needs it, but I imagine a lot could make use of it (particularly in a progressive enhancement style). Does your app have any kind of invite or sharing UI? You could use it there. I’m thinking of something like Figma’s share modal:

I’m just on my own to write in email addresses in there. If this was Google Docs, well, they have the distinct advantage that they already have a contact list for you thanks to the likelihood that you also use Gmail and keep some form of your contacts there. But very few of us are Google. The Contact Picker API levels that playing field!

I gave the Evil Martians demo a spin, and it works great.

If there were only some kind of easy-to-use web app that makes it really easy to play with new APIs like this and get a feel for them and save them for later reference. Some kind of playpen for code.

I think I was bitching about text-wrap: balance; the other day. Just like me, to be given such a glorious new property that helps makes headlines look better across the web and find something to not like about it. The balance value takes multi-line text and makes all those lines as roughly even as it can. I feel like that looks pretty good for headlines, generally. The kicker is that “balancing” isn’t always what people are looking to achieve, and what they really want is just to avoid an awkward orphan single word from wrapping down onto the next line.

Adam Argyle said to me: have you seen text-wrap: pretty;?

1. No, I have not.
2. Awww, pretty is a great keyword value in CSS.

I googled it and found Amit Merchant’s quick coverage. Then I set about making a demo and trying it out (only works in Chrome Canary until 117 ships to stable).

See what I mean about balance above? There is just far too much space left over above when all I really wanted to do was prevent the single-word orphan. Now pretty can prevent that.

That’s so generically useful I might be tempted to do something like…

p, li, dt, dd, blockquote, .no-orphan {
  text-wrap: pretty;
}

… in a “reset” stylesheet.

People reflecting on formative moments in their lives usually makes for a good story. And especially relatable when they are like: “… and that’s how I became a nerd.” That’s what happened when Alexander Miller’s dad gave him some paper:

When I was a kid, my dad gave me a piece of paper with a grid printed on it. It consisted of larger squares than standard graph paper, about an inch in size. It was basically a blank chessboard.

GRID WORLD

I didn’t become an incredible code artist like Alexander, but I can still relate. My first really “successful” programs were grid-based. First, a Conways’ Game of Life thing (that I’m still a little obsessed with) and then a Battleship clone (like Alexander’s father). These were absolutely formative moments for me.

Do you know one of the major JavaScript frameworks better than another? I bet you do, don’t you? You’re a Svelte groupie, I can tell.

Component party is a website that shows you how to do the basic and important stuff in each major framework (React, Svelte, Vue2/3, Angular, Lit, Ember, and several more). Very clever, I think! It’s helpful to know one of the frameworks so you can verify that’s how you would have done it there, then see how it works in another framework. Like if you need to loop over data in React, you probably end up doing a .map() thing, but in Svelte there is #each, where in Vue it’s a v-for attribute. I don’t work across different frameworks enough to have all this memorized so a big 👍 from me for making a useful reference here.

“Sometime this fall (2023)” is all we know for the release date of macOS Sonoma. Normally operating system releases aren’t that big of a deal for web designs and developers, who are more interested in browser version releases. But Sonoma has a trick up it’s sleeve.

With macOS Sonoma, Apple goes all-in on the concept of installable web apps. They’re highly integrated in the overall macOS experience and don’t give away their web roots by not showing any Safari UI at all.

Thomas Steiner, Web Apps on macOS Sonoma 14 Beta

Installable web apps, you say? Like… PWAs? (Progressive Web Apps). The point of PWAs, at least in my mind, is that they are meant to be real competitors to native apps. After installation, they are clickable icons right there next to any other app. Level playing field. But to become installable, there was kind of a minimum checklist of requirements, starting with a manifest.json.

The word from Apple is that there are literally zero requirements for this. You can “Add to Dock” any website, and it’ll work. I guess that means it’s possible to have a docked app that just entirely doesn’t work offline, but 🤷‍♀️.

Sites installed this way do respect all the PWA mechanics like one would hope! Sites with a manifest won’t show any Safari UI at all. I don’t think there are install prompts offered yet, so users would have to know about this and/or find the menu item. There are prompts though in regular Safari if users go to a website that is already installed (to “Open” the “app”).

Overall, apps installed this way look pretty nicely integrated into the OS. But I also agree with Thomas’ wishlist, all of which seem like they would make things much better still.

Rauno Freiberg wrote an article getting into the CSS implementation of some of the neat features of the most recent Next.js website. Gotta love an article showing off how things work on a really top-notch modern design. Thoughts as I go down the list:

• The randomized dots on the switchboard look super cool. Just a tiny little box-shadow does the trick, but they need to be animated with opacity because animating opacity is super performant and animating box-shadow is very not. I wonder if we’ll ever get past gotchas like that? Also, the dots aren’t exactly random, they are just placed seemingly-randomly. What if we had real randomization in CSS? It’s been being talked about again seriously.

• The offset focus styles were done with a box-shadow. It was noted that outline now follow border-radius across the board, which opens up that door, and is powerful thanks to outline-offset. I think I would have gone with outline-offset because I like thinking about how easy that is to control. One example: if you find that your focus styles are getting cut off by hidden overflow, you have the option to use negative offset to pull the focus styles inside where they won’t get cut off instead.

• To pull the quotation marks of a blockquote toward the inline direction a bit, lining up the words, a bit of negative text-indent was used. That’ll work cross-browser, but it’s a shame we have to rely on a magic number rather than the purpose-built hanging-punctuation property. Let’s root for better support there.

• Love to see that fluid type in action! I see the blog post is using clamp() with a viewport unit. I’d recommend making sure that middle parameter factors in a little rem unit of some kind so that user font sizing is honored. The production website actually uses max(48px,min(5vw,76px)) and I’m curious about the change there. Seems… the same? And actually, since I bet the headline is an isolated React component, it’s kinda begging for the whole thing to be a container and for the header sizing to be done with a cqi unit instead.

• The “gradient tracking” trick using a moving SVG gradient background is just incredibly cool and absolutely one of the nicest effects I’ve seen anywhere this year. 5 stars.

I did a talk somewhat recently called “Modern CSS in Real Life,” and now I’ve turned it into a blog post in case digesting it that way is of interest to you.

One of the things I dwell on in the beginning is the use of Logical Properties in CSS and how you get some nice benefits out of using them. One is that I think it very slightly makes CSS easier to reason about. But the bigger one is that it helps a site that is being auto-translated behave better. In particular, I showed off an article that would have ended up mucher nicer when being translated from the Left-to-Right English default to Right-to-Left Arabic.

I thought of that again the other day as I came across the Arabic Design Archive. It’s interesting to look at designed items that need both language directions at the same time.

I like how the main thrust of the design is RTL, forcing the English headline to be right-aligned, but still looks great. Then in the smaller and slightly longer text, both directions are accommodated nicely by that vertical bar which both inline directions butt against.

Oh and speaking of design archives… archive.design is:

A digital archive of graphic design related items that are available on the Internet Archives

If I were going to argue against @scope, the new CSS feature, I might say that CSS already has scope. Like, every selector is “scope”. If you say .el, you’re saying “scope this bit of CSS to elements that have the class name of ‘el'”. But then someone might tell you, ok, but what about “donut scope” 🍩? Donut scope is a way for a scope to stop. Keith Grant shows that off in a recent article:

@scope (.card) to (.slot) {
  /* Scoped styles target only inside `.card` but not inside `.slot` */
  :scope {
    padding: 1rem;
    background-color: white;
  }

  .title {
    font-size: 1.2rem;
    font-family: Georgia, serif;
  }
}

Imagine that applied to this HTML:

<div class="card">
  <h3 class="title">Moon lander</h3>
  <div class="slot">
    <!-- scoped styles won’t target anything here! -->
  </div>
</div>

I’m not sure how I feel about that, honestly. Don’t hate it, but also can’t think of a time when I really really wanted that. That might be because it’s never existed so my brain didn’t try to reach for it. But container queries didn’t exist before, either, and I think we all pined for those anyway. Still, it’s a bit of a +1 for @scope because it’s a thing we can’t do any other way.

If I was still arguing against @scope, then I’d say, well, it turns out actually you can replicate donut scope, thanks to another modern CSS feature, :has(), as Bramus blogged:

.from ~ :has(~ .to) {
  outline: 1px solid red;
}

And actually, you don’t even need that.

So I’m afraid I have to rescind the point I gave @scope. Are there any other tricks up its sleeve? It does have one! It’s called proximity. This is just kind of a bummer situation in CSS:

<div class="green">
  <p>I’m green</p>
  <div class="blue">
    <p>I’m blue</p>
  </div>
</div>

If you wrote the CSS like this:

.blue p {
  color: blue;
}
.green p {
  color: green;
}

Then both paragraphs are green. Just because the green selector came second. That’s just how CSS selectors work. Both have the same specificity so the latter one wins. We can fix this with scopes:

@scope (.green) {
  p {
    color: green;
  }
}

@scope (.blue) {
  p {
    color: blue;
  }
}

Now that second paragraph is properly blue because the closer scope wins (and it doesn’t matter what order they are in). This is nice for color theming when you use classes to change the theme “higher up” in the DOM. But it doesn’t save you from increased specificity of other selectors, which are probably a more common “bug”. Still, I’ll say this is worth a +1!

Still, I’m not salivating for @scope. It doesn’t solve any big pain points that I’ve personally had. But maybe it does for you, the web is a big place, so all good.

I’ve said it before, but I think the super old-school idea of wanking a <style scoped> into the DOM anywhere and having those styles scoped to the parent is still a cool idea and actually does solve problems. Coupled with :scope { } it means I don’t even have to think of a name of how to select an element, yet still get the ability to apply pseudo-elements and the like. So inline styles with more abilities. And without having to name anything, there is no possible way for the styles to leak anywhere else. Sure, it’s neat to stop style leaking with a @scope too, but because I have to apply it to a class, I need to make a super obscurely named class like .card_987adf87d (a build tool concern) for it to actually worry-lessly “scope”.

The post Chris’ Corner: Scoping appeared first on CodePen Blog.

If you’re a super normal person like me, you’ve gone to war with typographic widows and orphans many times over your years as a developer, trying to ensure they don’t happen and ruin anyone’s day. You know what I mean, a headline with one silly little word that has wrapped down onto its own line. If only you could add a couple of soft returns in there to prevent it. You can, of course, but you know better. A soft return might fix a problem at one particular container width, that break causes an even more awkward problem at another container width.

One technique that is sometimes employed is to insert a   (non-breaking space) between the last two words (maybe even three?) of a headline (or paragraphs, if you’re nasty).

This little piggy went to market

None of us can be troubled to hand-code that if we’re in charge of the HTML of headlines regularly. I wrote my own PHP to split headlines by word and manually insert the non-breaking space on CSS-Tricks a decade or more ago. It can be done in client-side JavaScript too, naturally, but nobody wants to see that reflow.

Finally, along comes the web platform with something that looks like a solution:

h1, h2, h3 {
  text-wrap: balance;
}

Tyler Sticka has an article about this new CSS and offers this clear comparison:

That “balanced” headline nice, generally a much more pleasing result for multi-line headlines.

But notably, what is happening here isn’t explicitly orphan-fighting. Richard Rutter makes this clear in an article of his own:

What this is not is control over widows and orphans. My previous examples show how the text balancing algorithm in Chrome Canary does indeed prevent a widow (the single word dropped down), and that’s a highly likely outcome. But you have to remember that the balancing job shortens the lines, so this isn’t an approach you would take to prevent widows at the end of paragraphs. In fact Canary limits balancing to 4 lines.

So it works for avoiding orphans/widows, but almost as a side effect of the balancing. In a follow-up article, Richard shines a light on what could be a future answer:

Bit by bit, the CSSWG seems to have been converging on a potential solution. In the current draft of the CSS Text Module Level 4, there is mention of Last Line Minimum Length. …

Amelia Bellamy-Royds took the Last Line Minimum Length idea and proposed a solution with a new min-last-line property. Her proposed property would specify a minimum length for the final line, and a minimum length for the penultimate line once you’d dropped a word or more down to address the short final line.

Ship it. Especially if it works on paragraphs in multi-col.

✨ Outstanding blog post alert! ✨

Future CSS: Anchor Positioning by Roman Komarov.

We only have the most rudimentary way to “connecting” the position of two elements in CSS today. Take an element that has non-static positioning, and you can absolutely position an element within that context. That’s about it. Kinda sad when you think about it — especially as it comes up relatively often. Mostly in the context of tooltips and context menus, where you want an element (of arbitrary DOM position) to be positioned right next to the element that needs the tooltip or context menu.

This positioning challenge is usually done with JavaScript (the cow paths have been laid), by way of getBoundingClientRect and doing various geometric math to make sure the element doesn’t wank off the edge of the browser or in any way become “data loss” as we like to say in CSS. More challenging that it seems. Letting CSS do it seems awfully nice.

CSS tends not to focus solutions on one exact need though, preferring instead to solve the problem conceptually with primitives that might solve lots of use cases. This is where Roman gets clever with things and makes examples like this connecting elements with pointing arrows (involving SVG):

But also some cool demos with a slightly more practical twist, like moving highlight menus:

Jhey Tompkins’ article on this, Tether elements to each other with CSS anchor positioning, covers things from first principles and is probably a better reference for the syntax. But Jhey being Jhey, there are some weird and clever demos as well, like this emoji finger form:

It’s a Pen, naturally.

There is a <meter> element in HTML, and Dana Byerly does a great job of showcasing it. It’s a natural fit for stuff like “You’ve uploaded 47 of your maximum 100 files” in a visually more understandable way. There is some accessibilty stuff to get right though, including using “fallback text” (the text within the element) which is used by some screen readers and will certainly be useful context. Free basic styling is nice:

Live tests as a Pen, naturally.

I like the term “CSS micro-framework” as coined here by Blake Watson.

• May include classes for building grids, components, etc. Typically limited, though, because of the next rule.
• Under 10kb minified and gzipped. I feel like you can’t claim “micro” or “lightweight” beyond 10kb.
• JavaScript is optional and is not supplied by the framework.

Examples:

• Pico: https://picocss.com/
• Spectre: https://picturepan2.github.io/spectre
• Milligram: https://milligram.io
• Skeleton: http://getskeleton.com/
• Picnic: https://picnicss.com/
• Pure: https://purecss.io/

They aren’t just a reset and they aren’t… Bootstrap. They aren’t necessarily “classless” either, which is a whole other category of framework that only styles things based on HTML selectors.

And then, another possible ending:

As we go deeper down the path of minimal CSS starters we end up at the logical conclusion—you might not need a framework at all.

I feel like y’all out there are like: ya know what I could use this week? A scattered collection of interesting links with light commentary about what is interesting about them or how they connect with the modern web zeitgeist. No worries gang, I got ya.

I like Josh’s take on all this coding + AI stuff and the fear of lost jobs. It’s terrible timing for all this because fricking tons of people are losing tech jobs in layoffs right now. But that isn’t because AI is taking their jobs, it’s economic fears, correcting overhiring mistakes, and some greedy “ooo look we can do mass layoffs and not get much flack for it because everyone is doing it”. Anyway here are some quotes from Josh’s article:

… since the beginning, there’s been a concern that web developers would be made redundant by some new technology. In the 2000s, it was WordPress. In the 2010s, it was Webflow. In the early 2020s, it was “no code” tools.

[on GPT-4 building simple website from napkin drawing] … we haven’t needed web developers to build these sorts of pages in decades. There is an enormous difference between this HTML document and the sorts of code front-end developers write today.

Code snippets are all over the internet, and are often generic. By contrast, every codebase is unique. There are very few large open-source codebases. How’s the AI supposed to learn how to build big real-world projects?

I actually think that this could increase the total # of developer jobs.

Certain tasks might be delegated to an AI, but not many jobs.

Normally I skip or roll my eyes at people’s hot takes on AI stuff since there is just so much of it right now, but again I think Josh’s takes here are smart. It’s also in agreement with most other takes I’ve read on this. Generally, people are writing articles trying to address people’s fear, but the fear seems a little invented.

A little accessibility back and forth!

• Ben Meyers: The Web Needs a Native .visually-hidden
• Scott O’Hara: Visually hidden content is a hack that needs to be resolved, not enshrined
• Dennis Lembree: We Don’t Need A Native .visually-hidden

I suppose the powers that be should listen to web accessibility experts over me, but I’m more inclined to agree with Ben here. The cowpaths are there, pave them.

Another back-and-forth took place last month between Alex Russell’s The Market for Lemons and Laurie Voss’ The case for frameworks. As much as I prefer to rate these arguments on the written word entirely, the fact is I know that both of these people are Very Big Web Personalities that both very much like to argue. Laurie for the most part brings baby-bear porridge to the party and I like that, but I also don’t mind Alex bringing down the hammer and taking hard-line stances on web performance, mostly because not a ton of other people do that and the web could use the pushback.

A good amount of web platform arguments end up being about JavaScript frameworks and the whole idea of SPAs. Probably no question we overdid it as an industry on the SPA thing. One side plot here though is that this was all happening during a time when the web was perhaps a bit more threatened by “native” apps than it is now. Native apps have a certain feel to them that is a bit different than web apps generally, and no small part of that is how they tend to animate their state and page transitions moreso than web apps do. SPAs made that far more possible than we were able to do on standard new-page-loading web apps.

Transitioning interfaces and page transitions in non-SPAs isn’t just sitting around waiting to be solved though. I think of three things:

1. Swup is a JavaScript library just for this stuff which is being actively developed. There is also Taxi.
2. Turbo looks still actively developed too, and while it’s not about transitions specifically, it’s about making a non-SPA behave like an SPA meaning you don’t need to change architectures but can still benefit from a page that never 100% reloads.
3. The biggest deal is still the View Transitions API which has just landed now in stable Chrome. No libraries needed. No SPA needed. Just straight-up animations between state and page changes in native JavaScript.

I mentioned the other week that Firefox fixed this old bug a bit related to drop caps, but really, or I guess in addition to that, the best thing that can happen to drop caps is the CSS initial-letter property. I should have linked up Stephanie Stimac’s article Greater styling control over type with `initial-letter` which digs into that and strongly makes the case.

Ethan Marcotte has a wonderful video showing how to do drop caps well, but it’s frustratingly complicated. Really looks like initial-letter is the answer to all this.

Lemme show off some cool SVG-related things this week. Gotta love SVG. It’s this graphics language built right into the web platform that has a ton of capability and is always right there waiting for us when we need it. Thanks the web!

Portability is a cool SVG feature. You can copy and paste a bit of SVG right into HTML and that’s not only functional but actually, a pretty good way to do it. That way you can style it freely and no additional network request is made.

Ya know… that’s how our icons feature works here on CodePen.

And it’s a decently common way to deliver UX on a set of SVG icons generally. For example, check out Monika Michalczyk’s Shapes project, where you can just click any of them and get all the code right on your clipboard. They paste into Pens really nicely, of course.

Or here’s Robb Knight’s Mac 30th Anniversary Icons which are super cool minimalist representations of Macs over the last many decades.

You can learn the SVG syntax. I guess that’s kinda obvious but maybe not to everybody as SVG is often the output of tools. You can export SVG from Figma and Illustrator and stuff and you didn’t have to learn the syntax, you just use the output.

Just SVG paths alone are fairly complicated and something of a sub-syntax. I wouldn’t say I know it super duper well, but I know enough that I wrote a guide a while back.

Some of the other attributes of SVG elements are a bit more straightforward like circle essentially has a central point at an X, Y coordinate and then a radius. Sébastien Noël has a new guide on fffuel that helps understand a lot of these syntaxes:

But leave it to yuanchuan (creator of css-doodle) to Experimenting [with] A New Syntax To Write SVG. It’s centered around the idea that the stylistic SVG attributes can be moved to a CSS-like syntax, which doesn’t just select and style SVG, but creates it.

OK I saved the best for last for you: Draw SVG rope using JavaScript (and it’s not just because there is an excellent CodePen demo) from Stanko Tadić. And not just rope like a line that maybe has some basic physics, but real-looking twisted rope, like the kind that might be holding a large ship to dock. The journey, which is excellently documented, involves really digging into the SVG APIs, doing interesting math, and knowing about fancy algorithms and stuff (see “Chaikin’s method” for rounding). I like it when you can tell someone is clearly captivated by an idea, gets it all figured out, then documents it so well the output and the explanation are equally interesting.

I love Henry’s guide: How to Make a Website.

There is precious little recent instructional material on how you can build a website, a perfectly great website, using just the raw materials of the web. Raw HTML & CSS, as it were. But that’s not all that Henry’s guide is about. It’s full of holistic advice going well beyond web design:

Be kind and curious and humble when you’re working with folks, and be extra forgiving of their mistakes, so when the time inevitably comes that you make your own, there’s perhaps some goodwill in the vault for you.

 🙏

I do suspect if it’s not just lack of awareness that you can build a website with just hand-written raw HTML and CSS, but more of a then what? situation. Of course, we’re hoping CodePen is a place where that is a good option and are working to make that better every day. But there are plenty of options for getting that locally crafted HTML website to a real website, like Vercel, Netlify, GitHub pages, etc, which all make it pretty decently easy. It would be unfortunate if the DevOps knowledge for getting websites to production is just as much knowledge as actually making websites.

Oh hey this makes me think of a great term thrown out by Robb Owen: Hand-thrown frontends. He compares the website-making process to the ceramics process of making a bowl out of clay.

So, for me, the frontend bowl-making process is a cyclical, non-linear one. On a surface-level it probably doesn’t seem like it’s as efficient as assembling Lego bricks to order, but over time you’ll make more bowls and each phase of iteration will gradually shorten as your skill increases towards mastery.

I’m a sucker for a good ceramics analogy as that’s what my Bachelor of Arts was focused on in college.

Oh! And speaking of Ceramics, have you seen Charlotte Dann’s Ceramics project? It’s probably my favorite generative art project I’ve ever seen. This surface is totally code-generated:

Oooooo tricky CSS challenge! Skewed Highlights. Vadim Makeev did up good:

You’d think transform: skew() would be involved somehow, but there isn’t a great opportunity for that, especially with arbitrary line breaks and such. Instead, the backgrounds are created with multiple gradient backgrounds (super clever) and fortunately box-decoration-break: clone; makes it look reasonable across lines.

Musing about slight alterations in CSS selector structure and how it affects selections? Sign me up for that party! Bramus compares:

.a .b .c { }
/* Versus! */
.a :is(.b .c) { }

They do look and behave similarly, but the former enforces that “c is a child of b is a child of a” situation solidly, while the latter allows for a situation where c is a child of a which is a child of b. That’s way too hard to understand in words, so here’s an image:

Admittedly I don’t reach for :is() all that much, but I suspect usage might go up a bit now that native CSS nesting is here and that all nested selectors must start with a symbol. So a quick way around wanting to nest element selector is wanking it in an :is():

header {
  h1 { } /* nope */
}

header {
  :is(h1) { } /* yup */
}

Let’s end with a little collection of developers looking forward to upcoming tech trends. This is, of course, popular in January and it’s March now but gimme a break I’m a little slow sometimes.

• The Viget gang wrote up What’s on the Horizon for UI and JS? and really it’s just a pile of links that does paint a pretty good picture of the hot topics in website buildin’ stuff. The first link is Rome which I’m cautiously optimistic about.
• Richard MacManus has got 2023 Web Tech Check-in: React Performance, PWAs, iOS Browsers. I’ve enjoyed Richard’s takes on web stuff in the last year or two. He brings a bit of journalistic flair to The New Stack that I’m a little envious of. . Is 2023 the year “the web finally breaks through on iOS?” I wish. 😬
• Robin Wieruch kicked out 10 Web Development Trends in 2023. Of all the trends I think serverless at the edge is my favorite (it’s good for everybody), but I did raise my eye a little at tRPC. If we’re gonna do TypeScript, and it seems like that ship has sailed, we might as well have tooling that does the type safety thing all the way up and down.
• Paul Armstrong: Things I want to see in JavaScript and Frontend development in 2023
• Ahmad Shadeed: The Guide To Responsive Design In 2023 and Beyond