Good. Take advantage of that. A big chunk of accessibility work is making things accessible to machines so they can then be accessible to humans.

Use their lingo. Call it machine-readable or AI-ready. That's how to make things AI-friendly 101.

Take stakeholders to the future they already want, but through the right route. Move accessibility from a compliance requirement to part of your AI strategy.

On 23 January 2026, I received an email from Salesforce about a security issue that impacted click tracking:

Salesforce Security recently became aware of a security issue that affected links in emails sent through Marketing Cloud Engagement, including: Clicks, CloudPages, Forward to a Friend, Profile Center, Subscription Center, Unsub Center, and View as a Web Page.

Prior to the fix, this issue—if exploited—could have allowed an unauthorized party to view or access data displayed on CloudPages and certain subscriber information, specifically for Forward to a Friend, Profile Center, Subscription Center, and Unsub Center. In addition, an unauthorized party could have potentially viewed emails sent through View as a Web Page.

Salesforce's solution was to expire all affected links (included click tracking links) prior to 21 January 2026:

Out of an abundance of caution, links generated prior to January 21, 2026 at 23:00 UTC were expired at January 23, 2026 at 21:00 UTC: Clicks, CloudPages, Forward to a Friend, Profile Center, Subscription Center, Unsub Center, and View as a Web Page.

While the ping anchor tag attribute would not have prevented the issue entirely, its adoption for click tracking in the email ecosystem could have reduced complexity, preserved link integrity, protected the recipient experience and limited business impact when failures occurred.

It's the difference between the solution being "all affected links are now expired" to "affected links still work but click tracking is disabled."

Function first. Measure second.

In such environments, change is hard. Change here is only possible if individuals go out of their way and fight inertia; not because the culture invests in change.

Change here happens mid air. It takes courageous individuals who are mad enough to touch the engine mid air. After all, this plane is not meant to land.

Working in tech can make this worse. The industry moves incredibly fast and it's natural to try to keep up with the changes. Afterall, your livelihood may depend on it.

Many in the industry end up consuming more. And many of those in tech are probably "optimisers", so they try to do it more efficiently. For those people, podcasts and videos are never played at 1x speed. The goal isn't just to consume more, but to do it faster too.

Given how much changes in the tech industry, there is a case for consuming more. The problem is when this habit creeps into other forms of consumption and learnings.

Allow yourself to ponder more deeply. Re-listen to that podcast episode that resonated with you. Re-read that book that made you think differently. Re-watch that talk. Think about them. Actually give your brain the chance to think thorugh and interrogate some ideas.

And most importantly, act on what you learned. Give it a try instead of being distracted by the next learning opportunity. Don't be simply a collector of knowledge. Mix what you already know with what you recently learned and start doing.

One thing you can try is creating a re-listen playlist and/or a re-read reading (books/articles) list. Next time you look for a new podcast episode or a new book, turn to these lists instead. Every now and then you can review these lists and ask yourself "what did I learn from this?", "what am I applying from this in my day-to-day?".

Why am I thinking about this again? Email messages may contain:

• dates
• phone numbers
• URLs
• email addresses
• physical addresses

Some email clients choose to auto-link these if found in the email message. A date would link to the default calendar app on the device. A phone number would be a tel link. An email address would be a mailto link. And so on.

This seems reasonable. The app is making it easier for their direct user to perform actions with fewer steps. They can quickly add a bill's due date to their calendar. One click and the support phone number is on their dial screen. They don't have to copy that physical address manually and paste it on Google Maps. You get the picture.

But senders of email marketing messages do not like this. They think of the recpient as their user too/instead. They want to be able to control what their user sees and what parts of the email message they can interact with. They want to choose how links are styled. This also seems reasonable.

However, what I don't see as reasonable is when senders not only want to control how links are styled, but when they also want to contorl whether the email client auto-links any of these. I don't think this is a good goal. The email client is trying to provide a good user experience to the user enabling them to perform certain actions with fewer steps. I don't think it should be the third party's decision to say "no, don't do that" and break the consistency of the email client's UX across different email messages.

Senders choose to break the email client's preferred UX by making text less accessible just so they can control the link style or prevent a piece of text from getting auto-linked.

On the other hand, email clients sometimes style links as if all email messages are only black-on-white (they aren't) and as if all languages can be styled the same (e.g. underline can impact legibility in languages like Arabic and Farsi).

And occasionally email clients would incorrectly auto-link things. Many social media handles include a dot . part way through and what comes after the dot can be a valid TLD. The email client may detect this handle as a valid domain and link to a site that does not exist or does not match what the sender is referring to.

Both the first party and the third party wants the user to belong to them. Each wants to control the UX. Each wants to control the styling. Each does things to cancel what the other does.

But, whose user is it anyway? That's irrelevent. The ultimate goal is to provide a good and accessible experience to the user. The way email clients and senders are handling this right now takes focus away from that goal and the engineering effort is instead put into tricking the other party's code to do what you want.

To do this, use BladeCompiler in bootstrap.php at the root directory of your Jigsaw project:

 1<?php
 2 
 3use Illuminate\View\Compilers\BladeCompiler;
 4use TightenCo\Jigsaw\Jigsaw;
 5 
 6 
 7$events->afterBuild(function ($jigsaw) {
 8  // get the Blade template as a string
 9  $bladeTemplate = $jigsaw->readSourceFile('path/to/template.blade.php');
10 
11  // render the template
12  $renderedHTML = BladeCompiler::render($bladeTemplate, [
13    // data to pass to the template
14  ]);
15 
16  // write the file (path relative to the build directory)
17  $jigsaw->writeOutputFile('index.html', $renderedHTML)
18});

You're not going to automatically get all of Jigsaw's global variables though. You can pass a $page object with all your global config variables available as properties (mimicking what Jigsaw does when rendering a Blade template):

1$renderedHTML = BladeCompiler::render($bladeTemplate, [
2  'page' => $jigsaw->getConfig(),
3]);

Quick intro to Alpine directives

An Alpine component must start with the x-data directive. Its value can be an inline object:

1<div x-data="{ isOpen: false }">
2</div>

Or you can use Alpine.data() and have a seperate (reusable) Alpine component object

 1<div x-data="myComponent">
 2</div>
 3 
 4<script>
 5  document.addEventListener('alpine:init', () => {
 6    Alpine.data('myComponent', () => ({
 7      isOpen: false
 8    }))
 9  })
10</script>

You can use inline directives:

1<div x-data="{ isOpen: false }">
2  <button type="button" x-on:click="isOpen = !isOpen">Toggle</button>
3 
4  <div x-show="isOpen">
5    <!--  -->
6  </div>
7</div>

Or encapsulate directives with x-bind:

 1<div x-data="myComponent">
 2  <button type="button" x-bind="btn">Toggle</button>
 3 
 4  <div x-bind="content">
 5    <!--  -->
 6  </div>
 7</div>
 8 
 9<script>
10  document.addEventListener('alpine:init', () => {
11    Alpine.data('myComponent', () => ({
12      isOpen: false,
13 
14      btn: {
15        ['x-on:click']() {
16          this.open = !this.open;
17        }
18      },
19 
20      content: {
21        ['x-show']() {
22          return this.open;
23        }
24      }
25    }))
26  })
27</script>

The directiveless approach

When you don't have control over the HTML markup, you can programmatically set the directives.

While you can programmatically set all the directives with element.setAttribute(), it's probably not the cleanest or most maintainable approach especially for more complex components.

1element.setAttribute('x-on:click', 'open = !open')

Instead use x-bind to encapsulate directives so you only have to programmatically set x-bind on the elements you need.

 1<div class="container">
 2  <button type="button">Toggle</button>
 3 
 4  <div class="content">
 5    <!--  -->
 6  </div>
 7</div>
 8 
 9<script>
10  // set directives programmatically
11  document.querySelector('.container')
12    .setAttribute('x-data', 'myComponent');
13 
14  document.querySelector('.container button')
15    .setAttribute('x-bind', 'btn');
16 
17  document.querySelector('.container .content')
18    .setAttribute('x-bind', 'content');
19 
20  // the alpine component
21  document.addEventListener('alpine:init', () => {
22    Alpine.data('myComponent', () => ({
23      isOpen: false,
24 
25      btn: {
26        ['x-on:click']() {
27          this.open = !this.open;
28        }
29      },
30 
31      content: {
32        ['x-show']() {
33          return this.open;
34        }
35      }
36    }))
37  })
38</script>

 1<?php
 2 
 3use Statamic\Facades\Blueprint;
 4use Statamic\Facades\Entry;
 5 
 6$data = [
 7  'slug' => 'some-title',
 8  'title' => 'Some title',
 9  // more data
10];
11 
12// validate the data
13$validated_data = Blueprint::setDirectory('resources/blueprints/collections/my_collection')
14      ->find('my_collection')
15      ->fields()
16      ->addValues($data)
17      ->validator()->validate();
18 
19// create & save the entry with the validated data
20$entry = Entry::make()
21  ->collection('my_collection')
22  ->slug(data_get($validated_data, 'slug'))
23  ->published()
24  ->data($validated_data);
25 
26$entry->save();

When Statamic routes to a collection entry page, it automatically includes the entry variables in the view. You can access the entry’s title directly through the variable title. You don’t need to fetch the data in any way.

There are cases in which you need to create your own custom routes, and your own Laravel controllers that return Antlers views.

1public function index()
2{
3    return (new \Statamic\View\View)
4        ->template('myview')
5        ->layout('mylayout')
6        ->with(['title' => 'Example Title']);
7}

You can add the variables you want to be accessible to you within the antlers view by passing an array to the View::with() method. But what do you do when you want to pass an entry’s variables to the view?

 1use Statamic\Facades\Entry;
 2 
 3public function index()
 4{
 5  $my_entry = Entry::whereCollection('my_collection')
 6                        ->where('slug', $slug)
 7                        ->where('published', true)
 8                        ->first();
 9 
10  return (new \Statamic\View\View)
11      ->template('myview')
12      ->layout('mylayout')
13      ->with([
14        // what do I add here?
15      ]);
16}

You can use the toArray() method:

 1<?php
 2 
 3use Statamic\Facades\Entry;
 4 
 5public function index()
 6{
 7  $my_entry = Entry::whereCollection('my_collection')
 8                        ->where('slug', $slug)
 9                        ->where('published', true)
10                        ->first();
11 
12  return (new \Statamic\View\View)
13      ->template('myview')
14      ->layout('mylayout')
15      ->with($my_entry->toArray());
16}

And you can add other variables too:

1return (new \Statamic\View\View)
2    ->template('myview')
3    ->layout('mylayout')
4    ->with(array_merge([
5      // other variables
6    ], $my_entry->toArray()));

However, you may run into unexpected templating issues with certain field types like the Entries fieldtype where can’t output the desired content even though you may be able to loop over the selected values for this field.

The better way to add your entry’s variables to the antlers view is by using the View::cascadeContent() method:

 1<?php
 2 
 3use Statamic\Facades\Entry;
 4 
 5public function index()
 6{
 7  $my_entry = Entry::whereCollection('my_collection')
 8                        ->where('slug', $slug)
 9                        ->where('published', true)
10                        ->first();
11 
12  return (new \Statamic\View\View)
13      ->template('myview')
14      ->layout('mylayout')
15      ->with([
16        // some variables
17      ])
18      ->cascadeContent($my_entry);
19}

This site was built with Jigsaw a couple of years ago, but I didn't like that I was using both PHP and Node.js (to compile assets with Laravel Mix). I switched to an all Node.js solution (Astro) for about a year, but I missed the simplicity of Jigsaw in comparison.

So I switched back to Jigsaw, but decided I'd take a minimal approach this time with the below goals in mind:

• Zero NPM dependencies. I want the site to be solely compiled with PHP.
• Single file components. I want to author the component's CSS in the same file I author the HTML. An approach I really liked in Astro.

Component CSS

The goal is to be able to author CSS and HTML in the same component file

1<style>
2  /* my component CSS */
3</style>
4 
5<div>
6  <!-- my component -->
7</div>

Using Blade's stacks, the <style> element can be pushed to the <head>:

1<!DOCTYPE html>
2<html lang="en">
3<head>
4  @stack('css')
5</head>
6.
7.
8</html>

Using the @pushOnce directive, the <style> element is only pushed to the <head> once per page. It is also only pushed if the component is used on the page.

1@pushOnce('css')
2  <style>
3    /* my component CSS */
4  </style>
5@endPushOnce
6 
7<div>
8  <!-- my component -->
9</div>

For a light site the CSS doesn't need to be served via an external style sheet. So I am happy to keep the components' CSS in embedded <style> elements.

Base CSS

The base CSS is authored in a CSS file. So I could add it to the page via an external style sheet, but seeing how small it is I chose to follow the same approach as the components' CSS and embed it directly to the page using the inline() helper function:

 1<!DOCTYPE html>
 2<html lang="en">
 3<head>
 4  <style>
 5    {{ inline('/assets/build/css/main.css') }}
 6  </style>
 7 
 8  @stack('css')
 9</head>
10.
11.
12</html>

CSS Minification

Considering the way I chose to author the CSS, I decided to create a pair of custom Blade directives that minifies the CSS inside it using a PHP-based minifier (matthiasmullie/minify):

1@minifyCSS
2  <style>
3      {{ inline('/assets/build/css/main.css') }}
4  </style>
5 
6  @stack('css')
7@endMinifyCSS

./blade.php:

 1<?php
 2/** @var \Illuminate\View\Compilers\BladeCompiler $bladeCompiler */
 3 
 4$bladeCompiler->directive('minifyCSS', function ($expression) {
 5  return '<?php
 6    if($page->minifyCSS) {
 7      ob_start();
 8    }
 9  ?>';
10});
11 
12$bladeCompiler->directive('endMinifyCSS', function ($expression) {
13  return '<?php
14    if($page->minifyCSS) {
15      $minifier = new MatthiasMullie\Minify\CSS();
16      $minifier->add(str_replace(["<style>", "</style>"], "", ob_get_clean()));
17      echo "<style>" . $minifier->minify() . "</style>";
18    }
19  ?>';
20});

And in the configuration file of any environment where CSS needs to be minified, set minifyCSS to true:

1return [
2  'production' => true,
3  'minifyCSS' => true,
4];

JavaScript

Right now the site doesn't use any JS, but if I was to add any, I would use Alpine.js. This would enable me to keep this NPM-free and continue with my single file component approach.

Plus I love Alpine!

Syntax highlighting

I blog about web dev so code syntax highlighting is a must. I offloaded the syntax highlighting to Torchlight which has first-party support for Jigsaw.

Putting it together

Example layout

 1<!DOCTYPE html>
 2<html lang="{{ $page->language ?? 'en' }}">
 3  <head>
 4    {{-- meta tags --}}
 5 
 6    @minifyCSS
 7      <style>
 8          {{ inline('/assets/build/css/main.css') }}
 9      </style>
10      @stack('css')
11    @endMinifyCSS
12  </head>
13  <body>
14    <x-header />
15 
16    <main>
17      @yield('body')
18    </main>
19 
20    <x-footer />
21  </body>
22</html>

Example page

 1@extends('_layouts.main')
 2 
 3@pushOnce('css')
 4  <style>
 5    /* page-specific CSS */
 6  </style>
 7@endPushOnce
 8 
 9 
10@section('body')
11  {{-- page content example --}}
12 
13  <section>
14    <h2>Latest posts</h2>
15 
16    @foreach($content_posts->take(5) as $post)
17      <x-posts.card :post="$post" />
18    @endforeach
19 
20    <a href="/blog">View all posts →</a>
21  </section>
22@endsection

Example component

1@pushOnce('css')
2  <style>
3    /* component CSS */
4  </style>
5@endPushOnce
6 
7<div>
8  <!-- component -->
9</div>

1.collapsible {
2  height: 0;
3  overflow: hidden;
4  transition: height .3s;
5}
6 
7.collapsible.is-open {
8  height: auto;
9}

For years developers relied on jQuery's (or Velocity's) slideUp() and slideDown() methods to perform slide up/down animations without setting a fixed height. In fact, I remember being brought into projects where jQuery was added to the project just for these 2 methods.

