Micros

There are two colour models: additive, and subtractive. Screens use additive colour, where red, green, and blue (RGB) are added to each other to create new colours. Print uses subtractive colour, where cyan, magenta, and yellow (CMY) subtract from white light.

Additive relies on light being emitted from a surface, while subtractive relies on light reflecting off a light surface (like paper), which results in it having a much smaller gamut due to limits on how much light can be reflected. Because it can’t reproduce every colour, spot colours (pre-mixed single-colour inks) such as those from Pantone are commonly used.

Note that the combinations of two colours in RGB provide CMY, and vice versa. Looking at subtractive, one can observe that:

• Cyan absorbs red light (reflects green + blue).
• Magenta absorbs green light (reflects red + blue).
• Yellow absorbs blue light (reflects red + green).

Print actually uses CMYK, the K representing ‘Key’. Though a CMY alone can create dark colours, it isn’t optimal. The colour is often more of a dark brown than a full black, and printing with cyan, magenta, and yellow usually leads to less fine detail, leaving text fuzzy. For this reason, when printing black, there are three primary different methods used. Standard black (also called flat black or single-colour black) is just straight black ink, which is good for detail such as for text, but doesn’t quite reach pitch darkness. Rich black uses CMYK, meaning it uses those CMY colours paired with black (or ‘key’) ink to achieve a darker, more saturated black. Due to multiple layers of ink, some detail is lost, though.

Even darker is registration black, which is 100% of each cyan, magenta, yellow, and key for the darkest black possible. This does mean a lot of ink (400%) is used, however, which often leads to ink bleeding and smudging, longer drying, and warping of oversaturated paper stock. It is worth keeping in mind Total Ink Coverage (TIC) / Total Area Coverage (TAC), which is typically capped at ~240% for uncoated and ~300% for coated. For this reason, it is usually reserved for crop marks, trim lines, and such.

I attended DDD Perth for the second time today. This time, not just as an attendee, but also as a first-time speaker!

I caught a few talks, but there were two standouts of those I saw:

• Matthew Pierce presented Rethinking Web: Can we do more with less? about web platform features that can be embraced in place of frameworks, abstractions, and libraries,
• Sierra McDowell presented The pursuit of spending $0 - building a zero-cost cloud data platform which was a fun, free-tier-exploiting-tale.

One of the issues with a multi-track conference is that there are too many brilliant talks going on simultaneously, and one can’t be in five places at once!

I made a point to be very outgoing and talked to so many people. A few people recognised me from my work and name, which remains an extremely surreal experience, and I got to have interesting hallway chats with such a variety of folks with different skills.

My talk was titled ‘Newly Acquired Powers of the Web Platform’, and I ran through a handful of fantastic new features of the web platform. HTML and CSS have seen so many new additions in recent years, so I ran through text-wrap: balance, flex-wrap: balance, corner-shape, text-box, sibling functions, color-mix(), contrast-color(), invoker commands, scroll-driven and scroll-triggered animations, and view transitions, while cramming mentions of a few more additions in too. Jam-packed! I’d have included more if I wasn’t already on the edge of my time limit.

I had some nerves, though they were mostly pertaining to if my laptop and custom web-based slide deck system would work fine on the AV system of the venue. Rather than replicate the output of the code I was talking about in PowerPoint or similar, it felt proper to use the web directly. Thankfully, everything ran smoothly, and I managed through the presentation without issue. I was late out at the speaker’s dinner at the venue-adjacent pub last night and early rising to get prepared and to the conference, so I only got three and a half hours in the early hours of this morning. Perhaps not optimal, but I managed.

The industry is in a shaky state at the moment, so to have a brilliant community conference with 1000-odd attendees like DDD Perth is a welcome sight. I’m feeling very inspired. My talk is recorded and will be published online at a later date.

All my many thanks go to the volunteers, organisers, other speakers, sponsors, and everyone else that made the event possible.

Whenever I use a semicolon I feel like a pretentious twat.

Looking across the Swan River to the venue I’ll be speaking at feels like the scene in a video game where the title card comes up introducing the boss battle.

On Saturday I’ll be on stage giving my first conference talk across the Matagarup Bridge at Optus Stadium.

Welp, development industry is fucked. What is everyone’s plan B?

There’s nothing more we can do. It’s in the CI’s hands now.

A ‘pixel’ in CSS is not a true pixel as makes up a display.

A pixel in CSS is quite a complex unit, as is explained in CSS Values and Units Module Level 3. A CSS pixel is relative to the reference pixel:

The reference pixel is the visual angle of one pixel on a device with a device pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch).

