HTML


Recently, I came across the following post on Twitter:

<TwitterTweetEmbed
  tweetId={'1108290606458175489'}
/>

It became known as the _Impossible Layout_ with many concluding that it couldn't be done with just CSS. Of course, I had to tackle it. In the end I came up with 2 solutions. One is a pure CSS solution, but it has a relatively minor caveat and the other requires a bit of JS, but no caveats.

## Solution 1 - Pure CSS

Looking at the layouts I saw there were three uniformly-sized images and an arbitrary amount of text. I also know that all the elements involved are siblings of each other and not three containers each with their distinct image and text, otherwise, the larger layout wouldn't be workable. And since the items are all siblings and I need to move things in 2 dimensions that I will be needing CSS Grid at some point.

Let's elaborate on that last point.

Going back to the small layout, everything is in a single column and intermixed. On the large layout, there are clearly two columns with the text on one side and images on the other. So that explains needing to manipulate the elements in one direction, horizontally. Also on the large layout, the text all sits snug together without large breaks between them where an image used to be so that means Ii'll need to move them vertically as well. And if you're working with two dimensions in CSS, then you're likely to be wanting CSS Grid to keep things tidy.

To begin, let’s create our grid container and move everything in it to the second column. And then move just the images over to the first column.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - CSS Grid only"
  src="//codepen.io/arkmuntasser/embed/eXboKv/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/eXboKv/">
    Impossible Layout - CSS Grid only
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

Now we're getting somewhere! This is starting to look like the large layout we want, but there are rows between the images when they should be immediately under each other and the height of the images are causing the rows to be too tall in some instances.

To fix this, we're going to set the `position: absolute` on the images. This will allow the text on the right to sit comfortably without the images effecting the row height. But with now the images are stacked on top of one another.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - CSS Grid + Absolute Positioning"
  src="//codepen.io/arkmuntasser/embed/MxZRZJ/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/MxZRZJ/">
    Impossible Layout - CSS Grid + Absolute Positioning
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

This is where the caveat comes in with this method. Because I am assuming the images are uniform in size, I can translate the images reproduce the desired layout. For this, I am also going to assume that you as the developer or the CMS have some way of knowing how many images there are and which number each image is. Why? So we can set an inline CSS variable (CSS Custom Property) on the images. This will let us write a very simple rule in our CSS to enable support for an arbitrary number of images.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - CSS Grid only"
  src="//codepen.io/arkmuntasser/embed/YgdMgd/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/YgdMgd/">
    Impossible Layout - CSS Grid only
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

Finally, we can add a little extra CSS for some better styling and a media query go back to the small layout.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - Final"
  src="//codepen.io/arkmuntasser/embed/YgdbKg/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/YgdbKg/">
    Impossible Layout - Final
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

And you're done!