Here is how to implement slide up/down animation with Alpine JS.

Component set up

Start with an Alpine component with a property to manage the open state of a collapsible element. And let's add a .collapsible element.

1<div x-data="{isOpen: false}">
2  <div class="collapsible">
3    <!-- your content -->
4  </div>
5</div>

CSS

Then we add the CSS styles for the collapsed state:

1.collapsible {
2  height: 0;
3  opacity: 0;
4  overflow: hidden;
5  transition: all .4s;
6  pointer-events: none;
7}

And then we add the CSS for the expanded state (excluding the height which we'll manage with Alpine):

1.collapsible.is-open {
2  opacity: 1;
3  pointer-events: auto;
4}

The magic

What we want to do when the isOpen property is set to true:

1. Add the .is-open class to the .collapsible element
2. Programmatically set a height to the .collapsible element

For (1), we'll use x-bind to conditionally set a class based on the value of the isOpen property. This can be written as x-bind:class or :class:

1<div x-data="{isOpen: false}">
2  <div
3    class="collapsible"
4    :class="isOpen && 'is-open'"
5  >
6    <!-- your content -->
7  </div>
8</div>

For (2), we'll also use x-bind, but to add some inline styles. We'll add the height property and give it a value we calculate with JS.

"Calculate" is a misleading term here. We are going to literally read the height of the element using scrollHeight which includes the height of an element's visible and invisible content. We'll access the element's DOM node using Alpine's $el magic property.

1<div x-data="{isOpen: false}">
2  <div
3    class="collapsible"
4    :class="isOpen && 'is-open'"
5    :style="isOpen && {height: $el.scrollHeight+`px`}"
6  >
7    <!-- your content -->
8  </div>
9</div>

Here is the full demo including a button to expand/collapse the element:

See the Pen AlpineJS: slide up/down animation by Hussein Al Hammad (@hus_hmd) on CodePen.

One way to achieve this is to add the line break <br> element after the first word:

1<h1>
2  Lorem
3  <br>ipsum dolor sit amet
4</h1>

This is easy to do if you are hardcoding the content. It is certainly achievable with a scripting language if your content is dynamic, but there's also a simple and practical CSS approach:

1. Target the first line of the text with the ::first-line pseudo-element.
2. Set a large word-spacing that no two words can fit in a single line

1.reverse-orphan::first-line {
2  word-spacing: 100vw;
3}

You can now apply specific styles to the first word by styling the first line:

1.reverse-orphan::first-line {
2  /* make it on its own */
3  word-spacing: 100vw;
4 
5  /* style it how you wish */
6  text-transform: uppercase;
7  font-family: monospace;
8  color: tomato;
9}

See the Pen Reverse orphan word (alone on first line) by Hussein Al Hammad (@hus_hmd) on CodePen.

I realise there are multi-part names (and probably words) in some languages and you'd prefer to keep the full word on the first line. The above approach has no awareness of that; so use wisely.

If you’re reading this and not in the world of HTML email development, the short explanation is CSS has to be inlined out of necessity and not by choise.

I’m not going to dive into the maintainabiliy issues of inlined CSS and why you should avoid it if you can. What I want to discuss is the readability of inlined CSS. Readble code is very valuable; particularly in a team environment. If you don’t put an effort to keep your code readable, you’re hurting yourself and your team.

When you write CSS in a ruleset, you probably use whitespace to keep it readable like so:

1.my-class {
2  color: #000;
3  fake-property: fake-value;
4}

Besides the indentation, you most likely add a space between the property name and the value:

1property: value;

I see developers trying to do the same when manually inlining their CSS:

1<div style="color: #fff; property: value; fake-property: value;"></div>
2<div style="color: #fff; property: value; fake-property: another-value; margin: 10px 0 30px; padding: 10px 20px;"></div>

The space between a property name and its value is equal in size to the space between a value and the following property. This makes it harder for you as a human to scan pairs. It simply takes your brain longer to parse the CSS.

A more readable alternative would be to stack the properties like you would when writing full rulesets:

1<div style="
2  color: #fff;
3  property: value;
4  fake-property: value;"
5>
6</div>

I know this is not everyone’s cup of tea. It’s not the only approach though. You can keep everything in one line and omit the space between a property and its value:

1<div style="color:#fff; property:value; fake-property:value;"></div>

You end up with CSS that is a lot easier to scan and parse as a human. You can compare the readability of the two approaches below:

1<div style="color: #fff; property: value; fake-property: another-value; margin: 10px 0 30px; padding: 10px 20px;"></div>
2<div style="color:#fff; property:value; fake-property:another-value; margin:10px 0 30px; padding:10px 20px;"></div>

Data on support for the mdn-css__properties__aspect-ratio feature across the major browsers

But most major email clients still do not support it:

Yet, you can rely on it for images! Set the width and the height attributes on the img tag, and the browser handles the rest:

1<img src="https://via.placeholder.com/1200x675/FF0000/FFFFFF.png" alt="" width="1200" height="675" style="width:100%; height:auto;" />

This works because the browser's user agent style sheet utilises the values of the width and height attributes to generate the value for the aspect-ratio property:

1img {
2  aspect-ratio: attr(width) / attr(height);
3}

At the time of writing, the attr() function can only be used on the content CSS property. However, when it comes to the browsers UA style sheet the browser can map these values "under the hood" but the CSS value is still represented using the same attr() function.

If you're unfamiliar with the problems aspect-ratio solves, check:

• Jen Simmons's video: Do This to Improve Image Loading on Your Website.
• Barry Pollard's article: Setting Height And Width On Images Is Important Again

Web vs Email

On a normal web page, it doesn't matter what the values for the width and height attributes are as long as the generated formula represent the same value. So for a 16:9 image, all the below are rendered the same way in modern browsers:

1<img src="https://via.placeholder.com/1200x675/FF0000/FFFFFF.png" alt="" width="16" height="9" style="width:100%; height:auto;" />
2<img src="https://via.placeholder.com/1200x675/FF0000/FFFFFF.png" alt="" width="640" height="360" style="width:100%; height:auto;" />
3<img src="https://via.placeholder.com/1200x675/FF0000/FFFFFF.png" alt="" width="1200" height="675" style="width:100%; height:auto;" />

Unfortunately, in email clients it's not as straightforward because:

1. Outlook Windows still render HTML emails using Microsoft Word, not a browser engine.
2. Gmail's desktop basic HTML view rewrites the height property to min-height.

So unlike on a normal page, it matters which values are used for the width and height attributes. Using the largest values at which you intend to render the image seems a safe approach. So if you have a 1200px x 676px image, but the largest size at which the image is going to be rendered in your email is 640px x 360px, you'd use:

1<img src="https://via.placeholder.com/1200x675/FF0000/FFFFFF.png" alt="" width="640" height="360" style="width:100%; height:auto;" />

I was in one of these rooms and what caught my attention is how the operator selected and started the different games.. with a one-button interface. All he had is a yellow box with a single red button. He hits the button in different sequences to trigger different commands.

I initially thought that must be inconvenient. And the more I thought about it, the more I disliked it. I started thinking about how they must have had to program the controller to handle such commands. And the thoughts started snowballing from there. What is the on-going maintenance and the documentation of these commands like? What about onboarding new operators? That would be unnecessarily time consuming.

If it works for them, then that's good enough, right? What I consider inconvenient is irrelevant here. I'm glad I can easily interact with most software I use with more than just one button.

But what I considered inconvenient is actually necessary in a different context. What I described above is some sort of a single switch entry device. People who are unable to use a mouse or keyboard need an alternative input device, and a single switch entry device is one example of assistive technology that can be used instead.

What I considered inconvenient to myself actually makes interacting with computers and smart phones possible for many.

However, these days I author a lot of code that run in environments on which I have very little control. This feels frustrating at times. Adding client-side form validation on a HTML form that is already being validated with JS client side forces you to implement things in a certain way. And don't get me started on building a HTML email that gets rewritten in 100 ways by the different tech it touches it.

One day while having to implement a workaround after a workaround, I stopped. "Wait.. Am I the third party here?". It felt like I was. I guess I had an epiphany. This changed my mindset when approaching such tasks. I am the third party.

Between new international students, foreign workers, immigrants and refugees there are many people who won't understand the content you have on your website, or the messages you send them via email.

I once was a new international student in Australia and understood very little English. Like many other international students at the time, I carried a portable translation device. Luckily now if you can connect to the internet, you can access a lot better translation services (e.g. Google Translate, Yandex Translate) for free! And you have the convenience of in-browser and in-email translations so you don't have to keep copy-pasting every bit of text you don't understand.

Is translatability an accessibility concern?

Absolutely! And translation software is one type of assistive technology. Making your HTML accessible to as many people (disabled or not) as possible should be your goal.

While it is not reasonable to translate and localise your emails for all languages or expect to know the actual preferred language for all your audience, it is reasonable for your audience to expect accessible emails from you!

What makes your HTML email untranslatable?

In the email industry some practices are favoured (despite accessibility concerns) in order to render emails in a certain way.

Text on images

Text on images has a number of accessibility concerns and translatability is one of them.

Gmail's built-in translator (Google Translate) translates the alt text of images, but the translated version is not visible. An average user will not be able to access the translated version.

Outlook's first-party Translator add-in does not translate the alt text of images at all.

Preventing auto-linking

Another common practice in the email industry is to break words/phrases that trigger email clients to auto-link them with special characters like the "zero width no-break space"  and the "zero width non-joiner" ‌:

1<span>23 September</span>
2<span>23 Se&#xfeff;pte&#xfeff;mber</span>
3<span>23 Se&#x200c;pte&#x200c;mber</span>

In Gmail, only the first <span> is correctly translated. In Outlook (using the first-party Translator add-in), only the last <span> is not correctly translated.

VML

Given Outlook Windows still uses Microsoft Word to render HTML emails in 2021, it can still render VML shapes. Outlook's own first-party Translator add-in does not translate text inside VML shapes. So that's another accessibility issue with VML shapes.

Let's go through the various technical aspects you need to consider when testing CSS in email.

Browser support

Let's start with the easy one. Most email clients rely on a browser to render HTML. This is obvious when it comes to webmail clients you access via a browser, but it is also true to native apps as they rely on browser engines to render the HTML. The exception here is Outlook Windows apps and Windows Mail as they use Microsoft Word to render the HTML.

Given browsers support for CSS features is not identical, the first factor we must consider when testing a CSS feature on email clients is whether browsers support it.

This is an important factor. On iOS, for instance, all native apps have no option but to use the same browser engine (WebKit) to render HTML. So up until iOS 14, no email client on iOS supported WebP images.

I am excluding Outlook Windows and Windows Mail apps from the rest of this article on purpose. Testing CSS features on email clients that use modern browser engines (which follow documented open standards) is one thing, and testing features on email clients that use proprietary software (which support a small set of HTML 4 features) is another thing.

What "support" means

So if the browser engine used by an email client supports certain CSS features, why do we need to look at whether that email client supports it too? How can they not support a feature if the browser engine they use support it?

For a number of reasons (security at the top of that list), blindly rendering third-party HTML code would be a huge issue. So email clients sanitise the code before rendering it to the user. An obvious and easy security win is the removal of any JavaScript code, but email clients tend to strip a lot more than that. They may strip (or even add!) certain certain CSS properties or values, HTML tags and some HTML attributes.

Just because Chrome supports a CSS property, it does not mean a webmail client running on Chrome supports it. CSS declarations in HTML emails can be:

• stripped out
• overwritten
  • the CSS declaration is kept, but is overwritten by email client's own CSS
  • the CSS declaration is kept, but the email client's own CSS affects how the CSS property behaves
• rewritten
  • the CSS property is kept, but the value is changed
  • the value is kept, but the property is changed

And no, email clients do not document any of that.

Narrower questions

Broad questions are rarely helpful in the context of email clients. A question like "is flexbox/grid supported in email clients?" has no short answer.

Flexbox/grid are CSS layout modules. Figuring out whether the module is supported in a browser is fairly straightforward. But you cannot check whether a whole CSS layout module is supported in email clients as easily despite the support summary below:

The above summary tell us two things only: whether the CSS property display is supported and whether it can take the value of flex. Nothing more. It doesn't mean the flexbox layout module is fully supported.

So what sort of narrower questions can we ask?

CSS properties

Testing whether a CSS property is supported is a good first step.

Gmail does not support the align-items CSS property. It completely removes it. So the following:

1<div style="display:flex; align-items:center;"></div>

becomes:

1<div style="display:flex;"></div>

And Yahoo does not support the height CSS property. It keeps the value, but renames the property to min-height. So the following:

1<div style="height:100px;"></div>

becomes:

1<div style="min-height:100px;"></div>

And testing the property on different elements could be insightful. For instance, Outlook mobile apps support the border-radius CSS property, but their default CSS styles prevent border-radius from working on tables.

CSS properties shorthand

Email clients may also have different support for shorthand properties and the separate properties that can be set by a given shorthand property. The background CSS property is an example of this.

CSS values

CSS properties are only half of the equation.

In a CSS declaration there is a CSS property and a CSS value. An email client may support a CSS property while not supporting all valid values the property accepts in the CSS spec.

How an email client handles an unsupported value varies. For example, with vh values, Apple Mail on iOS 15 keeps the declaration, but rewrites values as 0. While, Outlook mobile apps strip a declaration entirely if it has a <gradient> value type.

CSS value types

CSS has many value types (also known as "data types") such as <string>, <length>, <color> and <image>. And there are some sort of sub-types like <gradient> which is a special type of <image>. CSS functional notations (such as url() and calc()) are technically value types too.

Multiple CSS properties can accept the same value types. An example is the color and background-color properties as both accept <color> values. And while color and background-color are widely supported among email clients, not all <color> values are.

Outlook.com, for example, supports the rgb() functional notation, but does not support the hsl() functional notation even though both are <color> values.

Similarly, background-image is another widely supported property only when the url() functional notation is used. Support for other <image> values is inconsistent.

CSS value syntax

A CSS value type can be written in more than one syntax. An email client may support a CSS value, but only in certain syntaxes.

Using the rgb() functional notation as an example. While it is widely supported, not all email clients support the whitespace syntax:

1<div style="background-color: rgb(0 128 0);"></div>
2<div style="background-color: rgb(0 128 0 / 1);"></div>

border-radius is a widely-supported property, but Yahoo does not support the slash notion for defining elliptical corners (using two radii):

1<div style="border-radius: 10% / 50%;"></div>
2<div style="border-radius: 27% 73% 70% 30% / 30% 34% 66% 70%;"></div>

CSS value units

Another thing to consider is the value units. An email client may generally support a CSS property like height which accepts <length> values according to the CSS spec, but the email client may not necessarily accept all <length> values. See: Apple Mail on iOS 15 renders vh units as 0.

Side effects

You may know a CSS feature is not supported in an email client, but still choose to use it as an enhancement for other email clients that do. This is a very reasonable thing to do (see Progressive Enhancement).

However, it is important to check what an email client does when it encounters a CSS feature it doesn't support. Does it remove the whole CSS declaration? Does it rewrite the CSS property and/or value? Are there any side effects?

An example of a major side effect happens in Gmail. While Gmail supports the rgb() functional notation, it does not like it when the value is written in whitespace syntax rgb(0 0 0). When Gmail encounters this syntax in a style attribute of an element, Gmail strips the whole attribute:

1<!-- This -->
2<div style="background-color:rgb(0 0 0); padding:20px;"></div>
3 
4<!-- Turns into this -->
5<div></div>

Guess what happens if you choose to include the whitespace syntax in your embedded CSS in a <style> block. It won't settle for removing the CSS declaration that includes rgb() with the whitespace syntax. It won't settle for the CSS ruleset where the value is used either. It removes the whole <style> block!

Even as a native Arabic speaker, there are many points in that document (or other documents it links to) I had not really thought about. The Arabic and Persian Gap Analysis also highlights gaps in the support for Arabic script on the web.

It is worth noting this affects more than just "websites". The document specifically says "on the Web and in eBooks". This also means in-browser and browser-based apps like Electron apps. The current gaps limit in-browser design apps in particular on how much they can support Arabic script (this doesn't excuse Figma for not supporting RTL/Arabic at all!).

Unicode BIDI Algorithm

An important piece in RTL text support in browsers is the Unicode Bidirectional algorithm:

It is important to understand from the outset that, in all major web browsers, the order of characters in memory (logical) is not the same as the order in which they are displayed (visual).

The set of rules applied by the browser to produce the correct order at the time of display are described by the Unicode Bidirectional Algorithm, or 'bidi algorithm' for short.

If you ever worked on sentences containing a mix of both RTL-flowing and LTR-flowing characters, you know it is painful to author the content in many apps and it requires a bit of extra effort to get it to render ok in browsers. When you have control over the HTML, you can get the text flowing correctly. Having an understanding of how the BIDI algorithm works may help you to handle such sentences in HTML even if you don't read the languages. Understanding the algorithm can also be helpful in crafting sentences that render fine when you have no control over the HTML (e.g. subject line in email clients).

I'm not going to attempt to explain the algorithm here, but I'd like to highlight some interesting aspects.

Unicode characters can have different types: strong directional characters (e.g. alphabet characters), weak directional characters (e.g. common number separators) or neutral characters (e.g. whitespace). You can find a table containing examples of each type in section 3.2 of this document.

What's even more interesting is that some characters are logically interpreted in the Unicode Standard. The U+0028 character (HTML entity: (, AKA: () is not interpreted as "left parenthesis", but rather as "opening parenthesis". If you're familiar with CSS logical properties, this concept of logical directions is not alien to you.

See the Pen Logical Unicode characters by Hussein Al Hammad (@hus_hmd) on CodePen.

1<img loading="lazy" src="/image.jpg" alt="" />

The MDN documentation notes that this is an anti-tracking measure:

Loading is only deferred when JavaScript is enabled. This is an anti-tracking measure, because if a user agent supported lazy loading when scripting is disabled, it would still be possible for a site to track a user's approximate scroll position throughout a session, by strategically placing images in a page's markup such that a server can track how many images are requested and when.

While the purpose of this behaviour seems reasonable on the surface, it made me thinks about two things:

1. The goal of disabling JS

This anti-tracking measure assumes that a user's goal of disabling JS is to prevent websites from tracking them and their actions on pages. This assumption justifies loading more resources on the user's device even if they do not scroll far enough down a page to need them.

I can't personally speak of the intention of disabling JS, but I am unsure how I feel about disabling the feature when JS is disabled in order to prevent tracking. After all, web features get maliciously used all the time.

Disabling deferred loading on img[loading=lazy] can have a direct impact on the user. I can see a user disabling JS in the browser to save on mobile data while browsing. They may not need to scroll all the way down to all pages. That is; they may not need to download all the images on all pages they visit. In this case, the anti-tracking measure backfires.

2. The noscript tracking paths

There are plenty of user-behaviour tracking approaches that work without JS.

The loading attribute on iframe

The loading attribute also works on <iframe>s. The current implementation of the loading attribute on <iframe> works even when JS is disabled. iFrame tracking pixels can be used to workaround the anti-tracking measure on images.

The ping attribute on anchor tags

The ping attribute on an anchor tag is typically used for tracking. It accepts a space-separated list of URLs to which the browser sends POST requests when the link is followed:

1<a
2  href="/contact"
3  ping="https://example.com/my-tracker https://example.com/my-other-tracker"
4>
5  Contact Us
6</a>

The ping attribute works even when JS is disabled. It is disabled by default in Firefox though.

The noscript tag

The <noscript> element can be used to conditionally load different/additional tracking pixels when JS is disabled:

1<noscript>
2  <!-- add tracking pixels here -->
3</noscript>

The CSS approach

CSS provides a number of ways to conditionally apply styles. It also provides a number of ways to load external resources such as images. So it is entirely possible to make use of this to track users without the need of JS.

Using media queries:

1@media (prefers-color-scheme: dark) {
2  #tracker {
3    background-image: url(/my-tracker.png);
4  }
5}

Using feature queries and browser-specific prefixed CSS properties:

1@supports (-webkit-overflow-scrolling: touch) {
2  #tracker {
3    background-image: url(/my-tracker.png);
4  }
5}