As far as is needed for development in most cases, a CSS pixel can just be understood to vary a bit between displays. As printed output, of course, doesn’t have pixels, a CSS pixel in print represents 1⁄96^th of an inch.

Using ECMAScript’s devicePixelRatio, the size of a pixel on your display relative to a CSS pixel is unknown. Note that this figure may be unreliable if zoomed in Safari.

Using actual pixels has many issues. One of the most blatant is that many websites would slowly shrink as display technology improves and pixels themselves become steadily smaller. It’d also work oddly with zooming (do you scale a pixel, or leave as is?). Another is that it’d make sites much harder to author and would make responsive design much harder.

My hammer went rogue and started smashing people’s heads in! There was nothing I could do. I tried to stop it, but my arm kept swinging it at people. It isn’t my fault! It is the hammer’s. This is very dangerous. Someone should regulate hammers.

(This is a post about AI safety and liability.)

Over a decade ago I listed myself in my father’s phone as ‘Supreme Overlord’. To this day he hasn’t changed it, and will still say ‘Hey Siri, call Supreme Overlord’ to reach me. Gold.

Unless Halo under Activision reviews extraordinarily well and is free of predatory monetisation strategies, I probably won’t play any future games in the series.

Despite my love for the games, this is likely the killing blow for any excitement I had for future entries. Dreadful.

If ever you search for a song or musical artist on Bluesky, you’re likely to find the results flooded with automated accounts which post whenever a song is played by a specific radio station.

I find this noise rather annoying, so have compiled this moderation list for easily muting them:

https://bsky.app/profile/vale.rocks/lists/3mvyoavalic2m

Rather than the sound of water trickling, which indicates a typical leak, software memory leaks can be identified by the hiss of a fan.

I love the CSS spec’s take on supporting text-decoration: blink.

It may as well say,’Support it, don’t support it, nobody here gives a shit. Probably don’t make stuff blink though. We all know what a mess <blink> was.’

(Even before deprecation, none of the major browsers supported the value.)

The relevant bit of CSS Text Decoration Module Level 4: https://drafts.csswg.org/css-text-decor-4/#text-decoration-line-property

I’ve had quite a number of people tell me to stop bringing up ‘politics’ in my writing. For example, when I’ve decried Elon Musk and David Heinemeier Hansson (DHH) when mentioning X (formerly Twitter) and Omarchy, respectively.

Plainly, no. I will continue to mention injustices and wrongs. Tech is political – especially now.

The only people that are helped by staying quiet about bigotry, racism, fascism, xenophobia, etc, are the bigots, racists, fascists, and xenophobes.

I’ll call it out where I see it, and I urge everyone else to do the same.

I’m sad to say that CSS-Tricks is stuck in limbo again. The site was acquired by Digital Ocean in 2022, and it continued to run under their ownership until February of 2023, when DigitalOcean fired the people working on it. The site stayed latent for a year before DigitalOcean re-hired lead editor Geoff Graham in June of 2024, who got the ship sailing again.

Now, CSS-Tricks sits inactive again. Its future is unclear, because there hasn’t been any communication. DigitalOcean largely just went silent. DigitalOcean is a big company, and it can be expected that things get missed, especially with staff turnover. However, management is a small part of a larger picture.

Only a few days ago, DigitalOcean pledged a $3,000,000 USD donation to Omarchy – a set of scripts and configurations atop Arch Linux and a range of other open-source software (much of which struggles greatly for funding). A set of scripts and configurations which are led by David Heinemeier Hansson (DHH), previously of Ruby on Rails fame, but now of Omarchy notoriety and far-right, racist infamy.

CSS-Tricks being ignored isn’t a matter of effort or time; it is a matter of care. As David Heinemeier Hansson wrote announcing DigitalOcean’s funding:

But the part of this patronage that really made me smile was how quickly it all came together. I reached out to Paddy Srinivasan, DigitalOcean’s CEO, on X on Wednesday. We had a call that same night. I sent a proposal on Saturday. By Sunday, we’d finalized everything.

I know Geoff has been trying to raise CSS-Tricks’ predicament for months, to no avail.

Atop of this, DigitalOcean has ceased the monthly $50 payments they previously gave to GNOME and Flathub infrastructure. Apparently it is a more pressing matter for them to donate to a collection of scripts and configuration files than to contribute to the projects they’re built upon or to pay the writers and editors of their own publication.

Yes, I’ve got skin in the game as someone who has written for the publication, but I’ve got more skin in the game as someone who wishes for a thriving ecosystem and who wants to read the exemplary work CSS-Tricks is known for publishing. There are very few quality publications about the web left, and it would be a major blow to lose another.

