{"id":373504,"date":"2022-09-23T08:13:36","date_gmt":"2022-09-23T15:13:36","guid":{"rendered":"https:\/\/css-tricks.com\/?post_type=newsletters&p=373504"},"modified":"2022-09-26T07:29:12","modified_gmt":"2022-09-26T14:29:12","slug":"298-all-aboard-the-acquisitions-train","status":"publish","type":"newsletters","link":"https:\/\/css-tricks.com\/newsletter\/298-all-aboard-the-acquisitions-train\/","title":{"rendered":"298: All Aboard the Acquisitions Train!"},"content":{"rendered":"\n

[Geoff:]<\/strong> The news that Adobe is acquiring Figma<\/a> produced typical knee-jerk reactions in both directions. I’m not here to add to the noise; you already know how you feel about it and my take isn’t any different than what you can already find in your Twitter timeline.<\/p>\n\n\n\n

One thing I’ll throw in, though, is how easy it is to feel something<\/em> when a new software acquisition happens. If the app you’ve come to rely on for your day-to-day work is one you’ve been using for years, you may very well be scared, angry, or sad about the passing of one era into another. That’s because an app \u2014 particularly one that’s as ubiquitous and widely used as Figma \u2014 is more than an app. It’s how you get things done, and that has an impact on everything from your daily routine to how confident you are in your work. It’s personal.<\/p>\n\n\n\n

But it’s also how our industry works. Companies are swallowing other companies all the time. In fact, some companies have an explicit goal to be acquired. Products swap hands so often that they are almost a currency in tech. Figma? That is roughly seven Beats acquisitions<\/a>. There’s been such a flurry of acquisitions in the WordPress space the past few years that someone designed a WordPress game of Monopoly<\/a>.<\/p>\n\n\n\n

So, those knee-jerk reactions? They’re gonna be the same no matter what \u2014 just swap Figma with another product and you’re sure to hear much of the same. It’s a good reminder of how fast things change and the danger of getting too personally attached to a product, tool, service, app, or whatever when it comes to our work.<\/p>\n\n\n\n

Let’s move on to some links!<\/p>\n\n\n\n\n\n\n\n

\n\n\n

Maybe HTML isn’t always the accessible choice<\/h2>\n\n\n

That’s the conclusion I arrived at after rounding up some recent chatter about the <details><\/code> element<\/a>. We often assume that native HTML elements are specced to be accessible out of the box, but that hasn’t been the case here. For one, it’s unclear whether <details><\/code> is a container or an interactive element as it has an implicit group<\/code> role, but is also defined as an interactive element. Speaking of which, <summary><\/code> is also defined as an interactive element, and nesting another interactive element in there \u2014 such as a link \u2014 is valid HTML even though it produces wildly different results in assistive tech.<\/p>\n\n\n\n

\"HTML
Wait, is that a link in the <summary><\/code> valid HTML?<\/figcaption><\/figure>\n\n\n\n

It appears that <details><\/code> is suffering both from issues with the spec and with how browsers have implemented it. This all reminds me that Dave Rupert warned us about the inaccessible parts of HTML<\/a> back in 2020.<\/p>\n\n\n\n

\n\n\n

A content warning component<\/h2>\n\n\n
\"\"<\/figure>\n\n\n\n

Speaking of <details><\/code>, I’m all about Kitty Giraudel<\/a> ‘s thought process for using it to hide potentially harmful or sensitive content<\/a>. It works without JavaScript. Styling is cosmetic rather than functional. Users can prepare themselves to either engage with the content or skip past it. What’s not to love? This is what I call a fantastic use case for <details><\/code> \u2014 without the accessibility #HotDrama to boot.<\/p>\n\n\n\n

\n\n\n

When is it OK to disable text selection?<\/h2>\n\n\n
\"\"<\/figure>\n\n\n\n

Another #HotDrama alert!<\/strong> We can prevent (but obviously not rule out) users from selecting text in CSS with user-select: none. But should we? David Schwarz identified a few use cases where it might make sense, including sites that publish content behind a paywall. That set off a blast of comments from folks arguing that disabling text selection is never OK because it merely annoys and confuses users \u2014 with some going so far as to call it “hostile” \u2014 not to mention they can disable it in DevTools anyway if they have some experience there.<\/p>\n\n\n\n

But not all comments were quite so dogmatic. Code examples with line numbers were one such example where it might make sense, as is an interactive game with otherwise selectable elements.<\/p>\n\n\n\n

\n\n\n

Drag and drop in CSS? Sure, there’s a way!<\/h2>\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

Temani Afif<\/a>‘s most recent article walks through the steps he took to create a nifty game<\/a> where you construct a puzzle out of actual pieces of an image by dragging them into place… all with HTML and CSS! His technique for dragging elements relies on a clever combination of styling the :active state of an element to change its dimensions with some visual and timing tricks using CSS transforms and transitions:<\/p>\n\n\n\n

.a {\n  width: 0%;\n  transition: 0s .2s; \/* add a small delay to make sure we catch the hover effect *\/\n}\n.box:active .a { \/* on :active increase the width *\/\n  width: 100%;\n  transition: 0s; \/* instant change *\/\n}\nimg {\n  transform: translate(200%);\n  transition: 999s 999s;\n}\n.a:hover + img {\n  transform: translate(0);\n  transition: 0s;\n}<\/code><\/pre>\n\n\n\n
\n\n\n
What’s new with forms in 2022?<\/h2>\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
Ollie Williams<\/a> has the scoop<\/a>, and it turns out there’s quite a bit, from full support for requestSubmit()<\/code> to prevent forms with validation errors from submitting to an inert<\/code> attribute for disabling an entire form. It’s good to see so much work being done to bring more cross-browser support to these sorts of features in the past year.<\/p>\n\n\n\n
Most of that support was completed when Safari 16 was released the other week<\/a>. That release is a big deal in its own right because it brings support for new features we’ve been clamoring for, like Container Queries<\/a> (*and units), CSS subgrid<\/a>, animatable grids, and Motion Path<\/a> among a crap-ton of other things worth checking out.<\/p>\n\n\n\n
\n\n\n
A beginner’s guide to JavaScript in the DevTools console<\/h2>\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
A nice little primer on working with JavaScript in the DevTools console<\/a>. It’s not so much that this tutorial covers any new ground, but I appreciate how Lisa Tagliaferri<\/a> assumes no experience whatsoever when showing how to navigate around DevTools and use JavaScript to manipulate the current page. There’s even a handy section that outlines other DevTools features that anyone new to web development will want to bookmark for future reference.<\/p>\n\n\n\n
\n\n\n
New in the CSS Almanac!<\/h2>\n\n\n
We’ve been hard at work adding more CSS properties and pseudo-selectors to the ol’ CSS-Tricks Almanac<\/a>. Here’s just a taste of what’s new in the last couple of months:<\/p>\n\n\n\n