CSS also provides a number of ways to apply styles based on user interactions. For example, you can track some user actions in a similar manner to the above using pseudo-classes. And I'm sure there are more novel ways to make use of other CSS features for tracking.

Final thoughts

Built-in anti-tracking measures is a very nice goal in theory, but it seems very hard to implement without sacrificing something else in return.

So this begs the question: is "whether JS is enabled in the browser" the right criterion for enforcing built-in anti-tracking measures?

Arabic is written right to left, but GitHub's layout is LTR. This made the Arabic documentation hard to read on GitHub. Fortunately, we can add HTML to Markdown files. I opened a PR (which has been merged) to sprinkle a bit of HTML to change the layout to RTL.

How?

Wrap the whole thing in div[dir="rtl"]:

1<div dir="rtl">
2# العنوان
3 
4ها نحن ذا ، على دروب كنزنا. نسير معاً و أمالنا تسير قبلنا. من غيرنا؟ يقطع درباً مثلنا! درباً خطيرة إلى الجزيرة ، من غيرنا؟
5</div>

Wrap code blocks in div[dir="ltr"] (assuming your code is written in a LTR language!):

 1<div dir="rtl">
 2# العنوان
 3 
 4ها نحن ذا ، على دروب كنزنا. نسير معاً و أمالنا تسير قبلنا. من غيرنا؟ يقطع درباً مثلنا! درباً خطيرة إلى الجزيرة ، من غيرنا؟
 5 
 6<div dir="ltr">
 7```js
 8import 'alpinejs'
 9```
