paulo72 / Paul

Designer and Maker of digital things.

There are no people in paulo72’s collective.

Huffduffed (182)

  1. Keeping it simple with CSS that scales - Andy Bell

    This is the written version of my new talk, “Keeping it simple with CSS that scales”, which I first delivered at State of the Browser 2019.It’s a very long read, so I recorded an audio version, too:CSS has a weird place on the web today. There’s a lot of polarisation, with the opinion being seemingly split on “CSS sucks” and “CSS rules, learn it better, fools”.I empathise with the “CSS rules” camp and I’ll explain why: I have a theory as to why the “CSS sucks” camp have the attitude that they do. I think it’s a combination of them over-engineering their CSS, not fully understanding the power of CSS and finally, approaching it like it is a language like JavaScript and expecting it to work in the same way.What I’m going to do in this piece, is tackle the first bit and talk to you all about how we can simplify CSS to give us incredible power, while also being as low-tech as possible. The secret sauce is that most of the content isn’t actually about CSS, but that’ll all become clearer, later.Let’s talk about scaleI absolutely hate it when we use the term, “Scale”. I think we are stuck with it though, just like we are stuck with “JAMstack”, “Serverless” and “performant”.They’re all equally awful words, but one thing they do is create a common, recognisable construct for communication. As much as it pained me, it’s exactly why I named this talk “Keeping it simple with CSS that scales”. You probably knew before I even opened my gob that I’d be talking about working on massive codebases, which at some point in this talk, I’ll get to.One thing that I do get pissed off about with “Scale”, though, is that gets slightly muddied when people use it as an excuse to over-engineer something.Let’s take this common example. It usually gets said by some Bay Area tech bro:We use a CSS-in-JS library because our product needs to scaleLet’s be honest for a moment, folks: most of the tepid guff that these tech bros are making will only scale as far as the bin, so it’s not much of a valid excuse, is it?I’ll also be bold and straight-up say that I don’t think using scale as an excuse for over-engineering stuff—especially CSS—is acceptable, even for huge teams that work on huge products. Keep that in mind, because I hope, by the end of this session, you’re going to be in agreement with me.Four key thingsI think we can focus on four key things today, and for the rest of this piece, I’m going to run us through them in detail with a little progress thing, so you know roughly how much longer you have to endure me for.I could package this up as DCCS and really mop up the upvotes on that orange website, right?Anyway, let’s dive in.Don’t panic permalinkOne of my favourite books is The Hitchhiker’s Guide to the Galaxy. It’s about the earth being blown up to make way for a hyperspace highway and our main character, Arthur Dent proceeds to hitchhike around space with his alien guide, Ford Prefect.I know, that’s a proper rubbish synopsis, but you all didn’t come here to read me chatting about this book.The actual Hitchhiker’s Guide to the Galaxy is a sort of interactive encyclopaedia—well, interactive by 1979 standards…The thing that has always resonated with me about the encyclopaedia is on the cover it says: “Don’t Panic”. The phrase is used so many times throughout the story, even when the context very much calls for panic.I find myself really resonating with Ford Prefect, guiding Arthur Dent—a bumbling brit through the understandably mind-boggling adventure in space. Ford always approaches challenges in a calm, pragmatic way, just like the guide tells him to: “Don’t Panic”, and I think that’s a takeaway for us too.In fact, when Arthur first gets the book handed to him, he says:“I like the cover…‘Don’t Panic’. It’s the first helpful or intelligible thing any-body’s said to me all day.“Right, anyway, I digress…“don’t panic”. It’s such good advice because when we panic, we make silly mistakes. Think about it: how many horrendous CSS hacks have you made when you’re up against-it in a project and you just needed to get it done.A lot of people do it and it’s because we’re panicking. The deadline is looming and there’s no time to work out why our CSS is borked, so we throw !important at it until it’s fixed.This is fine: we all do it, but what isn’t fine is technical debt. Often panic goes beyond a little hack here-and-there and escalates into something much more serious, like employing a CSS-in-JS framework, which is the equivalent of taking out a Wonga loan to pay of your house mortgage.Incredibly high interest technical debt, which frustratingly, the developers who took it out, only pay a bit off, because that developer has probably already gone and got a new job. It’s mainly the user who takes the biggest hit, in terms of performance, and this boggles my mind when you consider what we have available to us with modern CSS.The current state of CSS permalinkReally, we’ve never had it better with CSS. We have CSS Grid with 93% support and Flexbox with 98.8% support. Approach using them with a safe progressive enhancement mindset and your layout is sorted. Job done. No worries.We also get CSS Custom Properties which are native CSS variables. They’re incredibly handy for tokenising our CSS. Because they are also affected by the cascade, we can can override them, contextually. This makes them useful for theming, algorithms and display modes, such as dark mode.:root {

    —primary: #8e8e8e;}.box {

    background: var(—primary);}.badge {

    color: var(—primary);}These are just a subset of powerful new features, but you can see how modern CSS is an incredibly powerful, effective styling tool. But it can come up a bit short, especially when you do have lots of CSS. So let's look at how we can deal with that.Sass for the win! permalinkAll of this native functionality is cool as heck, right? Let’s not forget native nesting too, but who does all of the work when we use that? Yep: the browser!In most cases, that’s fine, although the thought of native CSS terrifies me—especially when we are already kludging up the browser with heavy JavaScript frameworks.Basically, what I’m saying is we don’t have to abandon Sass because native language features are coming. It’s probably better to cautiously pre-compile your CSS and not force the browser to work as hard. It’s already working hard enough, re-rendering the DOM every time one piece of data changes (cough reactive frameworks cough), so why make it work harder just so you can have native nesting? It smells like developer experience over user experience to me.We rush to throw stuff in the bin without thinking about the wider implications. Yeh, we’ll get nesting soon, but how is a low-powered device going to handle 5 levels of nesting with chained selectors? How is a low-powered device going to handle calculating the colour of a Custom Property that has been overridden by the cascade 5 times? It doesn't matter how good the native tools are because if we keep throwing rubbish code at browsers, the users will suffer for it.The beauty of Sass is that you can have the best of both worlds. You get cool stuff like nesting, but if you do it right, you can get nice, flat selectors. You also get components and if you want, you can set your project up to get multiple bundles. You can also lint your CSS at build time, so you know when stuff is getting out of hand, right in your terminal or GUI.The most important thing is that with Sass—well, SCSS, you’re writing CSS still. SCSS is smart enough to just do what it needs to focus on and leave the rest of your CSS alone. To me, it feels like a pretty perfect setup.Communicate permalinkWe seem to be in an era where tools and methodologies are dreamed up to help avoid communicating with each other.Generated CSS class names is a classic example of this. It’s a very typical problem. Some might at this point start having an existential crisis, or dream of machine-generated classnames, but check this out: we’re going to try this novel thing called talking:Dev #1 - Lucrecia permalink“This component I came up with already exists. Let me have a quick look in git and see who created it. Ah, it was Isabella”Lucrecia to Dev #2, Isabella permalink“Hey, Dev Isabella, is there a reason why this component is called 'block'?”Isabella to Lucrecia permalink“Ah yeh, this very important reason. How about you call that component 'box' instead?”Now this important reason could be anything you dream up:A stakeholder decisionA legacy codebase issueA Design decisionImportantly, Isabella, a professional, who knows how to communicate effectively, comes up with an alternative.Lucrecia permalink“That’s a great idea. Thanks!”How wholesome was that?? It’s amazing what happens when we actually talk to each other.So-called “soft skills” which I prefer to call core skills are shunned in favour of being able to build your own linked-list or do fizz buzz on a whiteboard. This winds me up because to be an effective member of a team, you have to be able to communicate, whereas the only time you ever do fizz buzz in the real world is during that life-draining interview process…Documentation is everything permalinkAnother incredible way to communicate that’s not actual talking is writing. I love writing and you probably noticed, I do a lot of it… In fact, I write almost everything down because I never know when I might need it. It also helps me to commit stuff to memory.There’s a real value in writing everything down—especially in a large team of front-end developers, writing CSS—or any code, really. You can document your thought-process and explain how and why you’ve done things. You can write documentation, so if another developer picks up your code, they know what’s going on.By documentation, I don’t mean that you have to write reams and reams of structured docs: I’m talking goddamn comments in your code.Take this example:.card {

    background-color: #ffffff !important;}If I landed on this I would be like “What the heck is going on here?”How about this, though?.card {/* When this card is used in the legacy app, there is

    a collision between existing styles, so unfortunately we had to go nuclear. It’s certainly a refactor target. */

    background-color: #ffffff !important;}The same goes for most CSS frameworks to be honest. An example that gives me a heart attack is Tailwind CSS generates over 40 thousand lines of CSS by default (source). Bonkers.If you have a solid methodology like BEM, ITSCSS, SMACSS or even C-BEUT, you could sprinkle a bit of a grid system with, y'know GRID, add some layout helpers with flex and you are golden.This is the approach that we took with Every Layout—a book that I co-authored with my good pal, Heydon Pickering.For our layouts, we find the most robust solution by simplifying and distilling our problem. We then hint the browser, using axioms and rudiments, rather than micro-manage it to allow it to call the shots. This results in a very solid layout system that works upwards with progressive enhancement at the forefront.It’s been a really cool project and resonated with a lot of people, so go ahead and check it out.On the subject of progressive enhancement, gather around and take a knee for a moment, everyone.Don’t dismiss modern CSS because you have to support IE11.It’s a ridiculous mindset and it pisses me off whenever someone shares a cool trick on Twitter and a Chad will pop into the comments with “WhAt aboUt IE 11 tHOuGh”.Stop trying to pixel push your designs and instead, use progressive enhancement to create a sensible default that automatically improves where support is available.Take this example: we’ve got a good ol’ three column grid. In times gone by, we’d employ some hacks not just to lay it out, but also make it look like this in every browser.What I propose is that we take a step back, simplify the problem, and find a sensible baseline, and here it is: Good ol’ stacking with space. We can achieve 100% coverage with tiny amounts of CSS now.This is a handy little grid system that uses minmax to distribute columns. It means we get a responsive grid with no media {

    display: grid;

    grid-template-columns: repeat(auto-fill, minmax(16rem, 1fr));

    grid-gap: 1rem;}But, grid still isn’t quite full supported, but thanks to CSS’s nature, it’ll ignore stuff it doesn’t understand and move on, so we can add this below our grid > * {

    max-width: 25rem;

    margin-left: auto;

    margin-right: auto;}.auto-grid > * + * {

    margin-top: 1rem;}Now, thanks to @supports, we can reset some of that where there is support. If a browser supports grid, it supports @supports, so job done.It's 22 lines of CSS, with no hacks and works all the way back to IE9 (and probably beyond).See the Pen Progressively enhanced, media query-free grid by Andy Bell (@andybelldesign) on CodePen.Slow down permalinkThe last point on simplification and really, the last point of this presentation before I wrap up is “slow down”.Seriously, slow down. I know it’s hard when you are working sprint-to-sprint or on a massive project, but trust me, when shit hits the fan, just slow down.I came a cropper to this earlier in the year. I was working on a massive system/pattern library and we were hit with some early complications. What I should have done was stop, stepped back and put some critical thinking in place. But what I did instead was plough on through each sprint, each retro and each planning session until it got to the point where not slowing down had massive negative implications. I was cashing tech debt like I was earning air miles on it.We had two or three grid systems, some fluid type and some utility driven type that conflicted and a card component that was pretty much a website in itself. If I had slowed down and stepped back, I could have seen these problems, but I didn’t. So seriously, slow down and you will save so much time.I’ll leave you with this take-home advice: instead of moving fast and breaking things, move slowly and deliberately instead.You can watch me deliver this talk at State of the Browser 2019, here.You can see the slide deck from that presentation, here.


    Tagged with css scale

    —Huffduffed by paulo72

  2. Fireside Chat: Brian Eno

    Electronic music didn’t start with Brian Eno, but it was certainly never the same after him. On Roxy Music’s first two albums he helped make synthesizers and tape effects part of a rock lineup, pricking the ears of future synth-pop creators such as Human League. As a solo artist he forged a new genre, which he dubbed ambient music, before effectively becoming a one-man genre himself, lending touches to Genesis (where he’s credited with “Enossification”), John Cale, and David Bowie during his golden Berlin period. There wasn’t much in the way of experimental 70s music that wasn’t made a little odder by Eno’s touch. But that touch could also be a multiplatinum one, as he showed as a producer for U2 in the mid-80s and Coldplay 20 years later. In the 90s he created perhaps the most widely heard music of all: the six-second start-up sound for Microsoft’s Windows 95 operating system. Typically mischievous, he later let it be known that he’d created it on a Mac.

    (The token-tagged MP3 link this uses will probably expire at some point. You can listen to it at instead.)

    —Huffduffed by paulo72

  3. Brian Eno on Why Do We Make Art & What’s It Good For?: Download His 2015 John Peel Lecture | Open Culture

    Image by BBC Radio 6

    "Symphonies, perfume, sports cars, graffiti, needlepoint, monuments, tattoos, slang, Ming vases, doodles, poodles, apple strudels. Still life, Second Life, bed knobs and boob jobs" — why do we make any of these things? That question has driven much of the career (and indeed life) of Brian Eno, the man who invented ambient music and has brought his distinctive, at once intellectual and visceral sensibility to the work of bands like Roxy Music, U2, and Coldplay as well as the realm of visual art. Back in September, he laid out all the illuminating and entertaining answers at which he has thus far arrived in giving the BBC's 2015 John Peel Lecture.

    We featured Eno's wide-ranging talk on the nature of art and culture, as well as its utility to the human race, back when the Beeb offered it streaming for a limited time only. But now they've made it freely available to download and listen to as you please: you can download the MP3 at this link. You can also follow along, if you like, with the PDF transcript available here, which will certainly be of assistance when you go to look up all the people, ideas, works of art, and pieces of history Eno references along the way, including but not limited to the "STEM" subjects, Baked Alaska, black Chanel frocks, the Riemann hypothesis, Little Dorrit, Morse Peckham, Coronation Street, airplane simulators, the dole, Lord Reith, John Peel himself, Basic Income, Linux, and collective joy.

    If you haven't had enough Eno after that — and here at Open Culture, we never get enough Eno — have a look at and a listen to clips of a conversation he recently had with science writer Steven Johnson, all of which have an intellectual overlap with the Peel Lecture. The first deals with music, something this self-professed "non-musician" has done much more than his share of thinking about. The second has to do with punchlines, or rather, Eno's conception of a piece of art, not as a thing with value in and of itself, but as a kind of punchline on the order of "I used to have a car like that." (To hear its setup, you'll have to watch the video.)

    In the third, Johnson and Eno discuss an idea at the core of the Peel Lecture, Eno's famous definition of culture, and later art: "Everything you don't have to do." That covers all the aforementioned symphonies, perfume, sports cars, graffiti, needlepoint, monuments, tattoos, slang, Ming vases, doodles, poodles, apple strudels, still life, Second Life, bed knobs and boob jobs: "All of those things are sort of unnecessary in the sense that we could all survive without doing any of them," Eno says, "but in fact we don’t. We all engage with them." And if you want to know why we should keep engaging with them, and in fact engage with them more vigorously than ever, Eno can tell you.

    Related Content:

    Hear 150 Tracks Highlighting Brian Eno’s Career as a Musician, Composer & Producer & Stream His 2015 John Peel Lecture

    Jump Start Your Creative Process with Brian Eno’s “Oblique Strategies”

    Revisit the Radio Sessions and Record Collection of Groundbreaking BBC DJ John Peel

    Brian Eno Lists 20 Books for Rebuilding Civilization & 59 Books For Building Your Intellectual World

    Listen to “Brian Eno Day,” a 12-Hour Radio Show Spent With Eno & His Music (Recorded in 1988)

    When Brian Eno & Other Artists Peed in Marcel Duchamp’s Famous Urinal

    Prof. Iggy Pop Delivers the BBC’s 2014 John Peel Lecture on “Free Music in a Capitalist Society”

    Based in Seoul, Colin Marshall writes and broadcasts on cities and culture. He’s at work on a book about Los Angeles, A Los Angeles Primer, the video series The City in Cinema, the crowdfunded journalism project Where Is the City of the Future?, and the Los Angeles Review of Books’ Korea Blog. Follow him on Twitter at @colinmarshall or on Facebook.

    —Huffduffed by paulo72

  4. Radical Technologies - with Adam Greenfield | Virtual Futures Salon

    Virtual Futures presents leading technology thinker Adam Greenfield on his field manual to the Radical Technologies that are transforming our lives.

    We’re told that innovations—from augmented-reality interfaces and virtual assistants to autonomous delivery drones and self-driving cars—will make life easier, more convenient and more productive. 3D printing promises unprecedented control over the form and distribution of matter, while the blockchain stands to revolutionize everything from the recording and exchange of value to the way we organize the mundane realities of the day to day. And, all the while, fiendishly complex algorithms are operating quietly in the background, reshaping the economy, transforming the fundamental terms of our politics and even redefining what it means to be human.

    Having successfully colonized everyday life, these radical technologies are now conditioning the choices available to us in the years to come. How do they work? What challenges do they present to us, as individuals and societies? Who benefits from their adoption? In answering these questions, Greenfield’s timely guide clarifies the scale and nature of the crisis we now confront —and offers ways to reclaim our stake in the future.

    In coversation with Luke Robert Mason (Director, Virtual Futures).


    Original video:
    Downloaded by on Thu, 28 Dec 2017 23:55:34 GMT Available for 30 days after download

    —Huffduffed by paulo72

  5. Donald Hoffman: Do we see reality as it is? | TED Talk |

    Cognitive scientist Donald Hoffman is trying to answer a big question: Do we experience the world as it really is … or as we need it to be? In this ever so slightly mind-blowing talk, he ponders how our minds construct reality for us.

    —Huffduffed by paulo72

  6. Patterns Day: Laura Elizabeth

    Laura Elizabeth speaking at Patterns Day in Brighton on June 30, 2017.

    A one-day event for web designers and developers on design systems, pattern libraries, style guides, and components.

    Patterns Day is brought to you by Clearleft.

    —Huffduffed by paulo72

  7. Patterns Day: Ellen de Vries

    Ellen de Vries speaking at Patterns Day in Brighton on June 30, 2017.

    A one-day event for web designers and developers on design systems, pattern libraries, style guides, and components.

    Patterns Day is brought to you by Clearleft.

    —Huffduffed by paulo72

  8. Patterns Day: Sareh Heidari

    Sareh Heidari speaking at Patterns Day in Brighton on June 30, 2017.

    A one-day event for web designers and developers on design systems, pattern libraries, style guides, and components.

    Patterns Day is brought to you by Clearleft.

    —Huffduffed by paulo72

Page 1 of 19Older