Posts tagged “web”, page 6

Andy Bell:

It’s getting exhausting spending so much of my time defending one of the three pillars of the web: CSS. It should sit equal with HTML and JavaScript to produce accessible, progressively enhanced websites and web apps that help everyone achieve what they need to achieve.

Many people I meet think title texts, also known as tooltips, improve both the accessibility and usability of their sites. They don’t. In fact, they can even cause problems.

Painful. But at least human-readable?

Dave Rupert:

As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code.

Will these lists ever get shorter?

Jeremy Keith:

Now when we look at new things added to HMTL, new features, new browser APIs, what we tend to ask, of course, is: how well does it work?

How well does this thing do what it claims it’s going to do? That’s an excellent question to ask whenever you’re evaluating a new technology or tool. But I don’t think it’s the most important question. I think it’s just as important to ask: how well does it fail?

Nothing like a full hour of Jeremy Keith to get the year’s work started.

Jason Koebler:

There’s a subtext of the #deleteFacebook movement that has nothing to do with the company’s mishandling of personal data. It’s the idea that people who use Facebook are stupid, or shouldn’t have ever shared so much of their lives. But for people who came of age in the early 2000s, sharing our lives online is second nature, and largely came without consequences. There was no indication that something we’d been conditioned to do would be quickly weaponized against us.

Jeremy Keith:

Very soon, the vast majority of browsers will have an engine that’s either Blink or its cousin, WebKit. That may seem like good news for developers when it comes to testing, but trust me, it’s a sucky situation of innovation and agreement. Instead of a diverse browser ecosystem, we’re going to end up with incest and inbreeding.

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.

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.

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).

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.