10</div>
11 
12</div>

If you have LTR copy/code within RTL copy, it may be a good practice to default to wrapping it in span[dir="ltr"] as some characters may flip to the wrong side. For instance, the brackets () of a function can appear on the left instead the right e.g. myFunction():

1<div dir="rtl">
2# العنوان
3 
4إذا أضفنا <span dir="ltr">`.passive`</span> إلى المتصنّت للحدث، فإن هذا الرمز المميز سيعطل وظيفة <span dir="ltr">`preventDefault()`</span> ولن تعمل على أي حدث يتم تنفيذه. يمكن أن يساعدك أحياناً في تحسين أداء التمرير (scroll) على الأجهزة التي تعمل باللمس.
5</div>

I, too, used to default to Javascript solutions until I realised they created more issues in some cases (I also got one-too-many last-minute requests from agency clients to change the mobile behaviour of a section to a slider).

Rely on the browser

I am proudly lazy and overflow-x: scroll just works in browsers. Using the horizontal scrollbar to scroll? Works. Scrolling on a touch screen? Works. Scrolling with your keyboard's arrow keys? Works. Your mouse's scroll wheel supports horizontal scrolling? That works too.

No tech debt. No JS dependencies. It just works!

iOS support

It's been a while since I tested this on a real iOS device, but last I checked it didn't work well without the -webkit-overflow-scrolling property:

1.scroll-x {
2  overflow-x: scroll;
3}
4 
5@supports (-webkit-overflow-scrolling: touch) {
6  .scroll-x {
7    -webkit-overflow-scrolling: touch;
8  }
9}

Progressive enhancement

Using overflow-x: scroll does not mean you have to "settle" for a scrollbar if you don't want one. Glider.js is a good example of how you can progressively enhance a horizontal scrolling component with Javascript.

I also built a demo slider with Alpine.js

See the Pen Alpine.js slider with native scroll by Hussein Al Hammad (@hus_hmd) on CodePen.

Accessibility, UX and content discoverability

If you have multiple slides each of which contains some focusable elements (e.g. links), navigating a horizontal scrolling component with a keyboard gets you no surprises; the browser scrolls the in-focus element into view (within the component).

Another reason to love overflow-x: scroll is how it keeps content discoverability within a page possible when using the browser's built-in find functionality. Here is an example from the CSS-Tricks home page:

And here is another one from a Glider.js demo:

Wait, it gets better

CSS now allows you to customise the scrolling experience within a scrolling element with Scroll Snap. Ahmad Shadeed wrote a great article on Scroll Snap if you want to dive deep into this.

Domain name is وجد.موقع, and موقع is the top-level domain (TLD), which is the equivalent to the site TLD.

A full URL example of page:

1وجد.موقع/م/أساطير-خليجية

How do IDNs work?

Given the Domain Name System (DNS) has to use ASCII characters, they store IDNs as ASCII strings using Punycode, which is:

a representation of Unicode with the limited ASCII character subset used for Internet hostnames

So while my newly launched website's domain name is وجد.موقع, in the DNS it is stored in the Punycode equivalent:

1xn--rgbg7e.xn--4gbrim

Fortunately, there are Punycode converters such as: - punycoder.com - punycode.io

Domain Name vs Page Path

The IDNs use Punycode to work around the DNS limitation of only supporting ASCII characters. This does not apply to the rest of the URL. You can use Unicode characters in the page path.

MDN's What is a URL? is a good resource to learn the different parts of a URL.

Browsers

Unicode vs Punycode (ASCII)

When navigating to a website with an IDN via the browser address bar, both the Unicode (e.g. وجد.موقع) and the Punycode (e.g. xn--rgbg7e.xn--4gbrim) work.

Even if you typed in the Punycode in the address bar, web browsers may automatically convert the URL to the (human-friendly) Unicode equivalent if the URL meets the browser's IDN policy: - Google Chrome's IDN policy - Firefox's IDN Display Algorithm

The goal of these policies is to protect users from IDN homograph attack. There are also browser extensions that alerts users if they are on a site that uses Punycode in its domain name.

Early this year, Google Chrome Developers YouTube channel's show HTTP 203 released an episode titled Humans can't read URLs. How can we fix it?. Jake and Surma briefly discuss how Chrome analyses the URL and when it may choose to display the Punycode over the Unicode.

RTL vs LTR

If you ever mixed RTL and LTR languages when typing something on a digital device, you'd certainly have experienced frustrating times attempting to get words to flow correctly. The browser address bar doesn't handle this too well either.

In the case of وجد.موقع, it is read RTL. However, adding the http protocol at the start means the address starts LTR. So you end up with:

1https://وجد.موقع

Even if you set the language in the browser to Arabic, which converts the UI to RTL:

This is not a huge pain point, but it does look odd. As a developer I know the start is https://. However, to an Arabic speaker who is not familiar with the protocol and its uses, they may interpret this as the URL ends in https://.

This may be slightly off-topic, but it is worth noting that things become even more confusing if you use an ASCII domain name (LTR) with an RTL page path and vice versa:

1وجد.موقع/path/to/page
2 
3xn--rgbg7e.xn--4gbrim/الصفحة-1/الصفحة-2

Copying the URL

When you are on a website with an IDN and copy the URL directly from the address bar, what gets copied into your clipboard varies across browsers.

Firefox (83.0) copies the Unicode:

1https://وجد.موقع

Chrome's (87.0.4280.66) behaviour is more sophisticated. If you include the https protocol when you copy the URL from the address bar, it copies the Punycode into your clipboard:

1https://xn--rgbg7e.xn--4gbrim

If you exclude the https protocol, it copies the Unicode:

1وجد.موقع

The above behaviour only applies to the domain name. When it comes to the page path, the behaviour is also inconsistent across browsers.

Firefox (83.0) encodes the page path to its UTF-8 representation when the URL is copied (think JavaScript's encodeURI(), or PHP's urlencode()), which is a huge UX pain for me in general and not only with IDNs. Receiving a URL in a chat app that fills up half my phone's screen with %s and a mix of meaningless digits and English characters is pointless to me as a user.

1https://وجد.موقع/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9

On Chrome (87.0.4280.66), if the https protocol is included, it copies the Punycode domain name and the encoded page path:

1https://xn--rgbg7e.xn--4gbrim/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9

If the https protocol is excluded, it copies the whole URL in Unicode:

1وجد.موقع/م/أساطير-خليجية

Sharing the URL

Web browsers on smartphones and tablets offer a built-in sharing option, which gives you the choice to copy the URL or share directly to native apps. The behaviour across browsers here is also inconsistent.

The same browser may not behave consistently when copying the URL from the address vs when copying/sharing the URL using the built-in share option. Samsung Internet (13.0.1.64), for instance, copies the Unicode (domain and page path) if you copy the URL directly from the address bar:

1https://وجد.موقع/م/أساطير-خليجية

However, it copies the Punycode and the encoded page path when using the built-in share option:

1https://xn--rgbg7e.xn--4gbrim/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9

JavaScript

The Location API returns the domain name in Punycode and encodes page paths:

 1{
 2  "ancestorOrigins": {},
 3  "href": "https://xn--rgbg7e.xn--4gbrim/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9",
 4  "origin": "https://xn--rgbg7e.xn--4gbrim",
 5  "protocol": "https:",
 6  "host": "xn--rgbg7e.xn--4gbrim",
 7  "hostname": "xn--rgbg7e.xn--4gbrim",
 8  "port": "",
 9  "pathname": "/%D9%85/%D8%A3%D8%B3%D8%A7%D8%B7%D9%8A%D8%B1-%D8%AE%D9%84%D9%8A%D8%AC%D9%8A%D8%A9",
10  "search": "",
11  "hash": ""
12}

The wilderness

I have used a number of services in which I had to enter the IDN for Wajad or on which the domain name is displayed.

Domain registration

Registering a domain with Punycode with a common TLD like .com is not an obstacle. Some domain registrars allow you to use Unicode when searching domains e.g. وجد.com.

