skip to main content

Posts tagged “code”, page 2

  1. Relearn CSS layout: Every Layout

    Heydon Pickering and Andy Bell have created a terrific resource for CSS layout patterns following algorithmic design principles.

    We make many of our biggest mistakes as visual designers for the web by insisting on hard coding designs. We break browsers’ layout algorithms by applying fixed positions and dimensions to our content.

    Instead, we should be deferential to the underlying algorithms that power CSS, and we should think in terms of algorithms as we extrapolate layouts based on these foundations. We need to be leveraging selector logic, harnessing flow and wrapping behavior, and using calculations to adapt layout to context.

    This approach is precisely what I’ve been striving for ever since Jen Simmons’s Intrinsic Web Design talk from last year.

  2. Details / Summary Are Not [insert control here]

    Adrian Roselli:

    Once major browsers started supporting <details> & <summary> developers immediately started to play with them to see what sorts of patterns they could enhance or replace. This is a good thing. Experimentation pushes boundaries, improves understanding.

    However, we need to be careful of christening this new-to-us interaction as the solution to all our coding struggles.

  3. CSS masonry with flexbox, :nth-child(), and order

    Tobias Ahlin:

    On the surface it seems fairly easy to create a masonry layout with flexbox; all you need to do is set flex-flow to column wrap` and voilà, you have a masonry layout. Sort of. The problem with this approach is that it produces a grid with a seemingly shuffled and obscure order. Items will be (unbeknownst to the user) rendered from top to bottom and someone parsing the grid from left to right will read the boxes in a somewhat arbitrary order, for example 1, 3, 6, 2, 4, 7, 8, 5, and so on so forth.

    Flexbox has no easy way of rendering items with a column layout while using a row order, but we can build a masonry layout with CSS only—no JavaScript needed—by using :nth-child() and the order property.

    This is very clever — an actually helpful use of order that helps visual order more accurately follow source order.

    But there’s a catch: it requires a fixed height for the container — and it needs to be a magic number that’s taller than the tallest column. That unfortunately makes it not super resilient to content changes, limiting its usefulness.

  4. Split

    Jeremy Keith:

    Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

    So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

  5. Stuffing the Front End

    Bridget Stewart:

    How many features are built-in to a framework or library that your app doesn’t need yet (and may never need)? How much can you hold back from the package you send to the web? How dependent are these modules and bits of code on one another? To me, that sounds like a lot of analysis up front to pick apart a tool before I even write a single line of code to be truly productive. It is also the antithesis of Progressive Enhancement, which strives to start with the bare minimum necessary to make it work and build up from there.

  6. I ruin developers’ lives with my code reviews and I’m sorry

    Philipp Ranzhin:

    I was mad that, while I spent my nights learning F#, my daughter started calling everyone around “fathers”. And this guy, instead of getting better at his job, went home to his children. And I wanted to punish him.

    Because I do code review for self-identification. I don’t give a toss about the project or the code. I’m simply a madman who’s allowed to hurt people. I’m a psychopath with a licence to kill. An alpha male with a huge stick.

    When I realized that, I felt ashamed of myself.

  7. Managing Flow and Rhythm with CSS Custom Properties

    Andy Bell suggests using CSS Custom Properties together with Heydon Pickering’s lobotomized owl selector to manage vertical spacing. It’s an elegant solution that works well with the cascade:

    .flow {
      --flow-space: 1em;
    .flow > * + * { 
      margin-top: var(--flow-space);

    I’ve been experimenting with old-school margin collapsing for vertical rhythm this past year, in Cobalt. I’m a proponent of spacing being an inherent property that exists by default instead of something that has to be explicitly added. But margin collapsing doesn’t really play well with Grid layout (until we get something like margin-trim), so I might give this method a try.

  8. How do you figure?

    A deep dive into figure accessibility from Scott O’Hara:

    A figcaption is meant to provide a caption or summary to a figure, relating it back to the document the figure is contained within, or conveying additional information that may not be directly apparent from reviewing the figure itself.

    If an image is given an empty alt, then the figcaption is in effect describing nothing. And that doesn’t make much sense, does it?

  9. Deep dive CSS: font metrics, line-height and vertical-align

    Vincent De Oliveira:

    Line-height and vertical-align are simple CSS properties. So simple that most of us are convinced to fully understand how they work and how to use them. But it’s not. They really are complex, maybe the hardest ones, as they have a major role in the creation of one of the less-known feature of CSS: inline formatting context.

    No kidding, this stuff is complex.

  10. HTML, CSS and our vanishing industry entry points

    Fighting words from Rachel Andrew, defending the ease of learning HTML and CSS from scratch:

    Whether front or backend, many of us without a computer science background are here because of the ease of starting to write HTML and CSS. The magic of seeing our code do stuff on a real live webpage!

    Yes! The instantaneous feedback when editing HTML or CSS on a live webpage is, to me, one of the most important characteristics of the web as a medium. Having no layers of abstraction between creative input and final output is one of the web’s miracles.

    I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged. I have plenty of fight left in me to stand up against that.

    I couldn’t agree more. It really was the ease of getting started that got me into web development, and kept me away from native app development. Easy to learn, hard to master is a wonderful trait that the web should fight to keep.