Tags: frontend

1348

sparkline

Friday, March 29th, 2019

City life | Trys Mudford

Not only does the differentiation of terms create a divide within the industry, the term ‘web app’ regularly acts as an excuse for corner cutting and the exclusion of users.

Straight-talkin’ Trys:

We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.

Benjamin Parry Home-brew

I love the way that Benjamin is documenting his activities at Homebrew Website Club Brighton each week:

Another highly productive 90 mins.

Homebrew website club is on every Thursday evening 6.00-7.30pm at Clearleft. You should come along!

CSS { In Real Life } | Building a dependency-free site in 2019

I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.

Thursday, March 28th, 2019

Responsible JavaScript: Part I · An A List Apart Article

As I pick apart yet another bundle not unlike a tangled ball of Christmas tree lights, it’s become clear that the web is drunk on JavaScript. We reach for it for almost everything, even when the occasion doesn’t call for it. Sometimes I wonder how vicious the hangover will be.

I love everything about this article and I can’t wait for part two.

What we tend to forget is that the environment websites and web apps occupy is one and the same. Both are subject to the same environmental pressures that the large gradient of networks and devices impose. Those constraints don’t suddenly vanish when we decide to call what we build “apps”, nor do our users’ phones gain magical new powers when we do so.

Needless to say, I endorse this message:

Whether you think of your site as an “app” or not, adding a service worker to it is perhaps one of the most responsible uses of JavaScript that exists today.

Monday, March 25th, 2019

Simple & Boring | CSS-Tricks

Let’s take a meandering waltz through what other people have to say about simplicity.

Stuffing the Front End

53% of mobile visits leave a page that takes longer than 3 seconds to load. That means that a large number of visitors probably abandoned these sites because they were staring at a blank screen for 3 seconds, said “fuck it,” and left approximately half way before the page showed up. The fact that the next page interaction would have been quicker—assuming all the JS files even downloaded correctly in the first attempt—doesn’t amount to much if they didn’t stick around for the first page to load. What was gained by putting the business logic in the front end in this scenario?

Friday, March 22nd, 2019

Who has the fastest website in F1? - JakeArchibald.com

I think I physically winced on more than one occassion as I read through Jake’s report here.

He makes an interesting observation at the end:

However, none of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.

Yes! This! Contrary to what you might think reading through the latest and greatest tips and tricks from the front-end community, the vast majority of sites out there on the web are not being built with React, Vue, webpack or any other “modern” tools.

All you need to know about hyphenation in CSS | Clagnut by Richard Rutter

Everything you need to know about hyphenation on the web today, from Rich’s galaxy brain.

Hyphenation is a perfect example of progressive enhancement, so you can start applying the above now if you think your readers will benefit from it – support among browsers will only increase.

Benjamin Parry Offline Homebrewing

Two of my favourite things: indie web and service workers.

This makes me so happy. I remember saying when my book came out, that the best feedback I could possibly get would be readers making their websites work offline. The same can be said for the talk of the book.

I Used The Web For A Day On Internet Explorer 8 — Smashing Magazine

A fascinating look at the web today with IE8. And it’s worth remembering who might be experiencing the web like this:

Whoever they are, you can bet they’re not using an old browser just to annoy you. Nobody deliberately chooses a worse browsing experience.

The article also outlines two possible coping strategies:

  1. Polyfilling Strive for feature parity for all by filling in the missing browser functionality.
  2. Progressive Enhancement Start from a core experience, then use feature detection to layer on functionality.

Take a wild guess as to which strategy I support.

There’s a bigger point made at the end of all this:

IE8 is today’s scapegoat. Tomorrow it’ll be IE9, next year it’ll be Safari, a year later it might be Chrome. You can swap IE8 out for ‘old browser of choice’. The point is, there will always be some divide between what browsers developers build for, and what browsers people are using. We should stop scoffing at that and start investing in robust, inclusive engineering solutions. The side effects of these strategies tend to pay dividends in terms of accessibility, performance and network resilience, so there’s a bigger picture at play here.

Wednesday, March 20th, 2019

Competing by mimicking - Andy Bell

In my mind, the only way to “compete” with native apps is to do better than native apps—and with the web platform consistently improving and enabling us to produce app-like experiences, with Service Workers, ES6+ JavaScript, modern CSS and Web Components: we are very much on the path to do better than native apps.

CSS custom properties in generated content

Cassie posted a neat tiny lesson that she’s written a reduced test case for.

Here’s the situation…

CSS custom properties are fantastic. You can drop them in just about anywhere that a property takes a value.