But I was looking for the internationalised TLD موقع. It was not easy finding a domain registrar that sold موقع domains. I ended up on multiple scammy-looking sites during my search. Eventually I bought the domain via maracaria.com.

Cloudflare

I had no issues adding IDNs with Unicode when adding the site to Cloudflare. They are also displayed in Unicode in the dashboard:

However, Cloudflare used the Punycode in the email notifications they sent to me so far:

Netlify

Before launching the site, I set up a "coming soon" landing page on Netlify. Unlike Cloudflare, Netlify did not allow me to add the domain name with Unicode, and I had to enter the Punycode equivalent. Netlify's dashboard displays the domain in Punycode:

Their email notifications also display the domain in Punycode:

Cloudways

Wajad's current PHP-based site is hosted on DigitalOcean via Cloudways. The experience on Cloudways is similar to Netlify and I had to enter the Punycode:

Google Search Console

I was able to add the site to Google Search Console with the Unicode version of the domain. Oddly, some subsequent forms did not accept Unicode:

So I had to enter the Punycode equivalent, but Google Search Console displayed the URL in Unicode after submitting the form:

Fortunately, email notifications use Unicode:

Google Search results

Google Search results display the domain name in Unicode. I already knew it displayed Arabic correctly for breadcrumbs, but it is really nice to see the domain name displayed in a human-friendly manner:

Both Unicode and Punycode are supported when using search operators like site::

1site:وجد.موقع
2 
3site:xn--rgbg7e.xn--4gbrim

Bing Webmaster Tools

Bing Webmaster Tools allow you to import verified sites from Google Search Console. Upon an import attempt it displayed an error message saying the site addition was unsuccessful:

I attempted to enter the URL manually as suggested, but the Unicode was not accepted:

Then when I went to check the list of sites under my account, Wajad was actually listed! I'm not entirely sure which of the above attempts was the successful one.

Bing Webmaster Tools lists the domain in Unicode, but when you open the dashboard for the site it lists the Punycode:

I had the opposite experience to Google Search Console when submitting the sitemap. The form accepted the Unicode, but the sitemap list displays the Punycode:

Bing search results

I have only recently submitted the sitemap via Bing Webmaster Tools, so I still do not know the full picture. From what I can tell so far Bing search results also display the domain in Unicode.

However, it seems only Punycode is supported when using search operators like site::

1site:xn--rgbg7e.xn--4gbrim

Fathom Analytics

I had no issue using the Unicode version of the domain when adding the site to Fathom Analytics. The domain is always displayed in Unicode (dashboard and email notifications).

Their recently-launched tool Phantom Analyzer also allowed me to enter the URL in Unicode, but the results page displayed the domain in Punycode.

Zoho Mail

Neither Unicode nor Punycode is supported when signing up to Zoho Mail.

Emails

G Suite (now Google Workspace) allowed me to sign up with my IDN. I sent test emails to Gmail, Yahoo and Outlook. Gmail was the only one to display the domain name in Unicode.

I have also sent HTML email tests with images. Yahoo Mail and Windows Mail did not load images whose src had the domain in Unicode, but Gmail did:

1<img src="https://وجد.موقع/path/to/image.jpg" alt="">

Auto-linking

When sending messages via chat apps, adding the https protocol to the URL (with domain name in Unicode) seems to be enough for most apps.

Although email clients are known for linking text in HTML emails when you don't want them to, I found Gmail and Windows Mail don't auto-link:

1https://وجد.موقع

In-app browsers

The behaviour of in-app browsers is consistent. On iOS, Instagram's in-app browser displays the domain in Punycode, while Twitter's in-app browser displays the domain in Unicode.

I understand, but..

I understand why I'm seeing very different behaviour across browsers and apps, but as a developer and a user I just would love to see a better user experience overall.

Wajad is still a young side project, but it is clear to me that I'll run into more interesting IDN-related scenarios as it grows and I'll try my best to document them.

1<html lang="en"></html>

Adding the lang attribute to an element seems to affect which glyphs in a web font some browsers render, and which system font is rendered. Here is a demo where different paragraphs have different lang values, but they all share font-family: sans-serif:

See the Pen lang attribute and fonts by Hussein Al Hammad (@hus_hmd) on CodePen.

If you are using Chrome, you can check the "Computed" tab in DevTools to check the rendered font. You may get different fonts depending on the fonts you have installed on your device.

Is this a problem?

In the demo above it seems to me that the browser tries to pick a font that is better suited for the specified language, which is a fair behaviour.

However, a number of developers reported that their web font renders differently based on the value of the lang attribute. It looks like the browser renders different glyphs of the same font:

• Example 1
• Example 2

Luckily you can force the browser to render the font in a specific locale with the -webkit-locale property:

1[lang=sr] * {
2    -webkit-locale: "en";
3}

1<html lang="sr"></html>

Here is a quick look at some of the approaches and how you may implement them for web pages and HTML emails.

1. Using different images

Web

On the web you can rely on the <picture> element for this without writing additional CSS:

1<picture>
2    <source srcset="image-dark-mode.jpg" media="(prefers-color-scheme: dark)">
3    <img src="image.jpg" alt="" />
4</picture>

This approach works if you only serve a dark theme when the user's browser or operating system is set to dark mode. If you provide toggable dark/light themes from within the website, you would implement this differently (e.g. hide/display 2 different <img>s).

Email

The <picture> element is not widely supported in email clients at the time of writing, so you would hide/display 2 different <img>s with a media query. Litmus's The Ultimate Guide to Dark Mode for Email Marketers covers this approach well and goes further to explain how to use the [data-ogsc] attribute selector to target Outlook web and mobile app.

2. Using dark-mode-optimised images

If you do not wish to use different versions of an image (one for light mode and another for dark mode), in some cases you can optimise an image so it looks well on dark mode. You may use a transparent background and/or add outlines or light-coloured shadows that do not show on light mode.

⚠️ Transparent backgrounds

PNG is probably the most commonly-used image format when a transparent background is needed. The type of the image impacts the file size. When it comes to PNGs, a photograph for instance can be extremely large in size in comparison to other formats such as JPG and WebP. So do not disregard performance here.

Web

For simple shapes like circles and rectangles with rounded corners you can rely on CSS instead of using a large PNG.

For more complex shapes, you may be able to use clip-path, but not all its features are supported across major browsers at the time of writing.

Email

For simple shapes like circles and rectangles with rounded corners you can also rely on CSS instead in HTML emails.

But Outlook Windows and Windows Mail do not support border-radius

You can use border-radius as a progressive enhancement so your email would still look presentable in email clients where it doesn't work. If you must have those rounded corners or circles on Outlook Windows, you can use a VML fallback. VML has a number of predefined shapes such as <v:oval> and <v:roundrect> so it is not a huge amount of extra code:

1<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word" style="width:400px; height:200px;" arcsize="3%">
2    <v:imagedata src="https://example.com/image.jpg" />
3</v:roundrect>

3. Inverting colours

If you have images with white/light background and a black/dark foreground, inverting the colours with CSS's filter property can be an option:

1@media(prefers-color-scheme: dark) {
2    .dark-scheme--invert {
3        filter: invert(1);
4    }
5}

On top of that it may make sense to use the mix-blend-mode property in some cases to blend in the image's background with the page's background if it does not match your dark mode background 100%:

1@media(prefers-color-scheme: dark) {
2    .dark-scheme--invert {
3        filter: invert(1);
4        mix-blend-mode: screen;
5    }
6}

See the Pen Invert image colours by Hussein Al Hammad (@hus_hmd) on CodePen.

Email

The prefers-color-scheme media query does not work in all email clients. Neither does the filter property. It is a nice progressive enhancement nonetheless.

Shortly after, Bootstrap 5 alpha was released and they also announced RTL support!

I live in a part of the world where it is becoming extremely common for websites and web apps to offer both English (LTR) and Arabic (RTL) versions. Seeing popular CSS frameworks add built-in support for RTL is a huge plus for many developers in this region, and I certainly hope more open-source projects follow suit.

Having said that, I do realise my role in this and I feel developers (including me) who want to see RTL support in more open-source projects should be contributing to such projects (if they have the required skill set); particularly if it is a small project with a single or very few maintainers.

Output a duoetone icon in single colour:

1echo $FA->get_svg('fad fa-laugh-wink', [
2    'fill' => '#e64980',
3]);

Swap layer opacity by adding the fa-swap-opacity class:

1echo $FA->get_svg('fad fa-laugh-wink', [
2    'fill'  => '#e64980',
3    'class' => 'fa-swap-opacity',
4]);

Single colour with custom opacity:

1echo $FA->get_svg('fad fa-laugh-wink', [
2    'fill' => '#e64980',
3    'secondary' => [
4        'opacity' => '0.2',
5    ],
6]);

Custom colours and opacity:

 1echo $FA->get_svg('fad fa-laugh-wink', [
 2    'primary' => [
 3        'fill'    => '#e64980',
 4        'opacity' => '0.5',
 5    ],
 6    'secondary' => [
 7        'fill'    => '#fcc417',
 8        'opacity' => '1',
 9    ],
10]);

Head to the GitHub repo to learn more.

x-cloak attributes are removed from elements when Alpine initializes. This is useful for hiding pre-initialized DOM. It's typical to add the following global style for this to work:

1<style>
2 [x-cloak] { display: none; }
3</style>

You may want to hide pre-initialised DOM on some screen sizes, but not others. A good example for this is the links in a site's navigation bar, which are typically hidden by default on smaller screen sizes, but are always visible on wider screens.

So instead of hiding all elements with the x-cloak attribute, we can hide only the ones whose x-cloak attribute has no value:

1[x-cloak=""] { display: none; }

This allows us to target elements whose x-cloak attribute has a value:

1[x-cloak="some-value"] { }

So now we can write CSS rules targeting elements whose x-cloak value is mobile, tablet, desktop:

1/* always hidden */
2[x-cloak=""] { display: none; }
3 
4/* hidden on mobile/smaller screens */
5@media screen and (max-width: 768px) {
6    [x-cloak="mobile"] { display: none; }
7}

If you are not familiar with FontAwesomeSVG-PHP, it is a PHP class that inlines Font Awesome's SVG icons without Javascript. It renders the icons on the server side instead of outputting something like <i class="fas fa-file"></i> and have Javascript replace that with the actualy SVG icon on the client side.

What's new?

Automatic aria-labelledby

With the previous version you could add a <title>:

1echo $FA->get_svg('fas fa-file', [
2    'title' => 'File',
3]);

The above outputs something like:

1<svg>
2    <title>File</title>
3</svg>

With the new version you can also add an id to the <title>. If you do, aria-labelledby will be automatically set for you:

1echo $FA->get_svg('fas fa-file', [
2    'title' => 'File',
3    'title_id' => 'file-id',
4]);

1<svg aria-labelledby="file-id">
2    <title id="file-id">File</title>
3</svg>

aria-* attributes

You can now add any aria-* attribute to the SVG tag:

1echo $FA->get_svg('fas fa-file', [
2    'aria-label' => 'File',
3]);

1<svg aria-label="File"></svg>

aria-hidden attribute

Decorative icons should be hidden from screen readers. So aria-hidden="true" is added to the SVG tag by default unless <title id=""> (and hence aria-labelledby) or aria-label is set:

1echo $FA->get_svg('fas fa-file');

1<svg aria-hidden="true"></svg>

What Derrick said about habits vs goals made me think about goal setting again:

I think it is helpful to at least name, if not goals, then what habits I want to form.That's kind of how I'm thinking about it. Habits over goals or specific milestones. And I think that may align better with the try-to-enjoy-the-journey part. What are the things on the day-to-day that I can cultivate as opposed to just striving towards some end-state.

Even though Hannah's article title sounds like it is only focused about learning from missing goals, it also discusses some tips on setting goals. During Syntaxt #67 Wes Bos and Scott Tolinski discuss strategies for goal setting and explain how they set their own goals.

There is a lot to learn from both the article and the Syntax episode. I realise I slip up on my goals management for various reasons (due to increased workload, poor planning, family obligations, etc). So I find it very helpful to re-listen to the Syntax Goal Setting episode every now and then particularly when I plan on setting new goals.

Goals management requires an active, conscious effort. Syntax #67 is a good reminder of this.

Full Stack Radio #102: Paul Jarvis - Staying Small

Full Stack Radio's Adam Wathan "talks to Paul Jarvis about defining your own version of success and why you might not need to build a big business to achieve it."

This is the podcast episode I have listened to the most. I listened to Adam and Paul discuss running an intentionally small business (and still reaching your professional and personal goals) close to 10 times already and I'm certain that I will revisit it again.

I don't think an attempt to summarise this episode would suffice so I highly recommend listening to the episode and reading Paul's book: Company of One.

Building an interface to support both LTR and RTL layouts is a challenge. Flexbox and Grid certainly makes things easier, but they don't cover all our styling needs.

There are many CSS rules we write in which we specify a physical direction or side. For instance, when we write CSS to layout horizontal elements, it is common to set a margin only on a single side and set a margin of 0 (on the same side) to the first or last sibling element.

1.element {
2    margin-right: 1rem;
3}
4 
5.element:last-child {
6    margin-right: 0;
7}

Or

1.element:not(:last-child) {
2    margin-right: 1rem;
3}

In the above example we are adding a margin on the right side of each element except the last. That's how it is written. Though what we mean when we write this is to add a margin after the element in the direction of the horizontal flow of the document (or the parent element).

A common way to style blockquote is to add a border to one side of the quote; the side we consider to come before the quote.

This is Bulma's <blockquote> styling:

1.content blockquote {
2    background-color: #f5f5f5;
3    border-left: 5px solid #dbdbdb;
4    padding: 1.25em 1.5em;
5}

And there are many other styling choices we make in which we specify a side/direction (left/right) in CSS, but what we actually mean is before/after.

So when building interfaces that support both LTR and RTL layouts, one option would be to write CSS rules like:

1.class {}
2 
3html[dir="rtl"] .class {}

Or perhaps even load different stylesheets for LTR and RTL layouts. However, both options require we either write more CSS or set up our tooling to generate the appropriate flipped styles. And there are also tools that convert LTR to RTL styles for you.

Wouldn't it be nice to work with a lower level of abstraction instead? What if we can tell the browser we are targeting the side before/after an element instead of referring to the physical directions left/right? At the end of the day this is what we mean a lot of the times. This reminds me of this tweet.

CSS has what is called logical properties. We can now tell the browser what we actually mean. Instead of using -left and -right, we can use -inline-start and -inline-end:

1.element:not(:last-child) {
2    margin-inline-end: 1rem;
3}

Similarly instead of using -top and -bottom, we can use -block-start and -block-end.

This means we can write one set of rules that target both LTR and RTL layouts. Here is an example using the margin-inline-end property:

See the Pen Logical properties demo: inline list by Hussein Al Hammad (@hus_hmd) on CodePen.

Using the border-inline-start and padding-inline-start properties:

See the Pen Logical properties demo: blockquote by Hussein Al Hammad (@hus_hmd) on CodePen.

Firefox also supports border-*-*-radius so you can target different corners with border-start-start-radius, border-end-start-radius, etc.

See the Pen Logical properties demo: inline form by Hussein Al Hammad (@hus_hmd) on CodePen.

All demos:

See the Pen Logical properties demo by Hussein Al Hammad (@hus_hmd) on CodePen.

For a deeper explanation, you can refer to Rachel Andrew's article Understanding Logical Properties And Values. This is not just about RTL interfaces or horizontal bidirectional CSS rules. Rachel's article also covers logical dimensions.

Browser Support

Can I Use?:

• Logical Properties
• border-*-*-radius

They have a nice simple API for fetching filtered property listings. However, it was unclear to me how to filter the listings by a field whose value is empty or set to a certain value.

The syntax for filtering by a field that is empty:

1Fieldname__c=

The syntax for filtering by a field whose value is either test or unicorn:

1Fieldname__c=IN(test;unicorn)

If you want to filter by a field whose value is empty, test or unicorn, you can do so by prepending an additional ; to your options:

1Fieldname__c=IN(;test;unicorn)

Luckily, we are no longer in the era in which building a bespoke CMS is common for one-off projects. On the other hand, while there are many CMS products in the market we are very much in the era of using (or repurposing) SaaS applications as headless Content Management Systems.

Many applications have nice interfaces, customisable data structures, native mobile apps and developer-friendly APIs. Some even have built-in field types! The ability to build custom extensions provided by some applications also open doors to fill in any gaps in order to utilise them as CMS solutions.

CMS has a competition

Content has a new potential home. CMS products have competition from products that are not classified as a CMS or site builders and, in many cases, not built to solve the same problems. These products can perform many of the same tasks and some may even out-perform traditional CMS products in some aspects.

The bar is a little higher for CMS products nowadays. The expected feature list is a bit longer ranging from built-in third-party integrations to real-time collaboration and from customisability to ease-of-use.

The CMS target audience no longer compares a CMS product only against other CMS products, but also against other digital products. A Content Management System is a digital product after all. When users are exposed to a wider range of digital products and find a feature has become so common amongst these products, they may eventually expect the average CMS to support it too.

What can you use as a CMS?

There are several products you can use as a CMS:

• Google Drive
• Google Sheets
• Airtable / more Airtable / Aritable + Gatsby / even CSS-Tricks has an article on using Airtable as a CMS
• Trello
• Evernote

Zenkit, a SaaS product that offers a good deal of customisability, even suggests on their website that you can use the product as a CMS:

Don’t just manage projects – create a CRM, CMS, ERP, or anything else you need.

And you probably can create your own custom headless CMS solution using Zoho Creator, a low-code platform.

Not a one-size-fits-all

As with almost everything in the tech world, using a digital product that isn't a CMS to manage and deliver content to websites does not suit all use cases. I'm not claiming that. However, this approach is certainly viable.

We've seen site builders compete against CMS products and services such as Squarespace and Wix now serve a market that otherwise would rely on a CMS to power their websites. We've seen many developers ditch CMS solutions in favour for static site generators when possible. So I don't think it is too crazy to consider some SaaS products as alternatives to content management systems, especially when a product like Airtable can also be used for managing other aspects of a business (e.g. project management, CRM).

I do, however, think the headless CMS scene has great options. So unless a company is already using a product for managing other aspects of the business, it probably makes more sense to pick a tool that was designed for managing and delivering content.

For comments, you can go to the DEV.to version of this article.

Blog

While I have not been publishing on this blog consistently, I wrote a lot more on my Perch-focused blog, Pipits. One thing I learned from publishing technical articles is that it helps me more than anyone else. It is true what you hear, you get a better grasp of concepts by explaining them. So this is something I would love to keep doing.

I'm hopefully going to be organised enough to consistently blog on here as well. It's not necessairly going to be all focused on web development, but I can see that being the main topic.

Arabic version

Now that I am back in the middle east, I feel ignorant not having an Arabic version of this site even though the majority of my current clients do not speak Arabic or require websites in Arabic. So I am working on one!

I have not decided whether I am going to start blogging in Arabic as well. It would certainly be nice. I silently complain about the quality of Arabic content on the web and by not publishing any Arabic content I feel I'm somehow part of the problem.

One reason of Font Awesome's popularity is the ease of use. You add a CSS file and a JS file to your document, and you're set. You can then add the icons like so:

1<i class="fas fa-home"></i>

When the SVG icons option was introduced, they kept it just as simple which is great because SVGs are great.

However, you may not necessairly want to load extra Javascript on your PHP application or website just to include icons. And it would be nice to have the SVG icons on there as soon as the page loads - which is one of the benefits of using inline SVGs to begin with.

So I wrote a PHP class to allow me to add the SVG icons almost just as easily. You can find it on GItHub.

1$FA = new FontAwesomeSVG($dir);
2 
3echo $FA->get_svg('fas fa-file');

I've kept the same behaviour when it comes to classes and attributes. And you also still get the auto-accessibility feature.

For semantic icons, the class adds a <title> inside the SVG like the default JS method does. However it does not add the aria-labelledby attribute at the moment.

Example usage

I have also built a Perch app to make it possible to add the SVG icons via PHP or directly in a Perch template. Using the app I can add icons to Perch templates simply like so:

1<perch:fa id="home" icon="fas fa-home" html >

Or via PHP like so:

1pipit_fa_icon('fas fa-home');

There's also a blog on the website about working with Perch and Perch Runway. So I may not post many Perch-related posts on this blog.

The response from the Perch community has been positive and hopefully Pipits for Perch will grow into something very useful to the Perch community.

Logo designed by Sarah Boese.

Vision

I see it not only being useful to the average Perch developer, but also to the front-end developer (and designer) who's not familiar with PHP, to the developer who's using Perch or Runway for the first time and perhaps to the beginner who's looking to perform his first CMS integration.

I remember as a beginner looking to use a CMS for the first time and most of the options I found required the creation of themes which was a turn-off. I just wanted a site with editable content. I didn't want to couple my front-end with a CMS.

So I was really excited when I learned about Perch for the first time (through the Unfinished Business podcast) and how I didn't have to create themes to integrate it with a website. And as I grew as a developer and being familiar with Perch, Perch Runway seemed the obvious choice to use on more complex projects and it also doesn't have the concepts of themes.

A CMS like Perch seems to me like a great option for beginners and as they build upon their skills and start to build bigger, more complex sites they can start using Runway.

The thing is apart from the Perch documentation and forum, there wasn't enough learning resources on the web. Now there's a new resource: the blog on Pipits for Perch which hopefully can help developers/designers regardless of their experience. That's why some of the posts on there discuss some basic usage and others discuss more complex concepts.

You can also find Pipits for Perch on Twitter and GitHub.

Who wants to go through the trouble of filling in a form, remembering yet another password and verifying their email address or phone number? Instead most would rather just do it in two clicks via a social login.

But there doesn’t seem to be a user-centred pattern of implementing a social login. We implement the social login solution to free user from certain tasks, but perhaps we haven’t looked thoroughly enough at the best way to implement this.

Don’t get me wrong; I’m not against social logins. It’s the way it’s implemented that I want to discuss.

Am I signing in or up?

Many websites use ‘sign in with Facebook’ or ‘log in with Twitter’ regardless whether the user is signing in to their existing account or creating a new one. Why confuse your users?

Gitlab, for example, have a section for social logins below their sign in and registration forms. Whether the user is on the ‘Sign in’ form or the ‘Register’ form the section says “Sign in with”.

Do I need to have an existing GitLab account linked to my social media account to be able to sign in using it? How do I register using a social media account? It’s not clear. Thankfully GitLab’s users are a bit more tech-savvy than your average user.

We are forgetful

Using a social login means as a user I don’t have to remember another password. Though it also means I have to remember which social login I use when I sign up to an app. Many apps include multiple social login options (e.g. Facebook, Twitter and Google). GitLab (shown above) uses 4, and I have accounts with 3 of these.