I struggle tremendously to read ‘Yahoo!’ without hearing the epitomous yodel echo forth from the crevices of my fracturing mind.

I’m not sure if I spent the last week testing Internet Explorer, or if Internet Explorer spent the last week testing me.

Trying to surf the web while the spider who spun it injects digestive fluids into me and I become a slurry.

The towers are gone now, reduced to bloody rubble, along with all hopes for Peace in Our Time, in the United States or any other country. Make no mistake about it: We are At War now — with somebody — and we will stay At War with that mysterious Enemy for the rest of our lives.

From Fear & Loathing in America by Hunter S Thompson. Published September 12, 2001.

Sometimes you just need Internet Explorer 11. I won’t question why you need it, but here is how you can open it natively in Windows 11. If you try to execute iexplore.exe from C:\Program Files\Internet Explorer or via Run, Windows will instead open Microsoft Edge. There used to be various links around Windows’ interface which hadn’t been updated to Edge and thus could be used as a gateway. Unfortunately they’re almost all removed now so some slightly more complex methods are required.

The easiest method is to use this short PowerShell command: $ie = New-Object -ComObject InternetExplorer.Application; $ie.Visible = $true. Run it in PowerShell and Internet Explorer will open.

Another good approach is to create a Visual Basic Script (a file with the extension .vbs) with the below contents. When the script is run, Internet Explorer will open.

CreateObject("InternetExplorer.Application").Visible = True

In most cases you’re best to use Microsoft Edge’s Internet Explorer mode.

Accurate as of Windows 11 version 25H2.

They’re trying to pry me away from the keyboard. They’re saying something about the browser going supercritical. They’re saying that the rendering engine is melting down. They’re yelling ‘Please! Please stop. Stop aligning so many divs!’. They’re watching as my computer begins to glow a hot red.

Not my monkeys, not my circus.

Not my divs, not my browser DOM.

In regard to my assertion that initial-scale=1 is no longer a necessary default, some people complained that in its absence a page which would otherwise horizontally extend beyond the viewport will be scaled so that the document’s full width fits the width of the viewport.

If initial-scale=1 comes into play, then your site is already broken. With or without initial-scale=1, you’re failing multiple WCAG criterion. Most obviously, 1.4.10 Reflow. You need to fix this problem urgently. Regardless of how you feel about positive fallbacks in behaviour, content overextending horizontally requires fixing. It is also a major usability failing for all users either way. With that in mind, I additionally think that omitting initial-scale=1 is preferable in the case that an overflow does reach production (which, as we have established, it mustn’t) because:

1. It makes horizontal overflows much more obvious and thus more likely to be noticed and fixed. Including initial-scale=1 to mask the issue disincentivises fixing the actual root cause. Beyond being more obvious to people, it is also more likely to be caught by visual regression testing.

2. With initial-scale=1 you risk having content off-screen which cannot be focused by a keyboard, which fails under WCAG 2.1.1 Keyboard.

3. It provides a better user experience. Horizontal scrolling in general (such as is required by initial-scale=1) is an uncommon interface pattern, and horizontal overflows are even more uncommon due to being unintended. A user is extremely unlikely to think to scroll horizontally to see the rest of a document.

   However, what is a common pattern is zooming in and panning. People will zoom in and pan around images, PDFs, and the likes. It is a familiar pattern, unlike scrolling horizontally on a page that otherwise seems scaled to the device. There is even great precedent for it with documents on the web, given that desktop-only sites are zoomed in upon and panned around in this way.

4. Without it set, content isn’t arbitrarily hidden. When content on a page horizontally overflows, you cannot see what has overflown until you act to scroll over to it or zoom out to see the full picture. Without initial-scale=1 the user is shown the full content with the ability to zoom in on what they were actually trying to access.

5. People often pair initial-scale=1 with overflow-x: hidden in their CSS, which makes any content overflowing completely unreachable. Not having it as a default avoids walking into this trap.

Regardless, initial-scale=1 doesn’t make sense to include as a default for a case that should never reach production and which is an obvious issue. Prior to the iPhone bug that popularised initial-scale=1 it wasn’t needed. Now it is fixed, it isn’t needed as a default. If one does decide they really want to include it, then they can, but that should be a conscious choice and not the result of tradition.

The year is 1996. You’re being inconvenienced by bespoke Internet Explorer behaviour.

The year is 2026. You’re somehow still being inconvenienced by bespoke Internet Explorer behaviour.

The year is 2032. This is the earliest year that Internet Explorer could possibly lose support entirely. In your gut you know it’ll probably live for longer somehow.

The year is 3794. You’re long dead, yet somehow Internet Explorer still torments you.