Here’s an example of defining a custom property for a length:

:root {
    --my-value: 1em;
}

Then I can use that anywhere I’d normally give something a length:

.my-element {
    margin-bottom: var(--my-value);
}

I went a bit overboard with custom properties on the new Patterns Day site. I used them for colour values, font stacks, and spacing. Design tokens, I guess. They really come into their own when you combine them with media queries: you can update the values of the custom properties based on screen size …without having to redefine where those properties are applied. Also, they can be updated via JavaScript so they make for a great common language between CSS and JavaScript: you can define where they’re used in your CSS and then update their values in JavaScript, perhaps in response to user interaction.

But there are a few places where you can’t use custom properties. You can’t, for example, use them as part of a media query. This won’t work:

@media all and (min-width: var(--my-value)) {
    ...
}

You also can’t use them in generated content if the value is a number. This won’t work:

:root {
    --number-value: 15;
}
.my-element::before {
    content: var(--number-value);
}

Fair enough. Generated content in CSS is kind of a strange beast. Eric delivered an entire hour-long talk at An Event Apart in Seattle on generated content.

But Cassie found a workaround if the value you want to put into that content property is numeric. The CSS counter value is a kind of generated content—the numbers that appear in front of ordered list items. And you can control the value of those numbers from CSS.

CSS counters work kind of like variables. You name them and assign values to them using the counter-reset property:

.my-element {
    counter-reset: mycounter 15;
}

You can then reference the value of mycounter in a content property using the counter value:

.my-element {
    content: counter(mycounter);
}

Cassie realised that even though you can’t pass in a custom property directly to generated content, you can pass in a custom property to the counter-reset property. So you can do this:

:root {
    --number-value: 15;
}
.my-element {
    counter-reset: mycounter var(--number-value);
    content: counter(mycounter);
}

In a roundabout way, this allows you to use a custom property for generated content!

I realise that the use cases are pretty narrow, but I can’t help but be impressed with the thinking behind this. Personally, I would’ve just read that generated content doesn’t accept custom properties and moved on. I would’ve given up quickly. But Cassie took a step back and found a creative pass-the-parcel solution to the problem.

I feel like this is a hack in the best sense of the word: a creatively improvised solution to a problem or limitation.

I was trying to display the numeric value stored in a CSS variable inside generated content… Turns out you can’t do that. But you can do this… codepen.io/cassie-codes/p… (not saying you should, but you could)

Monday, March 18th, 2019

The Lean Web video from Boston CSS | Go Make Things

A good talk from from Chris Ferdinandi, who says:

One of the central themes of my talk on The Lean Web is that we as developers repeatedly take all of the great things the web and browsers give us out-of-the-box, break them, and then re-implement them poorly with JavaScript.

HTML periodical table (built with CSS grid)

This is a nifty visualisation by Hui Jing. It’s really handy to have elements categorised like this:

  • Root elements
  • Scripting
  • Interactive elements
  • Document metadata
  • Edits
  • Tabular data
  • Grouping content
  • Embedded content
  • Forms
  • Sections
  • Text-level semantics

Friday, March 15th, 2019

BEM: 4 Hang-Ups & How It Will Help Your CSS Organization

A few common gotchas when using BEM, and how to deal with them.

Wednesday, March 13th, 2019

if statements and for loops in CSS - QuirksBlog

Personally, I find ppk’s comparison here to be spot on. I think that CSS can be explained in terms of programming concepts like if statements and for loops, if you squint at it just right.

This is something I’ve written about before.

The web we broke. — Ethan Marcotte

Like Eric, Ethan is feeling rightly glum about the state of accessibility on the web. But…

Right now, I’m trying to focus on this one question:

What’s one thing I wish I understood better about accessibility?

Accessibility Insights

A handy accessibility tool. The browser plug-in is only for Chrome right now (I use Firefox as my main browser) but it’s pretty nifty—the tool for visualising tabbing is really useful.

Fighting uphill | Eric Bailey

Eric is down about the current dismal state of accessibility on the web. Understandably so. It’s particularly worrying that the problem might be embedded into hiring practices:

Overwhelmingly, crushingly, we shove new developers towards learning JavaScript single page application frameworks (SPAs). While many of these frameworks pay lip service towards preserving accessibility, if you do your homework you find that the majority of them were built without assistive technology in mind.

But it’s not all doom and gloom. Eric also points to initiatives that could really help.

Still, this is a tough question to ask out loud:

What if we’re losing?

Unpoly: Unobtrusive JavaScript framework

This looks like it could be an interesting library of interface patterns.