In case you forgot which one you used, it’s not clear to the average user what to do. There’s no guidance. There’s no ‘Forgot your password?’ equivalent.

It is actually easy to figure out which one it was. When you use a social login on a third-party app for the first time, you are asked to authorise the third-party app to access your credentials. If it’s not the first time, you log in straight away.

So in order to figure out which social network you used, you can try to log in with each and see what happens. If you pick Twitter, for example, and Twitter asks you to authorise the third-party app to access your information, then Twitter wasn’t the social network you used for sign up for this app.

Or you could look at the list of the authorised apps on your social media accounts (a lot of work).

Does the average user know this though?

Consider this: a user forgets which social network they used to create their account on a third-party app and they guess it was Facebook. They pick Facebook and get asked to authorise the app to access their Facebook profile information (they never used Facebook to log in to this app before), they confirm the authorisation (thinking they signed up with Facebook and authorising the app is a regular thing they need to do every time they log in) and end up with a new account. They have two accounts now (opps!).

They still have to find out which social network they used to sign up in the first place, then either merge the 2 accounts if the app allow such an option or delete the unintentionally created account.

What if they were aware that Facebook asking them to authorise the third-party app means they never used their Facebook account to sign up to this app? What if you told them? Shouldn’t you?

What if you told them? Shouldn't you?

Even if users are aware of the try-and-eliminate method and/or the fact they can check the authorised apps list on their social media accounts, you still should remind them. Even if they are aware that Twitter asking them to authorise an app means they never used their Twitter account to create an account on your website, you still should remind them.

Why? Humans forget.

I uninstalled the Medium app because of this. I created my account via the browser on my desktop using a social login and later decided to download the app on my phone. I indeed forgot which social media account I used to create my Medium account. The Medium app doesn’t let you access content unless you are logged in (another topic), so whenever you open the app even if it is through a link to a Medium blog post, you are asked to log in to access the content.

I also happened to forget the fact that a social network asks you to authorise an app when you try to log in to an app with said social network account for the first time. So I didn’t think of the try-and-eliminate method at the time. So every time I opened the app, I stared at the log in screen for a few seconds thinking if I pick the wrong social network, I would end up with two Medium accounts. I didn’t want two Medium accounts. So guess what I did? I closed the app every time. Eventually, I uninstalled the app.

So what?

From a UX point of view, I think there should be a way to help the user figure out which social network they used to create their accounts on third-party websites/apps from within the third-party website/app. Be it an automated method or by providing helpful tips.

So far the only app I encountered that put an effort into this is Line. Line allows you to log in with an email address (+password), a phone number or a social media account. I failed to log in with an email address and a password. So I thought I may have used Facebook to sign up. I chose to log in with Facebook, I was asked to authorise the app. At this stage I knew my Line account wasn’t connected to my Facebook account, but I authorised it anyway.

Then Line informed me (perhaps because I chose the ‘sign in’ option rather than the ‘sign up’) that I have never created an account with them using this Facebook account and whether I wished to proceed and create the account.

Bonus rant: I’m forgetful, but not amnesic

Ok so websites and apps allow users to use social logins because humans are forgetful (and lazy). However, I came across some that implement social logins in an unexpected way.

Below is a screen shot of Shahid MBC’s sign up form (it’s in Arabic). At the top you have a Facebook-blue button that reads “sign up with Facebook”. Then you have a horizontal line separating the Facebook button from the sign up form. By looking at it you would think that you have two options for signing up: 1-Social login with Facebook 2-Regular sign up form.

While the design suggests so, “signing up” with Facebook doesn’t actually sign you up. It just retrieves some of your information and fill in your name, email address and gender for you. It also makes these field uneditable. At the end, you still need to enter a password, your date of birth and a freaking captcha.

Instead of signing up to their free trial I chose to close the browser’s tab. I can be forgetful, but I’m not amnesic. I can enter my own name and email address. The reason I wanted to sign up with Facebook is so I don’t have to remember yet another password.

Shahid is just an example. I came across other websites that did the same thing. Interestingly, all these websites are middle eastern based.

The point

Adding social logins to your app provides a great option for your users. Though, Social networks won’t do your work for you. Your app’s sign in/sign up/credential retrieval flow is still part of your user experience. Don’t neglect it. If you can help your users, do it. Users have better things to remember than whether they used Facebook, Twitter or Google to sign up to your app.

When you start mixing your HTML with so many Perch tags, it can get a little messy. Firstly, there can be a lot in there: you have Perch tags that contain many attributes that improve your edit form and have no impact on the HTML rendering such as help, size and divider-before as well as other necessary attributes such as id, type and label. Then you got to think about the order of the fields on the edit form (which can be very different from what you need for your markup) so you start adding order attributes to these tags.

 1<perch:shop
 2  id="short_desc"
 3  type="textarea"
 4  label="Short Description"
 5  markdown="true"
 6  editor="markitup"
 7  size="s"
 8  help="This is displayed above the product options. It should be a concise description that highlights the product's best features"
 9  order="4"
10  divider-before="Product Details"
11/>

In small templates, it doesn’t feel like much. You can see where everything is and edit whatever you want quickly. However, in a big template things can get lost especially if you are reviewing a template you had written a while ago.

What you can do

Generally, you need a Perch template for two tasks:

1. To create (and edit) content/data for an item (product, blog post, etc)

2. To retrieve content and display it on a page

Perch is very flexible, so you can have a template to create the content and use another template to display it on a page. You can create some separation here to make things more manageable, more maintainable.

Example:

The following Perch Shop function uses the default product template (perch/template/shop/products/product.html):

1perch_shop_product('my-product');

By removing all your markup from the default product template (leaving Perch tags only), it will be easier to manage your edit form. You can move tags around as you wish and not worry about using any order attributes. You can focus on making the edit form more logical and user-friendly for your editors/clients without any HTML in your way. The template will be a lot easier to edit in the future.

As for your markup, create another template just for your frontend (HTML output). You can give it a different name and place it in the same directory as the default template, but I prefer to create a sub-directory named frontend and place the file there.

At render time, we always need the id and the type attributes.

You will still need Perch tags inside your frontend template, but you can delete all the attributes from them except the id and type attributes (always needed).

You can delete all the help and note-before attributes (that may have long explanations), order and divider-before that are also purely for the edit form. You can also delete any Perch tags you don't need in your frontend template rather than using the suppress attribute to hide them.

You'll end up with very short Perch tags and potentially fewer of them. Now you can scan through your markup much faster.

Below is a Perch tag with the ID of short_desc. To put into context: it is a short description of a product. On the product page the editor can add a short description and a detailed one. So by adding the help attribute we can give the editors some tips to differentiate between the two fields.

 1<!-- short_desc in template/shop/products/product.html (the template used for the edit form) -->
 2<perch:shop
 3  id="short_desc"
 4  type="textarea"
 5  label="Short Description"
 6  editor="markitup"
 7  markdown="true"
 8  size="s"
 9  help="This is displayed above the product options. It should be a concise description that highlights the product's best features"
10  divider-before="Product Details"
11/>
12 
13<!-- short_desc in template/shop/products/frontend/product.html (the template used for front-end) -->
14<perch:shop id="short_desc" type="textarea" />

Don't forget to edit your perch_shop_product function:

1perch_shop_product('my-product', [
2  'template' => 'frontend/product.html'
3]);

You need to design a table that displays its data in two different units. You want to avoid displaying both sets at once.

I came across this little problem while working on an e-commerce website. The client wanted to display the measurements in their size guide in both centimetres and inches.

The user shouldn’t have to convert the measurements to their unit of preference. And displaying the measurements in both units at once wasn’t a very desirable option. Why should the user go through both units when they only need to see the one they prefer? It’s our job to improve their experience after all.

The Solution

Give the user the option to toggle between both units. If they want to peruse the size guide in centimetres, they can. If their American friend next to them needs to see the measurements in inches, they are just a click/tap away.

Using JavaScript is an obvious option. And given many online stores rely on JavaScript for critical functions (adding items to cart, checkout process, etc), a non-JavaScript method may not seem necessary here. It is possible nonetheless.

Update: based on Heydon Pickering's tweet, this method is not great for accessibility. Proceed with caution!

The method is really simple. We'll rely on a checkbox's state .mycheckbox:checked and use CSS's general sibling selector to target the measurements we want to hide/display.

Here is what we're after:

See the Pen Toggle Table Data with CSS (size guide example) by Hussein Al Hammad (@hus_hmd) on CodePen.

The Code

A size guide is typically presented in a table. The markup for the table here is pretty standard. We'll just include two spans (one for each measurement unit) inside the table's tds.

In order to be able to target these spans with the general sibling selector and based on the checkbox's state .checkbox:checked ~ table span, we need to make the checkbox and the table siblings (i.e. have the same parent element). We also need to place the checkbox before the table. The checkbox doesn't have to be placed directly before the table though.

"The ~ combinator separates two selectors and matches the second element only if it is preceded by the first, and both share a common parent."

Simplified markup

 1<input type="checkbox" id="toggle" />
 2<table>
 3  <tbody>
 4    <tr>
 5      <td>Small</td>
 6      <td>
 7        <span class="default">20 cm</span>
 8        <span class="alt">8 inch</span>
 9      </td>
10      <td>
11        <span class="default">28 cm</span>
12        <span class="alt">11 inch</span>
13      </td>
14    </tr>
15  </tbody>
16</table>

CSS to toggle spans

 1table .default {
 2  display: inline;
 3}
 4 
 5table .alt {
 6  display: none;
 7}
 8 
 9/*checked*/
10.checkbox:checked ~ table .default {
11  display: none;
12}
13 
14.checkbox:checked ~ table .alt {
15  display: inline;
16}

Now it functions as intended. It's a table with a checkbox that toggles the table's data.

By default: we leave the checkbox unchecked and hide .alt spans with CSS. When checked, we hide the .default spans and display the .alt spans

Now all there's left to do is to customise our checkbox to make it look like a toggle switch and add clear labelling. We want these elements next to each other in this order:

1. Main label
2. First (default) measurement unit label
3. Checkbox/custom toggle switch
4. Alternative measurement unit label

There are many examples of custom switches on CodePen. That's a good starting place to get some inspiration.

When coding your own remember this:

Firstly, (as far as I know) you can't use pseudo elements on input[type=checkbox]. In my example, I'm using an empty span for my switch.

The other thing to keep in mind is while you want to hide the checkbox you need it to remain clickable. You want the user to be actually clicking the checkbox when they click on the measurement unit label they want to display. The trick is to set the opacity of the checkbox to 0 (makes it invisible, but remains clickable) and absolutely position it to overlap with the measurement units labels. You may also need to set the checkbox's z-index to a higher value to ensure it's on top (and thus remains clickable).

