Posts tagged “web”, page 6

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.

Paul Robert Lloyd:

Such notions of craftsmanship can soon lead us down a dangerous path, raising questions around elitism and discrimination. These are accusations you could level towards the IndieWeb. For all its promise of giving people the tools to regain ownership of their online identity and content, to do so fully and effectively requires a proficiency for coding and familiarity with an endless barrage of acronyms. Encouraging participants to selfdogfood only exacerbates the near-impenetrability and narrowness of this movement.

Rob Weychert chimes in and gets a strong +1 from me:

I’ve been making websites for 20 years. I read a bunch about how to set up webmentions and gave up before I started. 🤷🏻‍♂️ https://t.co/iIv1BgQXlY

— Rob Weychert (@robweychert) November 27, 2018

If even web people find it difficult, how can we ever manage to empower non-web people to produce web-like content?

Ben Callahan:

When you strip away all the stuff we do to try to control the experience of a website, it turns out the web is pretty darn accessible. It only breaks when we break it.

Dave Rupert:

Let’s say we have a site with ~300 third-party scripts all responsibly loaded as async, what would be the User Experience costs and risks?