Tags: css

856

sparkline

Monday, August 13th, 2018

The power of progressive enhancement – No Divide – Medium

The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.

A case study in applying progressive enhancement to all aspects of a site.

Progressive enhancement isn’t necessarily more work and it certainly isn’t a non-JavaScript fallback, it’s a change in how we think about our projects. A complete mindset change is required here and it starts by remembering that you don’t build websites for yourself, you build them for others.

Sunday, August 12th, 2018

Let’s serve everyone good-looking content

A terrific piece by Hidde, about CSS grid, but also about a much bigger question:

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.

Friday, August 10th, 2018

Creating the “Perfect” CSS System – Gusto Design – Medium

This is great advice from Lindsay Grizzard—getting agreement is so much more important than personal preference when it comes to collaborating on a design system.

When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM.

It’s all about the people, people!

Tuesday, August 7th, 2018

Coming to a browser near you - faster than ever before!

A great long-term perspective from Rachel on the pace of change in standards getting shipped in browsers:

The pace that things are shipping, and at which bugs are fixed is like nothing we have seen before. I know from sitting around a table with representatives from each browser vendor at the CSS Working Group how important interop is. No-one wants features to be implemented differently in browsers. This is what we were asking for with WaSP, and despite the new complexity of the platform, browsers rendering standard features in different ways is becoming increasingly rare. Bugs happen, sometimes in the browser and sometimes in the spec, but there is a commitment to avoid these and to create a stable platform we can all rely on. It is exciting to be part of it.

Friday, August 3rd, 2018

StyleURL - share CSS tweaks instantly

This is an interesting tool: mess around with styles on any site inside Chrome’s dev tools, and then hit a button to have the updated styles saved to a URL (a Gist on Github).

Tuesday, July 31st, 2018

CSS exclusions with Queen Bey

This great post by Hui Jing is ostensibly about CSS shapes and exclusions, but there’s a much broader message too:

Build demos, and play around with anything that seems remotely interesting. Even if that feature is in early stages, or only supported by 1 browser. And then talk about it, or write and tweet about your experience, your use cases, what you liked or disliked about it.

We can shape the web to what we want it to be, but only if we get involved.

The Accessibility of Styled Form Controls & Friends | a11y_styled_form_controls

A great collection of styled and accessible form elements:

Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.

How Do We Keep Up? What Happens if CSS Grid Changes? - YouTube

Another great video from Jen as part of her Layout Land series. This time she addresses the question of the overwhelming technology landscape for developers and where they should invest their time.

She references my most recent talk, where I’ve been drawing a distinction between “materials” (HTML, CSS, JavaScript) and “tools” (everything else).

What if CSS Grid Changes?

Friday, July 27th, 2018

Designing for Everyone: Building Great Web Experiences for Any Device

The slides and video from a really great well-rounded talk by Aaron, filled with practical examples illustrating concepts like progressive enhancement and inclusive design.

Friday, July 20th, 2018

Fractional. — Ethan Marcotte

Ethan’s ode to the fr unit in CSS grid.

Tuesday, July 17th, 2018

Should I try to use the IE version of Grid Layout? Revisited for 2018

Rachel follows up on my recent post about CSS grid in old IE with her thoughts.

As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.

Friday, July 13th, 2018

CSS grid in Internet Explorer 11

When I was in Boston, speaking on a lunchtime panel with Rachel at An Event Apart, we took some questions from the audience about CSS grid. Inevitably, a question about browser support came up—specifically about support in Internet Explorer 11.

(Technically, you can use CSS grid in IE11—in fact it was the first browser to ship a version of grid—but the prefixed syntax is different to the standard and certain features are missing.)

Rachel gave a great balanced response, saying that you need to look at your site’s stats to determine whether it’s worth the investment of your time trying to make a grid work in IE11.

My response was blunter. I said I just don’t consider IE11 as a browser that supports grid.

Now, that might sound harsh, but what I meant was: you’re already dividing your visitors into browsers that support grid, and browsers that don’t …and you’re giving something to those browsers that don’t support grid. So I’m suggesting that IE11 falls into that category and should receive the layout you’re giving to browsers that don’t support grid …because really, IE11 doesn’t support grid: that’s the whole reason why the syntax is namespaced by -ms.

You could jump through hoops to try to get your grid layout working in IE11, as detailed in a three-part series on CSS Tricks, but at that point, the amount of effort you’re putting in negates the time-saving benefits of using CSS grid in the first place.

Frankly, the whole point of prefixed CSS is that is not used after a reasonable amount of time (originally, the idea was that it would not be used in production, but that didn’t last long). As we’ve moved away from prefixes to flags in browsers, I’m seeing the amount of prefixed properties dropping, and that’s very, very good. I’ve stopped using autoprefixer on new projects, and I’ve been able to remove it from some existing ones—please consider doing the same.

And when it comes to IE11, I’ll continue to categorise it as a browser that doesn’t support CSS grid. That doesn’t mean I’m abandoning users of IE11—far from it. It means I’m giving them the layout that’s appropriate for the browser they’re using.

