Blog, page 5

Laura González:

In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.

Karen Olsson thinks about the importance of the many books she owns but will never read:

Perhaps in some cases it has actually meant more to me to possess a book than to read it, because as long as its contents remain unknown to me, it retains its mystery. The unread book is a provocation, a promise of something that might dissipate if I slogged my way through the text. I’ve read a little of Cave, City, and Eagle’s Nest: An Interpretive Journey Through the Mapa de Cuauhtinchan No. 2, a sumptuous art book about a 16th-century pictorial manuscript from Mexico […]. I keep this book around even though I don’t wish to make anything of it in a literal sense—I don’t want to write fiction or nonfiction or a nutty screenplay about a mesoamerican document, but I wish for it to somehow whisper in my ear while I write something not at all about the map, for its enigmatic presence to leave some ineffable trace.

I love this idea, and I must admit that I suffer from the same affliction. Design books, self-help books, nonfiction books… I want them to somehow transmit that “ineffable trace” to me just by virtue of sitting on my desk, mostly unread; no matter how many cookbooks I buy, it seems I always end up going to Serious Eats when I need a recipe.

I’m trying to read more by divorcing the physicality of owning a book from the process of reading it, so I bought an eReader. Now I get paper versions of the books I want to own, and digital versions of the ones I want to read. Totally normal, I know.

Eric Bailey posted a terrific list of principles that should be kept in mind when working on web accessibility.

Digital accessibility work is not easy, but it is vital. It is a holistic, multifaceted discipline that touches on multiple interconnected social and technological issues.

Craig Mod:

Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.

Chris Coyier’s latest talk puts all the complexity of modern front-end development in perspective:

All the very huge responsibilities front-end developers already have:

• Pulling of the design
• Making the design part of a system
• Making sure it is accessible
• Worrying about the performance
• Testing things across browsers
• Testing things across devices
• Sweating the UX

Oh hello, big pile of new responsibilities

• Component-driven design, designing our own abstractions
• Site-level architecture
• Routing
• Fetching our own data
• Talking to APIs
• Mutating data
• State management

Oof.

Charlie Owen:

The vast majority of respondents are still using Sass and vanilla CSS? Wow! This made me pause and think. Because I feel there’s an analogy here between that unseen dark matter, and the huge crowd of web developers who are using such “boring” technology stacks.

These developers are quietly building their sites and apps, day in, day out. But they are rendered invisible as they are not making use of the cutting-edge technologies that the 1% of the bleeding edge love to talk about.

They are the 99% of the web universe that is quietly getting on, not blogging about their technology stack, not publishing amazing new tooling. Simply building things.

Sass and not much else? It me. Though I am using some state-of-the-art tech like the fancy underlines made possible by CSS Text Decoration Module Level 4 😎

Megan Amram:

Men and women have completely different needs in the skin department. While a woman’s skin is soft like a dying flower and barely strong enough to keep her insides in, a man’s skin is thick like the door to a safe. We men need makeup that covers our hungry-boy blemishes and larger-than-average pores. There’s a reason they call those sewer things manhole covers—it’s because they’re thick like a man and big enough to cover a man’s holes (“pores”)!

Henry Sung:

What’s remarkable about vertical drama is that it’s not just any scripted content cropped for a vertical aspect ratio. These shows are specifically imagined for the mobile screen from the ground up. This is evident in three features they all share.

I am fascinated by vertical video — it feels like a completely different medium. To me, horizontal video always represents a very deliberate choice to “make a video.” Vertical video is much more spontaneous, like a long photo that lives on your phone.

Seeing the vertical format used for more serious scripted stuff is still uncanny, but I suspect there’s a lot to explore there.

Quinn Keast:

The Possibility Gap is a dark pattern that arises when a product takes advantage of unknown unknowns on the part of their users, as it relates to their understanding of what is possible in digital products today.

I’m linking to this just so I can go on the record on this here blog and say: motion smoothing is an abomination.

Evan Minto:

min() accepts one or more values and returns the smallest value. The magic of the function is that, just like calc(), the arguments can use different units, which allows us to return values that change dynamically based on context.

min() is one of three new comparison functions introduced as part of the CSS Values and Units Module Level 4. There’s also max(), which naturally does the inverse of min(). Finally clamp() is a convenience function that applies both a minimum and a maximum to a single value.

This is brilliant and I can’t wait until I can change my @supports queries from display: grid to min().

Dave Rupert:

Upgrading legacy applications was one of the usecases Vue was designed around. It means that developers can piecemeal upgrade bits of an application as necessary.

In my experience Angular, React, and a lot of other frameworks ultimately require you to go all in early and establish a large toolchain around these frameworks. Angular prescribes a lot with its amazing CLI. React on the other hand doesn’t prescribe anything, but requires you to self-assemble and wield a somewhat complex toolchain. But as Evan put it in his JSConf Asia talk, Vue sits in the middle of the “Cathedral and the Bazaar”. Vue has useful tooling, but it’s all optional and you can use only what you need. In some ways, Vue’s grafting capabilities really does make it seem like a jQuery replacement you can drop in to give your components superpowers as needed.

Mike Sherov:

In order to understand how best to kill IE11, we need to look back to how 2 previous versions of IE met their fate: IE6 and IE8. By examining the strategies employed to kill browsers, we can look at current efforts to sunset IE11. We can predict and evangelize for what may ultimately do it in, finally freeing the JS community from the burden of ES5.

Interesting historical analysis but I think that attempting to “kill” browsers is a misguided goal. I think the right way to move forward here is Oliver Williams’ idea of applying the “mustard cut” technique to all versions of Internet Explorer and serving those users just barebones (but useful) HTML and CSS.

A repository of styled and “styled” form control elements and markup patterns, and how they are announced by screen readers.

Kyle Wiens makes a great point:

[Dieter] Rams loves durable products that are environmentally friendly. That’s one of his 10 principles for good design: “Design makes an important contribution to the preservation of the environment.” But Ive has never publicly discussed the dissonance between his inspiration and Apple’s disposable, glued-together products.

When a single broken key requires replacing a laptop’s entire top case, there is no denying that Apple has given too little consideration to the durability of its products.

I’m extremely curious to find out how (if?) Apple’s design philosophy will change with Ive gone.

Adrian Roselli:

What we know is that native and custom calendar controls are often a problem for users and applied where they are not needed. Before dropping the code on a screen as a matter of habit, consider if it genuinely helps the user or just your workflow.