1<label for="toggle" class="toggle__main-label">Measurements in: </label>
2<label for="toggle" class="toggle__option">CM</label>
3<input type="checkbox" class="toggle__checkbox" id="toggle" />
4<span class="toggle__switch"></span>
5<label for="toggle" class="toggle__option">INCHES</label>

 1.toggle__main-label {
 2  display: inline-block;
 3  vertical-align: middle;
 4  margin-right: 10px;
 5}
 6 
 7.toggle__checkbox {
 8  opacity: 0; /*invisible but it's there (we need to keep it clickable)*/
 9  width: 100%;
10  z-index: 99; /*make sure it's on top so it's clickable*/
11  position: absolute;
12  left: 50%;
13  transform: translateX(-50%);
14  cursor: pointer;
15}
16 
17.toggle__option {
18  display: inline-block;
19  vertical-align: middle;
20  user-select: none;
21}
22 
23.toggle__option:first-child {
24  text-align: right;
25  left: 0;
26}
27.toggle__option:last-child {
28  right: 0;
29}
30 
31.toggle__switch {
32  display: inline-block;
33  vertical-align: middle;
34  position: relative;
35  width: 50px;
36  height: 20px;
37  margin: 0 10px;
38}
39 
40/*focus styles for accessibility*/
41.toggle__checkbox:focus ~ .toggle__switch {
42  outline: 1px solid #19ca2a;
43}
44 
45/*base of toggle switch*/
46.toggle__switch:before {
47  content: "";
48  position: absolute;
49  display: block;
50  left: 50%;
51  top: 50%;
52  transform: translate(-50%, -50%);
53  z-index: 1;
54  background-color: #464646;
55  width: 50px;
56  height: 2px;
57}
58 
59/*move to either side of the base based on checkbox's state*/
60.toggle__switch:after {
61  content: "";
62  position: absolute;
63  display: block;
64  background-color: #171717;
65  z-index: 1;
66 
67  width: 20px;
68  height: 7px;
69  left: 50%;
70  top: 50%;
71  transform: translate(
72    -130%,
73    -50%
74  ); /*position to the left side of the switch base*/
75  transition: transform 0.3s ease-out;
76}
77 
78.toggle__checkbox:checked ~ .toggle__switch:after {
79  transform: translate(
80    30%,
81    -50%
82  ); /*position to the right side of the switch base*/
83}

Last Words

If you want to get a bit fancy, you can detect the user’s country (e.g. from user’s IP address with PHP) and display the unit of choice in their country by default.

Javascript is still an option; you could display the measurements in both units by default and hide the alternative with Javascript (if the script loads). This way users who don’t have Javascript enabled will still be able to view both sets of measurements, and those who have it enabled will be able to toggle the measurements as they wish. Progressive Enhancement FTW.

I haven’t done any accessibility testing. The checkbox is still accessible via the keyboard and the focus styles highlights the custom switch. If you think the checkbox isn’t fully accessible and know how to fix that, please share your thoughts.

The select element is mainly associated with drop-down menus/lists. That's the default after all. You add a select element to a page and you see a white rectangle with an arrow pointing down at one end. You click on it, and based on the default behaviour you see a drop-down list of options for you to choose from.

This is the default behaviour on desktop browsers (and tablets?), but have you ever tabbed on a select element on a mobile browser? There are 2 behaviours I've seen:

1. Options displayed in a popup at the bottom of the screen (where the keyboard pops up)
2. Options displayed in a popup at the centre of the screen

On mobile browsers, users see a list of options but not in a drop-down list. Tabbing the select element when styled using its default styling (white rectangle with an arrow pointing down) doesn't trigger the expected behaviour based on its visual representation. The user doesn't get a drop-down list.

Besides, the W3C's definition of the select element doesn't explicitly describe it as a drop-down list.

"The select element represents a control for selecting amongst a set of options."

So styling the select element differently may make sense in some situations. Here's a semantically correct, pure CSS method to do just that.

What we will do

• Remove the default styling of the select element (including the arrow)
• Position the label to overlap the select element and make it look clickable without affecting functionality or semantics (in reality the user will be clicking the select element not the label)

1<div id="wrapper">
2  <label for="select-options">Change</label>
3  <select id="select-options">
4    <option>Option 1</option>
5    <option>Option 2</option>
6    <option>Option 3</option>
7  </select>
8</div>

All you need is an explicit label and the select element itself (just like you would normally create it).

We need to edit the styling of their parent element. If your markup allows you to apply the below styles without affecting your page's layout, do so. Otherwise, you may need to add a div wrapper.

Now we have an explicit text label using the label element. And we have set the value of the for attribute on the label element to match the value of the id attribute on the select element. This is semantically correct and there shouldn't be accessibility concerns.

Parent Element

1.wrapper {
2  position: relative;
3  width: 300px;
4}

For the parent element, in this case our div wrapper, we set the position property to relative because we will be applying absolute positioning for the label. The width can be whatever suits your layout.

select Element

 1select {
 2  /* remove default styles */
 3  background: transparent;
 4  border: none;
 5  -webkit-appearance: none;
 6  -moz-appearance: none;
 7  appearance: none;
 8 
 9  /* keep on top so it's clickable */
10  position: relative;
11  z-index: 99;
12  cursor: pointer;
13 
14  /* padding-right to prevent text overlap with label */
15  /*  padding-bottom to assist with :focus styling */
16  width: 100%;
17  padding: 7px 70px 7px 0;
18 
19  /* some browsers support text wrap in select element */
20  white-space: normal;
21  font-size: 1em;
22  line-height: 1.35;
23}

Here we remove the default styles of the select element. Setting the appearance property to none is what removes the arrow.

Because we will be absolute positioning the label in an overlapping manner, we have to increase the z-index of the select element to make sure the user can interact with it. Setting the cursor to pointer makes it more user friendly on desktop browsers.

Adding some padding-right will prevent the text of the select element from overlapping with the label. The padding-bottom is needed for the styling of select:focus.

Setting white-space to normal will make the text of the select element wrap to another line if it's too long (doesn't work in all browsers).

Label

 1label {
 2  position: absolute;
 3  top: 50%;
 4  right: 0;
 5  transform: translateY(-50%);
 6  font-size: 0.8em;
 7}
 8 
 9.wrapper:hover label {
10  color: #6feaa2;
11}

We vertically centre the label and position it to the right of the parent element.

The aim is to make the user think they can click/tab on the label to select another option, but in reality they are clicking on the select element. So you may want to style it to look like a button.

Note if you want to change the position of the label, just make sure the select element covers the new position (adjust height, width or padding).

Accessible & Tidy

By default browsers add an outline to focusable elements such as links and some input elements because of accessibility reasons. The outline provides a visual cue for users who are visually impaired or users who are unable to use a mouse. These users often rely on using the Tab key or assistive technologies to navigate through a page.

Leaving the outline for the select element here causes a problem: when it is clicked or in focus the outline overlaps with the label and it looks a bit messy. Removing it also causes a problem: it makes the page less accessible for some users.

Alternative :focus Styling

1select:focus {
2  outline: none;
3  border-bottom: 2px solid #8eb0e7;
4  /* decrease padding-bottom by border-bottom-width */
5  /*  This prevents it from affecting the layout */
6  padding-bottom: 5px;
7}

So here we're defining a custom visual cue for this group of users. It's just a border-bottom, but should do the trick (choose the colour carefully).

Uses & Limitations

The first possible use case is what I discussed at the very start: for mobile devices. You could easily reset the defaults for wider viewports.

Another possible use case is if you want to use the select element not only to provide a control for selecting an option, but also to display the selected option as information. I’ve used it in an audio visualisation experiment in which I made it possible for the user to change the streaming track via a select element. I didn’t want to have a select element where the track title is visible and display the track title some where else as well.

There are some limitations though. Given that not all browsers support text wrap in the select element means the options have to be short to use this method. And since the select element and the label have to overlap, the label text needs to be short as well (unless you position it above or below the select element and increase the select element's height or padding).

I have not done any user testing. I have no idea whether this method will generate any confusion to some users. On the other hand, most users are already familiar with the default styling of the select element, so when they see it they know there are options to choose from straight away.

Your choice of the label text has to be made carefully. Using verbs like 'change' or 'choose' will make it clearer to the user that there is some interaction required.

Browser Support

This solution relies on setting the appearance property value to none which is supported in most browsers with vendor prefixes. IE desktop doesn't support it all, but surprisingly IE Mobile 11 does!

Check browser support

But there are cases where you find yourself working on a project that doesn’t require much JavaScript to justify using Velocity.js (34KB) (or even worse jQuery (84KB)) just to add smooth scrolling. The thing is you don’t have to because there is a very tiny JavaScript module called Zenscroll.

Zenscroll

I came across Zenscroll recently and it quickly became my go-to scrolling module. What’s not to love:

• Tiny: only ~2KB minified, and only 1.1KB gzipped
• Has no dependencies
• Awesome features
• Good browser support

I can already hear you going “holy crap that’s awesome”, but wait there’s more!

The most convenient feature Zenscroll provides is automatic smooth-scolling on links within the same page (can be disabled). So if you literally only want to add smooth scrolling to same page links, then you literally only need to include Zenscroll in your HTML and you’re done. There’s no need to write any JavaScript yourself unless you want to change the default parameters.

Other useful features

• Smooth animated scrolling, using the browser’s built-in smooth-behavior if it’s enabled.

• Scroll to the top of a specific element.

• Scrolling an element into view, making sure both top & bottom are visible, if possible.

• Scroll to an element and center it on the screen.

• Customize the duration of the individual scroll operations.

• If you provide a callback function it will be executed when the scrolling is done.

• Specify the spacing between the element and the edge of the screen (e.g., for fixed navigation bars and footers).

Visit Zenscroll’s Demo Page to learn how to use it

However, there’s one small bug I encountered whilst playing around with it.

The bug discussed below is from an old version of Zenscroll

Problem with Disabling Automatic Smoothing on Local Links

By default Zenscroll takes care of smooth scrolling on local links automatically and that’s reasonable. And you can easily change the default parameters for the automatic smoothing (and all other scrolling):

1var defaultDuration = 777; // ms
2var edgeOffset = 42; // px
3zenscroll.setup(defaultDuration, edgeOffset);

You can disable automatic scrolling all together (why would you?) or on specific links (possible scenario: adding a callback function on scroll completion).

Unfortunately, I found in some browsers when I disable automatic scrolling and add my own Zenscroll behaviour to a click event on a local link, the page jumps to the expected target (no scrolling) then jumps back to the link that was clicked before executing the desired custom Zenscroll behaviour. The problem doesn’t happen every single time, but it was certainly repeatable. This is really the only drawback I encountered with Zenscroll.

Note that this problem doesn’t occur when you use Zenscroll programmatically on elements other than local links.

Callback Function on Local Links with Zenscroll

To add a callback function on scroll completion you normally do this:

1zenscroll.to(element, duration, onDone);
2 
3//example
4zenscroll.to(element, 600, function () {
5  console.log("scroll complete");
6});

But given the problem with local links outlined above, you can use a simple workaround: keep the automatic smoothing and use setTimeOut() to execute your code on scroll completion. Why? Because you know the duration of the scroll; by default it's 999ms or you can set the default value yourself with zenscroll.setup()

Example:

You have a comment/reply link. When clicked it takes you to the comment field on the same page. And on scroll completion you want to give focus to the comment field (textarea element)

Below is a simplified example and not a fully functioning solution

 1<!-- comment -->
 2<a href="#commentField" class="reply">Reply</a>
 3<!-- more comments -->
 4 
 5 
 6.
 7.
 8 
 9<form>
10    <textarea id="commentField"></textarea>
11</form>
12 
13.
14.
15<script src="js/zenscroll-min.js"></script>
16</body><

Add eventListener to all 'Reply' links

1var replies = document.getElementsByClassName("reply");
2 
3for (var i = 0; i < replies.length; i++) {
4  replies[i].addEventListener("click", prepareReply);
5}

Add focus to comment field on scroll completion

1function prepareReply(e) {
2  var commentField = document.getElementsById("commentField");
3  setTimeout(function () {
4    commentField.focus();
5  }, 999);
6}