All Posts, page 20

Ben Thompson:

Still, as a thought experiment, suppose Congressman Smith were right, and that Google’s search results, whether via managerial decree, general employee bias, or rogue employee, were gamed to disfavor Conservatives. The solution seems clear: create a competitor to serve the part of the market that is dissatisfied with Google.

The issue, of course, is that Google is, at least for a while (and more on this in a bit), impregnable: the company is an Aggregator with positive feedback loops everywhere.

Dave Rupert:

But in the past we had browser disparity as a mechanism for delaying bad ideas from becoming ubiquitous so they could be hashed out in a Web Standards body. Some of the best ideas we have today, like CSS Grid, were pioneered in one browser (IE10) and then polished in a Working Group. If V1 of -ms-grid was now the de facto standard, we’d have some regrets.

John Gruber:

There have always been bad Mac apps. But they seldom achieved any level of popularity because Mac users, collectively, rejected them.

Brad Frost:

I’m confident developers will get their heads around it. They’ll figure out their swim lanes and understand which JavaScript does what. I’m more concerned about other team members who are now staring at a Big Ol’ Intimidating Ball O’ JavaScript. And I’m concerned for those recruiters and hiring managers who are even further removed from the day to day. Those job listings with a giant spray of buzzwords and technologies can now be winnowed down to a single word: JavaScript. Those recruiters have a hard enough time separating Java from JavaScript, so best of luck to them making sense of the complex JavaScript ecosystem.

Jeremy Keith:

It’s not that CSS in inherently incapable of executing complex conditions. Quite the opposite. It’s precisely because CSS selectors (and the cascade) are so powerful that we choose to put guard rails in place.

On the news of Edge switching to the Chromium engine, Tim Kadlec writes:

We need Google to keep pushing the web forward. But it’s critical that we have other voices, with different viewpoints, to maintain some sense of balance. Monocultures don’t benefit anyone.

Hear, hear.

Christine Dodrill:

What? The code for that? It’s obvious, figure it out.

See? Five times as fast. Who cares that you have to throw out basically all your existing stuff, and if you mix rilkef and non-rilkef you’re gonna run into problems.

I’ve been taking a lot of interest in this topic ever since I started working on my own reset/boilerplate — Cobalt.

Heydon Pickering:

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well. This has two adverse effects:

1. Poor quality code
2. A bunch of people who can (and would enjoy!) expertly writing that code, standing unemployed on the sidelines muttering “WTF”

I so very much agree with everything Heydon says here. And that agreement comes from the experience of trying to become a full stack dev myself (though going at it from an HTML/CSS-first perspective).

Graphic design work on Incredibles 2 was brilliant, as expected. But there was one glaring exception, conspicuously missing from this post: the atrocious Edna Mode logo.

Arun Venkatesan:

During my research process, I noted down the keywords used to describe some of the typefaces. As I read through the list, the same words kept coming up over and over: friendly, modern, clean, simple, human. It’s like everyone wants something that they can use to define their brand, yet they really just want a slightly different version of what everyone has.

Ethan Marcotte:

Let me start by saying I generally avoid terms like “mobile,” “tablet,” and “desktop” in my work. It’s not that they’re bad; it’s because they’re broad. In my experience, terms like these confuse more than they clarify. Ask a roomful of clients or stakeholders to define “mobile,” and you’ll get a roomful of slightly different responses.

What I think is helpful, though, is breaking down the specific conditions or features that’ll cause our designs to adapt.