Published

How to embed an Are.na channel using an `iframe` in HTML

A friend got in touch recently about using this WordPress theme, asking if it would be possible to integrate support for Are.na channels in the theme. I suggested that it’s probably out of scope for the theme but could be great as a plugin that integrates the Are.na API, definitely something I’d be interested in making. Started thinking about how it might work best, wanted to keep it relatively simple and such since ideally I’d want it to work with classic WP and Gutenberg.

Turns out, I was way overcomplicating it. I mentioned the plugin idea to Sam and he suggested just doing an iframe embed like they do on the lovely Are.na blog. Of course! 🤦🏻‍♀️

I’d still like to explore the plugin idea at some point since it would offer a few more opportunities (see things to consider about embeds below, particularly the fact that Are.na embed support is undocumented), but this seems like a nice way of doing it in the meantime.

Example below of Gemma’s Internet Explorers channel as an embed:

How it works

This is the embed code for that particular iframe:

<iframe style="border:none;" width="100%" height="590" src="https://www.are.na/gemma-copeland/internet-explorers/embed" title="Gemma Copeland’s Are.na channel “Internet Explorers”"></iframe>

If you’re less familiar with HTML, here’s what’s going on.

The opening and closing HTML tags <iframe></iframe> stand for an Inline Frame element. This type of element nests a separate resource like a webpage on to the page you’re currently looking at. It contains the attributes style, width, height, src, and title to modify the way it behaves.

Since many browsers render an iframe with a border by default, we’re using the style attribute to get rid of the border on this iframe. You can also style HTML elements with classes and CSS, but we’re using this technique, known as inline styles, for simplicity’s sake.

The width and height attributes specify—you guessed it—the width and height of the iframe. If you were missing either of these attributes, the iframe would collapse. According to the standards, these values should both be set as integers which the browser interprets as pixels. That said, browsers seem to be able to interpret a 100% width correctly, meaning that it fills 100% of the width of its container. If you want to stick to standards, you could add a high width value and then add max-width:100%; to your inline styles.