Remember, websites do not need to look exactly the same in every browser.

How to build complicated grids using CSS grid

A nice walkthrough of a CSS grid in production. I was surprised to see percentages used as units—I wonder if it would feel “cleaner” if they were converted to fr units?

CSS: A New Kind Of JavaScript | HeydonWorks

A bold proposal by Heydon to make the process of styling on the web less painful and more scalable. I think it’s got legs, but do we really need another three-letter initialism?

We waste far too much time writing and maintaining styles with JavaScript, and I think it’s time for a change. Which is why it’s my pleasure to announce an emerging web standard called CSS.

Tuesday, July 10th, 2018

Components and concerns

We tend to like false dichotomies in the world of web design and web development. I’ve noticed one recently that keeps coming up in the realm of design systems and components.

It’s about separation of concerns. The web has a long history of separating structure, presentation, and behaviour through HTML, CSS, and JavaScript. It has served us very well. If you build in that order, ensuring that something works (to some extent) before adding the next layer, the result will be robust and resilient.

But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:

Rather than separating concerns by languages (such as HTML, CSS, and JavaScript), we’re are working towards a model of separating concerns at the component level.

This echoes a point made previously in a slidedeck by Cristiano Rastelli.

Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?

There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.

In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:

Your starting point should always be well-structured markup.

This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.

That’s basically an application of starting with the rule of least power.

In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:

We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”

There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.

My point is this:

  • Separating structure, presentation, and behaviour is a good idea.
  • Separating an interface into components is a good idea.

Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.

Monday, July 9th, 2018

Solving Sol

Browser implementations of Sol LeWitt’s conceptual and minimal art, many of which only exist as instructions like this:

Vertical lines, not straight, not touching, covering the wall evenly.

Monday, July 2nd, 2018

Speaking my brains in Boston

I was in Boston last week to give a talk. I ended up giving four.

I was there for An Event Apart which was, as always, excellent. I opened up day two with my talk, The Way Of The Web.

This was my second time giving this talk at An Event Apart—the first time was in Seattle a few months back. It was also my last time giving this talk at An Event Apart—I shan’t be speaking at any of the other AEAs this year, alas. The talk wasn’t recorded either so I’m afraid you kind of had to be there (unless you know of another conference that might like to have me give that talk, in which case, hit me up).

After giving my talk in the morning, I wasn’t quite done. I was on a panel discussion with Rachel about CSS grid. It turned out to be a pretty good format: have one person who’s a complete authority on a topic (Rachel), and another person who’s barely starting out and knows just enough to be dangerous (me). I really enjoyed it, and the questions from the audience prompted some ideas to form in my head that I should really note down in a blog post before they evaporate.

The next day, I went over to MIT to speak at Design 4 Drupal. So, y’know, technically I’ve lectured at MIT now.

I wasn’t going to do the same talk as I gave at An Event Apart, obviously. Instead, I reprised the talk I gave earlier this at Webstock: Taking Back The Web. I thought it was fitting given how much Drupal’s glorious leader, Dries, has been thinking about, writing about, and building with the indie web.

I really enjoyed giving this talk. The audience were great, and they had lots of good questions afterwards. There’s a video, which is basically my voice dubbed over the slides, followed by a good half of questions afterwards.

When I was done there, after a brief excursion to the MIT bookstore, I went back across the river from Cambridge to Boston just in time for that evening’s Boston CSS meetup.

Lea had been in touch to ask if I would speak at this meet-up, and I was only too happy to oblige. I tried doing something I’ve never done before: a book reading!

No, not reading from Going Offline, my current book which I should encouraging people to buy. Instead I read from Resilient Web Design, the free online book that people literally couldn’t buy if they wanted to. But I figured reading the philosophical ramblings in Resilient Web Design would go over better than trying to do an oral version of the service worker code in Going Offline.

I read from chapters two (Materials), three (Visions), and five (Layers) and I really, really liked doing it! People seemed to enjoy it too—we had questions throughout.

And with that, my time in Boston was at an end. I was up at the crack of dawn the next morning to get the plane back to England where Ampersand awaited. I wasn’t speaking there though. I thoroughly enjoyed being an attendee and absorbing the knowledge bombs from the brilliant speakers that Rich assembled.

The next place I’m speaking will much closer to home than Boston: I’ll be giving a short talk at Oxford Geek Nights on Wednesday. Come on by if you’re in the neighbourhood.

Ampersand 2018 | Rob Weychert

Rob attended the excellent Ampersand event last Friday and he’s made notes for each and every talk.

Sunday, July 1st, 2018

Tuesday, June 26th, 2018

The Layouts of Tomorrow | Max Böck - Frontend Web Developer

A walkthrough of the process of creating a futuristic interface with CSS (grid and animation).

While this is just one interpretation of what’s possible, I’m sure there are countless other innovative ideas that could be realized using the tools we have today.