With increasing frequency and disruption, I’m seeing people hide sites behind bot protections or kill them altogether just to prevent the content on them from being used for AI training. I generally think this is bad.

I can understand such a decision from the perspective of scrapers running up financial costs. Sure, you shouldn’t have to pay so that some company that doesn’t care about you in the slightest can overwhelm your website. Depending on your hosting and structure, it could be a significant financial burden. However, when people put up aggressive blocks or take down their site because of ideological disagreements with scraping or AI in general, it feels misguided.

Piling up anti-bot protections does very little to stop determined bots. Even less determined bots are often able to bypass protections, as they rarely hold up for long. Aggressive scraping operations will spin up full versions of Chrome from residential IP addresses and will scrape your site, even if it takes a while. Most protections are security theatre. In many cases protection solutions are directly associated with AI companies – like a protection racket.

Most protections do harm actual people, though. Having their phone come to a halt while it heats up to solve the complex maths of Anubis, or having to perform some asinine CAPTCHA task that likely isn’t completable for many people with accessibility considerations, or getting held up by a few seconds of delay when loading up a page. At the scale of AI systems, they can automate bypasses for most of these protections. It is individual people that are being inconvenienced.

I’ve heard the argument, ‘But at least I’m inconveniencing the scrapers or making them do more work’. Think about the financial figures flung about the AI space. To scrape sites costs a pittance and doesn’t inconvenience AI companies at all. All that is necessary is for your content to be scraped once, and it is in the training data forever after. It was likely scraped before you even considered blocking them, and it only takes one slip-up of even a hypothetical perfect protection for a site to end up in a data set.

I get the anger and feelings of violation. I agree that it isn’t right for scrapers to act as they do and for companies to exploit the openness of the web. However, at the point where we inflict more damage to humans than we do to AI, what is the point? Is our primary goal to do good for ourselves and other people on this planet, or to make weak attempts at inconveniencing AI? Why are you blocking scrapers? Is it to protect human creativity or to protect humans from your creativity? To reduce human expression in the face of automation is to concede to the machine.

I’m sure this sounds, to an extent, like I’m trying to be an AI apologist or that I’m saying you should give in to AI. If this is what it sounds like, then you’re misinterpreting me. My view is just that we should, as people, prioritise expressing ourselves and doing good for other people rather than harming people to spite AI.

It makes me sad when people stop maintaining personal websites for the reason that AI will scrape it.

Bad people might visit your site but that has never been a reason to stop. Make great stuff and share it.

Killing your site hurts people much more that it hurts AI, and keeping it benefits people much more than it benefits AI.

When reading articles by accessibility professionals, you can identify how long they’ve been in the field by how jaded their writing is and how aggressively they’ve countered every single conceivable rebuttal.

I loaded up a website and immediately found what I was looking for, but it was on a carousel and it slid away. The carousel had no buttons and the site markup was a mess so I just had to wait for the carousel to go through a full cycle and return to the start so I could click the link.

Torturous.

It shouldn’t need saying, but please don’t do this. Ideally just don’t do carousels at all.

For Interop 2027 I’d like to propose interoperability, where all the browsers reach greater feature parity and fix bugs while improving performance.

A line you will find in the head of almost every single HTML document: <meta name="viewport" content="width=device-width, initial-scale=1.0">

The line came into relevance after the first iPhone launched in 2007. As part of the same keynote at Macworld 2007 in which Steve Jobs unveiled the iPhone, he showed off the phone’s web browser loading the New York Times and Amazon. As he proclaimed on stage, the iPhone did not load mobile versions of the sites but instead the full desktop versions.

Mobile versions of websites at the time were usually on their own subdomain or path and were extremely simplified experiences. The iPhone ran the full versions. However, these sites weren’t designed for such small screens. Ethan Marcotte wouldn’t coin ‘Responsive Web Design’ until 2010. The intended interaction was for the user to zoom in and pan around sites designed for desktop.

To allow sites designed for small screens to scale nicely, Apple introduced the viewport meta tag as explained in the Safari Web Content Guide. The viewport meta tag was eventually picked up more universally across browsers such that it became the widely supported way to make a site responsive.

Though width=device-width handled things broadly, initial-scale=1.0 was important for many years to resolve undesired zooming behaviour in older versions of iOS and some other browsers. However, this isn’t the case any more. All the problems are no longer present and don’t need working around.

I can say with confidence that you do not need to declare initial-scale=1.0 if targeting modern browsers. All you need is <meta name="viewport" content="width=device-width">. That’s 19 bytes you can shave from your document head. Maybe not much in isolation, but when you consider the scale of the web, it adds up.