The src or “source” attribute tells the browser what content you want to embed. Without it, you’d just have an empty iframe. The URL we’re using here is exactly the same as the URL for Gemma’s actual Internet Explorers channel (https://www.are.na/gemma-copeland/internet-explorers), with the addition of /embed on the end. If you try visiting this URL, https://www.are.na/gemma-copeland/internet-explorers/embed, you’ll see that it is essentially a stripped-down version of the original Channel page that is more suitable for embedding.

The title attribute indicates the contents of the iframe. It can be important for accessibility since some screen readers will use it.

Things to consider before embedding content on your site

There are a few things worth keeping in mind if you decide to try this. These notes apply to any embedded content, regardless of where it’s coming from.

1. An iframe embeds the tracking and cookie behavior of its source, not just its contents

When you embed another webpage on your site with an iframe, it will behave the exact same way as if you had visited the source website. In other words, that website may collect data about your visitors, use cookies, embed additional third-party tracking, or monitor your visitors’ interaction with the embedded content.

You should be sure that you’re ok with this before including an embed on your site. Personally, this is one reason why I don’t use embeds very often.

I feel comfortable embedding an Are.na channel in this case because it’s for demonstration purposes, they adhere to the GDPR, and I’m satisfied by the way they handle data according to their privacy policy.

2. The accessibility of an iframe embed depends mostly on the source page

It’s recommended to add a title attribute to your embeds for better accessibility, but that’s pretty much where your accessibility control stops. If the source page hasn’t been built with accessibility in mind, it may be difficult to browse for people that use alternative ways to navigate the web.

Unfortunately, Are.na channel embed pages are missing accessibility features such as unique title elements, descriptive alt texts for the block images, and semantic elements such as <figure> or <figcaption>. This is kind of understandable though since these embed pages are an undocumented feature, something that they probably made more for their own use, and they’re no doubt focusing their main efforts on the public-facing product. Would love to see it tweaked though, particularly since they use these embeds on their own blog.

3. It’s nearly impossible to change the way an embed looks

There’s very little you can do to change the look of an embed. You can change the way the frame itself appears, like removing the default border as we’ve done in the example above, but you usually can’t change the contents of the embed.

Sometimes a platform will accept additional attributes or URL parameters that change an embed’s functionality. YouTube is an example, see their Player Parameters documentation. But this just changes the general functionality, it doesn’t allow you to actually change the placement of the play button or change the controls from red to blue. You can use some fiddly JavaScript to get things looking like you want, but it’s pretty hacky.

Instead, if you want to heavily customize the way that the embed contents look, you should probably integrate the content using the platform’s API if they offer it. This is what we did on Gemma’s site, using the Are.na API and Eleventy to add channels directly to her homepage. This content inherits her site’s styles, so it’s more in keeping with the look and feel of her site.

4. Embeds can break

Broken links are an ever-present problem on the web, people are always changing URLs and taking down content. A broken link is only noticeable if you click it, whereas a broken iframe can look pretty crap. If this would bother you, then you might want to be careful about how much embedded content you include on your site.

Besides this, the source website can restrict which domains are allowed to embed their content at any time. This is unlikely to happen with a platform like Vimeo or YouTube which offer embeds as a part of their advertised functionality. But with this Are.na channel embed for example, Are.na might decide that they only want to allow their embed pages to be embedded on their own site and change their Content-Security-Policy or X-Frame-Options HTTP response headers accordingly. And it’s their right to do so if they wish!

If you want to increase the likelihood that third-party content will be available on your site in the future, it’s best to use documented methods, ideally an API. If you integrate content via an API, you can craft a graceful error message in the event that the content doesn’t load. This can look a lot more forgiving than a broken embed.

5. Embeds probably won’t be crawled by search engine bots

This is… not a huge concern IMO. But I mention it since it may be a concern for others. Search engine bots don’t tend to crawl iframe contents, meaning that they won’t take that content in to account when determining what your page is all about. If this is super important to you, then use the platform’s API (if available) to integrate third-party content directly in to your site.

Edit at 2pm: Changed width description since 100% isn’t technically in line with standards, though it works.

Published

Disabling “save to Pinterest”

Just had a collaborator ask if we could disable the “save to Pinterest” button even if a visitor has a Pinterest addon / extension in their browser. My immediate reaction was “Maybe? I’d think not but will see!”

Turns out something like this should be possible. Pinterest supports disabling saves from a site, see their documentation. You can either enable it site-wide or per image.

I’m surprised but really happy to see that they offer this, hope that they continue to do so.

Published

aaronzlewis.com

Another personal site well worth checking out:

aaronzlewis.com

There’s a lot of great stuff going on here: a cocoon for fledgling writing that’s maybe not quite ready for prime time yet but well worth sharing, web-like behavior in that the site pulls in content from various sources (Twitter, Arena, his blog, etc.). It really gives you a well-rounded picture of his personality.

The use of color and transitions is great too, usually when I see a site with this much movement and color it can come across as wacky / zany. That’s fine and appropriate for some personalities, but it’s not the sort of thing that I would go for on my own site. So it’s cool to see someone accomplish a friendly, colorful, and playful design without it feeling too over the top.

I like the tone of his writing too, particularly the “mentors, collaborators, & co-conspirators” bit on his Credits page. I’ve wanted to add something like this for a while but haven’t been sure how to present it.

It’s interesting, coming across sites like this makes me go back and forth about where I’m going currently with my own. On the one hand I’m really enjoying making a site that others can use, it’s been great to see how people use it. On the other hand, I can only go so far with making the theme really “me”. There may be other ways to address this though… worth considering!

Published

A web color space that respects *real* lightness

Lea Verou just published a blog post about the LCH color space. This is super exciting, see her post for detail. Specifically, the improvement has to do with the perceptual uniformity and lightness being visually consistent no matter the hue.

The best way to get a feel for this is to experiment with her LCH color picker. Drag the hue value back and forth, and you’ll see that the tonality of the background remains consistent. It doesn’t suddenly feel a lot lighter in yellow than it does in blue. Do the same thing in an HSL color picker and you’ll feel the difference.

This would help a lot with the color on my site. I’ve never been 100% happy with how the color is handled because it is too hard to control the lightness and thus the legibility. See the List page for a clear example of this, posts in June and February are particularly hard to read. LCH would solve this!

Published

Digital coffee 🤖☕️

I’ve been getting a bunch of emails recently with web- and tech-related questions from collaborators, friends, clients, family members, almost everyone I know. I suspect this has to do with the huge shift we’ve all made recently in the way we work and live our lives.

Related to this, I’m offering offering free 30 minute slots every Tuesday afternoon GMT to anyone that wants to have digital coffee over Google Hangouts. I haven’t decided how long to do this, but I’ll try to continue until we’re past the worst of current events.

The point is to offer individuals – particularly those that are self-employed or run small businesses – an opportunity to ask nebulous tech-y questions. But I’m happy to talk about anything! WFH tips, recipe ideas, the best movie you’ve seen recently, great sci fi authors, how to grow herbs indoors (I could use some pointers). Only thing I’d probably rather not talk a lot about is COVID-19, please and thank you.

I can’t promise to have all the answers, but I can promise my insight and some nice face-to-face time. We could all use a bit of that right now.

If you think you’d benefit from this, feel free to sign up for a slot. If you know someone that might benefit from this, point them my way.

This is directly inspired by Carly Ayers’s Digital Coffee as linked to on Google’s Hack to Help: COVID-19 site. Nice idea.

Published

Using CSS, HTML, and maybe a little logic to display images with a consistent surface area

Every once in a while, I have to figure out how to display images on the web with a consistent surface area. It’s usually in relation to making a lot of logos with very different aspect ratios look evenly sized so that none of them stick out like a sore thumb.

I haven’t had to do this in a while but came across a tweet by Nick Sherman that prompted me to think about it again.

To achieve an evenly-sized group of images, you have to calculate a maximum width that is proportionate to the surface area you want. To do this, you need to be able to calculate a square root, you need the width and height of each original image, and all of your images need to be tightly cropped since extra negative space will throw things off visually.

In the past, I’ve achieved this with logic since vanilla CSS doesn’t currently support a sqrt() function (more on this later). I’ve usually used PHP since I tend to work with Kirby CMS pretty often.

The function in PHP:

function max_img_width($img_width, $img_height, $ideal_area) {
  $max_width = round($img_width * sqrt($ideal_area / ($img_width * $img_height)));
  echo $max_width;
}

And the function in use + corresponding HTML:

<img style="max-width: <?php max_img_width(1500, 3000, 40000); ?>px;" src="https://piperhaywood.com/my-image.jpg">

A CSS-only solution that works now

There seems to be a CSS-only way to go about this though. Apparently you can approximate square roots in CSS by using a series of CSS variables and calc(), see more info in this thread.

I will warn you: this is ugly. Also, it heavily relies on CSS variables which may or may not work for you depending on your browser support requirements. Here’s the CSS and the image markup:

img {
  --width: 0;
  --height: 0;
  --ideal-area: 40000;
  --area: calc(var(--width) * var(--height));
  --ratio: calc(var(--ideal-area) / var(--area));
  --guess01: calc(calc(var(--ratio) + calc( var(--ratio) / var(--ratio))) / 2);
  --guess02: calc(calc(var(--guess01) + calc( var(--ratio) / var(--guess01))) / 2);
  --guess03: calc(calc(var(--guess02) + calc( var(--ratio) / var(--guess02))) / 2);
  --guess04: calc(calc(var(--guess03) + calc( var(--ratio) / var(--guess03))) / 2);
  --guess05: calc(calc(var(--guess04) + calc( var(--ratio) / var(--guess04))) / 2);
  --guess06: calc(calc(var(--guess05) + calc( var(--ratio) / var(--guess05))) / 2);
  --guess07: calc(calc(var(--guess06) + calc( var(--ratio) / var(--guess06))) / 2);
  --guess08: calc(calc(var(--guess07) + calc( var(--ratio) / var(--guess07))) / 2);
  max-width: calc(var(--width) * var(--guess08) / 2 * 1px);
}
<img style="--width: 1500; --height: 3000;" src="https://piperhaywood.com/my-image.jpg">

I’d want to do some more browser testing since this results in a pretty gnarly calc() situation by --guess08, but at first glance this seems like it might be a worthwhile solution. It doesn’t give us exactly proportionate surface areas but it gets very close. It only starts to fall apart with super skyscraper-y and letterbox-y images.

A few quick notes regarding why this is written as it is and ways that it could be tweaked:

I capped the number of guesses at eight because any more seemed to just fail, Chrome and Safari wouldn’t interpret such a big calc() equation.

I set the default width and height to zero so that there is no max width restriction if the image tag is missing the width and height CSS variables. This could be changed, as could the ideal area variable (increase to get larger images, decrease to get smaller).

The 1px value in the max-width calculation is required so that the value is interpreted as a unit. That said, it doesn’t have to be pixels! Could change this to another unit like 1em or 1%.

If I wanted to display these evenly centred, I’d probably give the images some margin and then wrap them in a container with styles as below:

.container {
  align-items: center;
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
}

Could also use CSS grid for a more consistent spacing result.

And a final reminder: this only visually scales the images. Try to avoid loading a 3000px wide image if you’re going to be displaying it around 200px wide, your users and the planet will thank you.

A CSS-only solution that might work in the future

So apparently more complex math functions including sqrt() might be coming to CSS in the future! See this issue raised by Lea Verou in the CSS specifications editor’s drafts repo and the exponential functions section from CSS Values and Units Module Level 4 in the W3C editor’s draft from 3 February 2020 (a couple days ago!).

I’m not sure when this would become part of the spec and no idea if / when the browsers might implement them, but here is a snippet that should work with that new function in theory:

img {
  --width: 0;
  --height: 0;
  --ideal-area: 40000;
  max-width: calc(var(--width) * sqrt(calc(var(--ideal-area) / calc(var(--width) * var(--height)))) / 2 * 1px);
}

I’m happy that Nick asked the question on Twitter, I actually need this on an upcoming project where I’ve only got Twig to work with which doesn’t support square roots, and I’d prefer to avoid JavaScript in this instance. Hopefully this is the solution, will update here if so.

A picture says a thousand words, so see Nick’s very nice demo of area-based image sizing with CSS to check out one possible outcome.


Edit 05.02.20

Edited a few words for clarity, added Nick’s demo, added future example incorporating a CSS-based sqrt() function.

Thanks Sam Baldwin for bringing future math function support in CSS to my attention!

Edit 06.02.20

Simplified the PHP + HTML example.

The original PHP + HTML example used a --max-width CSS variable instead of just applying a max-width directly. I used a CSS variable because I thought that they were compliant with a strict Content Security Policy that includes the style-src directive set to unsafe-inline. That assumption was incorrect, though there does seem to be some discussion about the topic.

Thanks Lizzie Malcolm for questioning the CSS var usage in the PHP example!

Edit 18.02.20

Changed parenthesis-enclosed arithmetic so that each is enclosed in calc(). Plain CSS seems to interpret arithmetic enclosed in parenthesis just fine, but SASS doesn’t seem to like it.

Published

Switching from Google Analytics to Matomo (f.k.a. Piwik) on WordPress

It’s a new decade, time to leave Google Analytics.

A big part of me wants to say screw it, just get rid of analytics altogether. But I find it interesting. I’ve never used it to decide what to write, and I don’t think I ever will, but it’s just fascinating to find out what makes the rounds. I’ll never know why a short post about repairing my mom’s straw bag was my most popular post for years, but I’m glad to know a lot of people checked it out.

So I decided to keep my Google Analytics property in place and just locked it down as much as I could. I adjusted the script to respect users’ Do Not Track browser settings (Paul Fawkesley has a short article about how to do this). I also configured Google Analytics to anonymise IP addresses, and I deliberately disabled Data Collection for Advertising Features, Demographics and Interest Reports, User-ID, and all data-sharing settings. I also set a low data retention policy to make sure old data would get deleted.

None of this changed the fact that I was still sharing data with Google.

Read more

Published

Date-based colour

Read “Dynamic, Date-Based Color with JavaScript, HSL, and CSS Variables” by Rob Weychert

This is such a useful article. His implementation on Tinnitus Tracker is definitely more involved than what I’ve done on this site, particularly what he’s done to account for inherent saturation levels and lightness vs luminance. And his colour wheel mapping is slightly offset from mine. I feel like August is the reddest month! I’ve wanted to reconsider the colour here for a while, particularly since the accessibility of some of the hues isn’t up-to-snuff. Rob’s write-up might make that adjustment a bit more straightforward which is a big relief.

I remember being really interested in where Grant Custer went with colour on his blog when I started screwing around with colour on this site. See his blog in 2013 on the Internet Archive. I wanted to see whether or not there was some way to ambiguously reflect where I was in the world, particularly since I live so far away from most of my family.

The first version of the colour experimentation on this site mapped the HSL values to the season, temperature, and time of day where I was at the time the site was visited. This is an example from Paris in late 2016. The hue value was mapped to the date/season (same as now), and the lightness was mapped to the time of day using Moment.js and Moment Timezone. The goal was to map the saturation to the weather where I was using the OpenWeatherMap API with stormy and cloudy days being less saturated, but that never came to be since the weather descriptions weren’t consistent enough. I ended up mapping the saturation to the temperature instead, but I don’t think it was quite as effective.

When I turned the site in to a blog first and foremost, I dropped the location and weather aspect. It could be fun to return to it since it might bring a bit more variation, particularly on the list page. Might be a little wild though, and it might be a massive headache to introduce location and weather on old posts… At bare minimum, I could probably incorporate the time of day as lightness. We’ll see!

Published

gemmacope.land

gemmacope.land

Gemma Copeland’s new site is online! This was really fun, one of the truest collaborations I’ve done in a while. Minimal JavaScript, Eleventy + Netlify, Arena API fun, unicode arrows, accessibility at the fore. It was an exercise in playful sufficiency, hopefully we’ve created a functional sandbox that she can work with for some years to come.

I’m hoping to write a bit more about the development at some point, particularly on working with the Arena API. Ran in to some interesting hurdles with block ordering! In the meantime, see the repository on GitHub and check out the making-of post on her website.