![](https://cdn.glitch.com/2caac55b-1244-4a5a-9e9c-6389d180ccf7%2Ftenor.gif?1553317759077)

## Solution 2 - What about images of varying sizes?

Not quite.

What if you want to have images of different sizes? Or what if you can't know how many images there are or the index of each image? Then we're going to need a little JavaScript to help out.

What we need to do is find every image in the grid and as we loop over them keep a rolling sum of their heights and set a CSS variable on the images with the current height total. Then in our CSS we can simple translate the image by that amount.

<iframe
  height="265"
  style={{ width: "100%" }}
  scrolling="no"
  title="Impossible Layout - Solved!"
  src="//codepen.io/arkmuntasser/embed/PLXvWP/?height=265&theme-id=dark&default-tab=html,result"
  frameBorder="no"
  allowtransparency="true"
  allowFullScreen={true}
>
  See the Pen{" "}
  <a href="https://codepen.io/arkmuntasser/pen/PLXvWP/">
    Impossible Layout - Solved!
  </a>{" "}
  by Amir R Muntasser (
  <a href="https://codepen.io/arkmuntasser">@arkmuntasser</a>) on{" "}
  <a href="https://codepen.io">CodePen</a>.
</iframe>

With this, you can have an indefinite number of images, an indefinite amount of text, and images of varying sizes. Not so impossible after all.


How I Solved the Impossible Layout


Sometimes you just need a element to shrink or grow in height proportionally with the width. Some tags will naturally do this like the `img` tag or `video` tag, but sometimes you need this functionality on something like a `div`. For example, you might be lazy loading an image, but want to reserve the space of the image so content doesn't jump when the image loads in.

We can do this using a handy trick of padding. If you give an element a top or bottom padding with a percent value that percent will be in relation to width of the elements parent. Let's take a look at an example to get a better idea of what that means.

Consider the following:

<Code language="html">
{`<style>
  .parent {
    width: 400px;
  }\n
  .child {
    padding-bottom: 50%;
    height: 0;
    background-color: tomato;
  }
</style>\n
<div class="parent">
  <div class="child"></div>
</div>`}
</Code>

Here we have an element called `.parent` with a width of 400px and an element called `.child` with a bottom padding of 50%. When this renders the browser will resolve the bottom padding to 200px because that's what 50% of 400px (the width of the parent element) is. This results in the child element having an aspect ratio of 2:1. But you may be wondering why I set the height to 0 on the child element.

By default, a `div` will have a height to fit its contents; I want to make sure the height of the element is being only determined by my bottom padding and the quickest way to do that is to set the height to 0.

Now that we've made a box with an aspect ratio, let's do something more practical like reserving space for a lazy-loading image.

<Code language="html">
{`<style>
  .post {
    width: 400px;
  }\n
  .post .img-wrapper {
    position: relative;
    padding-bottom: calc(600 / 800 * 100%);
    height: 0;
  }\n
  .post .img-wrapper img {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
  }
</style>\n
<article class="post">
  <div class="img-wrapper">
    <img data-src="/path/to/image.jpg" alt="..." />
  </div>
  <h3>Hello, World!</h3>
  <p>Check out my super cool internet website for online enjoyment...</p>
</article>`}
</Code>

Here we have an bit of content with an image, title, and some body content. In this scenario, my image that I'm using has dimensions 800x600 and I'm using those dimensions to define bottom padding percentage of the `.img-wrapper`.

<Code language="css">
{`.post .img-wrapper {
  padding-bottom: calc(600 / 800 * 100%);
}`}
</Code>

In this case, I could have just set the bottom padding to 75%, but I find using the dimensions of the image in a `calc()` makes things very clear and readily update-able if my image aspect ratio ever needs to change. You'll also notice that we're absolutely positioning the `img` element; we have to do this because the `.img-wrapper` is being entirely filled with padding leaving no room for the `img` to sit in naturally. Absolutely positioning the `img` lets us place it in the top-left corner of the `.img-wrapper` and stretch it fill the available width and height.

All that is left to do is to lazy load in the image when it comes into the viewport. To do that, we can use an [Intersection Observer](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API) which will be a topic for a future post.


How to Give an HTML Element an Aspect Ratio


One of the most annoying things on the web is when a dropdown opens on hover and you move the most diagonally into the dropdown, but in doing so the dropdown disappears because I stopped hovering over the zone that triggers the dropdown to appear. There's a couple ways to go about this including this [awesome SVG-based solution from Hakim El Hattab](https://team.slides.com/hakimel/cssday-2019#/).

My go to method, however, is to use a little bit of animation.

- [View Demo App](https://better-dropdown.glitch.me/)
- [Download Source Code on GitHub](https://github.com/arkmuntasser/better-dropdown)

What I particularly like about this method is that it doesn't require any JavaScript to implement. All you need is the right markup and a bit of CSS.

## Prerequisites

- Working knowledge of [HTML and CSS](https://internetingishard.com/html-and-css/)
- Basic knowledge of [CSS transitions](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions)

## The Big Idea

Conceptually, we're not doing anything too dissimilar than what Hakim is doing with his solution. What we're after is an extended hoverable area going from our trigger point to our menu. To do this, we create have an invisible dropdown helper element that is the width of the dropdown and the height of the trigger area and we place it over trigger area.

In the demo app, if you hover over the the word "dropdown" you'll see a red rectangle appear: this is our dropdown helper. As you move off the word "dropdown" you'll notice the red area starts shrinking downward toward the menu.

What this results in is a time limit in which you can move diagonally from the trigger point to the dropdown. As you move horizontally, the valid hoverable area shrinks vertically, this gives us our triangular area to move in. And because the easing isn't linear, we actually get a nice curve like in Hakim's solution that is a lot more natural to work in.

So that's the idea, but what does the code actually look like?

## The Code

Here is what the markup looks like for this dropdown.

<Code language="html">
{`<div class="nav-section">
  <div class="nav-section-title">Dropdown</div>
  <div class="dropdown-helper"></div>
  <div class="nav-section-dropdown">
    <a href="#" title="link">Link</a>
    <a href="#" title="link">Link</a>
    <a href="#" title="link">Link</a>
    <a href="#" title="link">Link</a>
    <a href="#" title="link">Link</a>
    <a href="#" title="link">Link</a>
    <a href="#" title="link">Link</a>
    <a href="#" title="link">Link</a>
    <a href="#" title="link">Link</a>
  </div>
</div>`}
</Code>

And here's the CSS that handles the making the dropdown visible on hover.

<Code language="css">
{`.header .nav-section-dropdown {
  display: none;
}\n
.header .nav-section:hover .nav-section-dropdown {
  display: grid;
}`}
</Code>

By default, the dropdown is not shown and when we hover over anything in the `.nav-section` we show the dropdown. That's the setup, let's take a look at the animation.

First, we define the initial state of the dropdown helper and how it's animation is going to work.

<Code language="css">
{`.header .dropdown-helper {
  transform: scaleY(0);
  transform-origin: bottom center;
  transition: transform 300ms ease 200ms;
}`}
</Code>

By default, we want to this to essentially not exist but we want it readily animatable. To do this, we set the Y scale to 0.

We also want this to animate downward so we need to set the transform origin accordingly.

And last, we set the transition we want. I find having a slight delay of about 200ms gives a much better feel to the whole effect, but you might find you need or want to adjust these numbers for your needs and taste.

Next, we need to make the helper full scale on hover.

<Code language="css">
{`.header .nav-section-title:hover + .dropdown-helper {
  transform: scaleY(1);
  transition: none;
}`}
</Code>

There are 2 things to note here:

1. The hover is **not** on the `.nav-section` itself, but instead on the `.nav-section-title`. We're also using the immediate sibling selector to target the helper. This is because the dropdown is closed, the title is essentially the entire valid trigger area and it's also what the user will be hovering off of to get into the dropdown.

2. The transition is set to `none` when the title is hovered. We don't want the helper to animate in, because if the user is moving quickly, they may trigger the animate out animation before the helper has fully animated in which would likely break the effect. So we remove the transition and have the helper instantly blink to full size.

Now when we move away from the title, the animation will begin and the user can move diagonally into the dropdown.

Finally, there's one last thing to take care of.

<Code language="css">
{`.header .nav-section-title {
  position: relative;
  z-index: 2;
}`}
</Code>

We want to make sure that the title sits above the helper so we don't accidentally cause the helper to animate out early.

Altogether, we get this:

<Code language="css">
{`.header .dropdown-helper {
  transform: scaleY(0);
  transform-origin: bottom center;
  transition: transform 300ms ease 200ms;
}\n
.header .nav-section-title:hover + .dropdown-helper {
  transform: scaleY(1);
  transition: none;
}\n
.header .nav-section-title {
  position: relative;
  z-index: 2;
}`}
</Code>

It's a little extra CSS, but the effect goes a long way toward providing a better user experience. And I'm personally happy when I can get a win like this without needing to add more JavaScript to a site.

That said, do also check out Hakim's method. There are many ways to tackle a problem and just as many contexts in which a particular solution is best. The only truly wrong way to go about it, is to not try to provide an optimal experience for your users.


How to Improve Dropdown Navigation with Animation

Drop caps can present a unique challenge for accessibility. It may seem like a simple enough design feature to implement on a site, but given that the [CSS for actual drop cap support](https://developer.mozilla.org/en-US/docs/Web/CSS/initial-letter) is presently only implemented in Safari we have to get a bit hacky.

Consider the following design I recently implemented for a client.

![Example of a drop cap](/images/drop-caps-example.png)

The outline styling you see here had been used through out the site, so I already knew how I was going to be tackling that. To produce that effect, I used this CSS:

<Code language="css">
{`.outlined {
  -webkit-text-stroke: 1px #46348a;
  color: transparent;
}`}
</Code>

I'll start by saying that I'm not totally pleased with this solution as it seems to result in slightly fuzzy text. Ideally, I would have prefered if the font family had a style that was an outline or if I could have had SVGs that would have been good too. But with the time constraints of the project this was what I had to do.

With that in place, I had to figure out how I was going to style the first letter of the first paragraph. My first attempt was to do this:

<Code language="css">
{`p:first-child:first-letter {
  -webkit-text-stroke: 1px #46348a;
  color: transparent;
}`}
</Code>

But that didn't work. Turns out that `-webkit-text-stroke` doesn't play well with pseudo-selectors. Which meant I needed to apply the stroke to an element that had just the first letter which in turn means I needed to modify the HTML coming out of the CMS.

<Code language="html">
{`
<p>Lorem ipsum dolor sit amet.</p>\n

<p><span class="outlined">L</span>orem ipsum dolor sit amet.</p>`}
</Code>

Now I could style the firslt letter directly and I was able to get the desired look. Success!

Except it's totally inaccessible. For anyone using a screen-reader to read the page will hear "L-orem" instead of "Lorem". To rememdy this we're going to need a bit more HTML and some ARIA attributes.

<Code language="html">
{`<p>
  <span class="first-word">
    <span class="sr-only">Lorem</span>
    <span aria-hidden="true"> <span class="outlined">L</span>orem </span>
  </span>
  ipsum dolor sit amet.
</p>`}
</Code>

Let's break this down.

Instead of grabbing just the first letter, I'm now grabbing the entire first word because that's what we're breaking for assistive technologies. We then put the word in an unbroken state with the class of `sr-only` which hides it visually, but still makes it availed to be read by screen readers. That solves screen readers speaking the word properly.

Next we add the first word again with the first letter separated out as we had previously done, but the add `aria-hidden="true"` to the entire word. This creates a word the visual treatment we're looking for, but hides it from screen readers.

Accessibility is paramount when building on the web and seemingly simple things like drop caps can be an accessibility foot-gun.

Making Accessible Drop Caps

CSS Frameworks like Bootstrap, Foundation, and Bulma help us describe our HTML in terms of layout structure and components, but I'm not a fan of that approach.

I prefer an approach I learned from [Jen Simmons](https://www.youtube.com/watch?v=qNtJ5p3h2A4) where HTML is used to describe the actual content of the page. Layout doesn't ever factor into it. After all, it is _markup_ so it should be used to add semantic meaning to your content. But aside from this philosphical interpretation there are other reasons to not bake layout into your HTML.

A big one is there are fewer `div`s cluttering up the DOM which can improve performance. And it also results in cleaner looking code since there are fewer utility-classes in the HTML (though this last one is subjective as frameworks like [Tailwind CSS](https://tailwindcss.com/) make a reasonable argument for more of these utility-classes in your HTML).

- [View Demo App](https://ui-playground-grid-demo.glitch.me/)
- [Download Source Code on GitHub](https://github.com/arkmuntasser/css-grid-demos)

## Prerequisites

- Working knowledge of [HTML and CSS](https://internetingishard.com/html-and-css/)
- Familiarity with [Responsive Web Development](https://www.smashingmagazine.com/2011/01/guidelines-for-responsive-web-design/)

Let's consider this following layout:

![](https://res.cloudinary.com/arkmuntasser/image/upload/c_scale,f_auto,q_80,w_800/v1564885707/PixelSnap_2019-08-03_at_19.21.49_2x.png)

Using Foundation, I might write some HTML like this:

<Code language="html">
{`<section class="articles">
  <div class="row">
    <div class="columns large-8">
      <div class="row">
        <div class="columns large-6">
          <article></article>
        </div>
        <div class="columns large-6">
          <article></article>
        </div>
      </div>
    </div>
    <div class="columns large-4">
      <article></article>
      <article></article>
    </div>
  </div>
  <div class="row">
    <div class="columns large-8">
      <article></article>
    </div>
    <div class="columns large-4">
      <article></article>
    </div>
  </div>
</section>`}
</Code>

This is fine, but what is this thing? Really? It's just a list of articles, right? So shouldn't the HTML just look like this:

<Code language="html">
{`<section class="articles">
  <article></article>
  <article></article>
  <article></article>
  <article></article>
  <article></article>
  <article></article>
</section>`}
</Code>

That's a lot cleaner looking and a lot more descriptive of the content we have. But now that we've gotten rid of the layout, how do we add it back in? That's where CSS Grid comes in!

<Code language="css">
{`.articles {
  display: grid;
  grid-template-columns: 5fr 5fr 4fr;
  grid-template-rows: repeat(6, 7vw);
  grid-gap: 1rem;
}\n
.articles article {
  grid-column: span 1;
  grid-row: span 3;
}\n
.articles article:nth-child(3) {
  grid-row: span 1;
}
.articles article:nth-child(4) {
  grid-row: span 2;
}
.articles article:nth-child(5) {
  grid-column: span 2;
}`}
</Code>

That's it! That's all the CSS that you need to recreate the layout. I find this to be far easier to read than the framework-based solution above.

So now we've cleaned up our HTML and more accurately and concisely describe the actual content we have and we we're able to move our layout logic into just a few lines of CSS. But we haven't even gotten to the best part!

Because we're now handling layout in the CSS, we can take our simplified HTML and display it nearly anyway that we want without altering it!

What if we change our CSS to this:

<Code language="css">
{`.articles {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  grid-template-rows: repeat(18, 6vw);
  list-style: none;
}\n
.articles article:nth-child(1) {
  grid-column: 1 / span 2;
  grid-row: 1 / span 3;
}
.articles article:nth-child(2) {
  grid-column: 2 / span 2;
  grid-row: 3 / span 3;
}
.articles article:nth-child(3) {
  grid-column: 1 / span 2;
  grid-row: 5 / span 3;
}
.articles article:nth-child(4) {
  grid-column: 2 / span 2;
  grid-row: 7 / span 3;
}
.articles article:nth-child(5) {
  grid-column: 1 / span 2;
  grid-row: 9 / span 3;
}
.articles article:nth-child(6) {
  grid-column: 2 / span 2;
  grid-row: 11 / span 3;
}`}
</Code>

And get this:

![](https://res.cloudinary.com/arkmuntasser/image/upload/c_scale,f_auto,q_80,w_800/v1564885707/PixelSnap_2019-08-03_at_19.22.39_2x.png)

Or maybe we want something a little wilder?

<Code language="css">
{`.articles {
  display: grid;
  grid-template-columns: repeat(5, 1fr);
  grid-template-rows: repeat(3, 19vw);
}\n
.articles article {
  grid-column: span 1;
  grid-row: span 1;
}\n
.articles article:nth-child(2) {
  grid-column: 3;
}
.articles article:nth-child(3) {
  grid-column: 5;
}
.articles article:nth-child(4) {
  grid-column: 2;
}
.articles article:nth-child(5) {
  grid-column: 4;
}
.articles article:nth-child(6) {
  grid-column: 3;
}`}
</Code>

![](https://res.cloudinary.com/arkmuntasser/image/upload/c_scale,f_auto,q_80,w_800/v1564885707/PixelSnap_2019-08-03_at_19.23.33_2x.png)

Maybe something a bit more standard?

<Code language="css">
{`.articles {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  grid-gap: 2rem 1rem;
}\n
.articles article {
  height: 19vw;
}`}
</Code>

![](https://res.cloudinary.com/arkmuntasser/image/upload/c_scale,f_auto,q_80,w_800/v1564885708/PixelSnap_2019-08-03_at_19.24.07_2x.png)

Across all these layouts, there's only maybe 12 lines of CSS that's different. That's the power of CSS Grid and the power of moving layout out of the HTML.

Write Better Code with CSS Grid


Clean. Code. Clean code. CLEAN CODE! C-L-E-A-N C-O-D-E. Clean code.

What does that even mean? It's something we all say at some point, but it's meaningless. Or, more accurately, means different things to different people with different priorities and contexts.

For the purpose of this post I'm going to focus on separating business logic from the template. To illustrate this, I'll be using a code snippet I pulled from actual production code a developer on my team wrote. I've slightly modified it for clarity. Additionally, this is not meant to be an end-all-be-all way to write "clean code", but rather how I would approach writing this bit of code.

Before I get started, just a couple notes about the code:

1. The solution I end up with is not intended to be production-ready.
2. I am using server-side rendered [goatee](https://github.com/simpleviewinc/goatee) for templating, so syntax may seem unfamiliar at times.

Let's get into it:

<Code language="html">
{`<picture>
	<source
		srcset="{{image.getUrl({
			width: 900,
			height: 300,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 641px)"
	/>
	<source
		srcset="{{image.getUrl({
			width: 1280,
			height: 500,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 1025px)"
	/>
	<source
		srcset="{{image.getUrl({
			width: 1600,
			height: 700,
			crop: 'fill',
			quality: 60
		})}}"
		media="(min-width: 1440px)"
	/>
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Here our dev created a responsive image to draw on the page. It works! But there's a few things that stand out to me about it.

First, there are 3 source elements that are nearly identical; that looks like an opportunity to simplify.

Second, it looks like the crop and quality properties are the same across all calls to `getUrl()`.

Third, if I need to introduce another source, then I need to make yet another source element and it's own call to `getUrl()` which grows adds visual clutter to the template and promotes copy/pasting which can lead to unexpected results if the dev isn't paying attention.

Let tackle this in phases. To start, I'm going to pull out the `getUrl()` calls and make the HTML simpler to read.

<Code language="html">
{`{{~exec(function() {
	helpers.var.srcSm = data.image.getUrl({ width: 900, height: 300, crop: 'fill', quality: 60 });
	helpers.var.srcMd = data.image.getUrl({ width: 1280, height: 500, crop: 'fill', quality: 60 });
	helpers.var.srcLg = data.image.getUrl({ width: 1600, height: 700, crop: 'fill', quality: 60 });
})}}\n
<picture>
	<source srcset="{{~var.srcSm}}" media="(min-width: 641px)" />
	<source srcset="{{~var.srcMd}}" media="(min-width: 1025px)" />
	<source srcset="{{~var.srcLg}}" media="(min-width: 1440px)" />
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Already, this feels better. It isn't actually better, but I'm headed in the right direction. I still have a lot of repeated code, but at least I can more readily see how I might be able to simplify the multiple sources into a loop over a single source. Similarly, now that I've pulled out the `getUrl()` calls into a JS context, I can standardize how I generate the URLs.

<Code language="html">
{`{{~exec(function() {
	const props = {
		641: { width: 900, height: 300, crop: 'fill', quality: 60 },
		1025: { width: 1280, height: 500, crop: 'fill', quality: 60 },
		1440: { width: 1600, height: 700, crop: 'fill', quality: 60 },
	};
	const widths = [641, 1025, 1440];
	helpers.var.srcs = widths.map(width => ({
		width,
		src: data.image.getUrl(props[width]),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

This is starting to look much better now.

Starting with the HTML, I've condensed the multiple sources into a single, easy-to-read loop. This also means, that if I needed to add a 4th or 5th source, I modify the array.

Next, let's take a look at the JS. I've created an array of viewport widths called `widths`; these widths are also the keys in the `props` object so I can associate a width with a set of arguments for our `getUrl()` call. And lastly, I map over the widgets to create and array of `srcs` which is what drives the generation of source elements in our HTML.

At this point, the HTML is pretty much where I want it. However, there's still room for improvement in the JS; `crop` and `quality` are still shared across all the sets of arguments.

Let's address that.

<Code language="html">
{`{{~exec(function() {
	const sizes = {
		641: { width: 900, height: 300 },
		1025: { width: 1280, height: 500 },
		1440: { width: 1600, height: 700 },
	};
	const settings = { crop: 'fill', quality: 60 };
	const widths = [641, 1025, 1440];
	helpers.var.srcs = widths.map(width => ({
		width,
		src: data.image.getUrl({
			...sizes[width],
			...settings
		}),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

Here I've pulled out the `crop` and `quality` into their own object called `settings`. I've also renamed `props` to `sizes` which is much more descriptive now since all that object is concerned with are the sizes of the images to render.

Next, in the map, I spread the sizes and settings into an arguments object to be passed to `getUrl()`.

This is looking really slick now, but I'm not a fan of managing the viewport widths both in the `sizes` object and in the `widths` array. I really would like to keep it to a single touch point to reduce my chances to break something.

<Code language="html">
{`{{~exec(function() {
	const sizes = {
		641: { width: 900, height: 300 },
		1025: { width: 1280, height: 500 },
		1440: { width: 1600, height: 700 },
	};
	const settings = { crop: 'fill', quality: 60 };
	helpers.var.srcs = Object.entries(sizes).map([width, size] => ({
		width,
		src: data.image.getUrl({
			...size,
			...settings
		}),
	}));
})}}\n
<picture>
	{{#~var.srcs}}
		<source srcset="{{src}}" media="(min-width: {{width}}px)" />
	{{/}}
	<img src="/path/to/default.jpg" alt="…" />
</picture>`}
</Code>

To simplify the handling of widths, I removed the `widths` array altogether and am, instead, mapping over the entries of the `sizes` object and destructuring out the size and the width. This is what I would consider "clean code".

First off, the HTML is greatly reduced and can support an indefinite number of sources. And there's no ambiguity about what the HTML is doing: it's putting a picture on the page.

Second, I have a single entry point for getting the actual image URLs that, ideally, I or a future developer supporting this site shouldn't need to touch.

Third, moving out the shared settings like `crop` and `quality` afford me two things:

1. I can easily make a global quality or crop change.
2. I can ignore them if I don't actually care about what they're set to.

Lastly, I am freed up to focus on the part that I most care about: defining sizes of images for different screen sizes.

I would and have delivered something like this in production. I find it to be much more readable, maintainable, and extendable compared to any of the previous iterations I ran through in this post.

How would you approach this? Do you have a better idea? Let me know in the comments below.


Category:
HTML