Cyykratahk

The really funky part of the IE6 PNG fix was that the URL of the image in the expression was always relative to the current page URL, not the CSS file that the declaration was in.

I remember having to use Javascript to generate the image path (I cannot quite remember why absolute or root-relative URLs were not an option for us though...)

A stray "J" I encountered years ago: a certain client's support tickets would often end with a single "J", which was a little confusing as it was not one of their name initials. After a brief investigation, the original email source contained this:

    <font face="Wingdings">J</font>

Which renders as a smiley face.

I owned an Alienware laptop (M17X R4) many years ago that had a dedicated HDMI input.

It was a strange laptop. MXM socketed GPU, 120Hz screen that came with Nvidia 3DVision shutter glasses, and the worst battery life I've ever experienced.

There is some help text when clicking on the current goal amount:

> If an organiser turns on automated goal setting, GoFundMe adjusts their goal automatically based on the fundraiser’s characteristics and performance. You can see the goal history if GoFundMe has ever made automatic updates.

> To help the organiser reach their goal, we start them at a lower goal and adjust it as donations come in.

I'm guessing Google is avoiding the scenario where a contributor "accidentally" commits code with a bug, then later reports the bug they "found".

I'd always assumed the opposite, seeing as a browser's primary function is to parse HTML text into DOM nodes as efficiently as possible.

But on the other hand, since document.write (rightfully) gets such little usage - and has a multitude of footguns - I wouldn't be surprised if browsers used a different, slower code path when executing it; if only to prevent it from borking the parser.

The most obvious downside for me was remote terminal windows (e.g. using ttyd) being unusable because canvas rendering was "broken".

I'd use `yield from` more if I didn't have to re-index arrays before yielding from them:

    function numbers() {
      yield from [1,2,3];
      yield from [4,5,6];
    };
    
    foreach (numbers() as $k => $v) { echo "$k => $v\n"; }
    0 => 1
    1 => 2
    2 => 3
    0 => 4
    1 => 5
    2 => 6

It's great to see more progress around scroll snapping - I'll have to check out this scroll-state container query and the new events.

The biggest missing scroll-snap feature I see is the ability to tell a scrolling container to "snap to the next position in this direction", and maybe by extension "which element(s) are currently snapped". In this article clicking an arrow moves the scroll position by a fixed 40px, but it would be very nice to have a proper API that accounts for element sizes, snap alignments, out-of-axis children, etc.

I ended up writing a package a few years ago that does this (scroll-snap-api). It feels so dirty to calculate the styles on every child in the tree just to find scroll snap positions.

For a long time GA had no method to back up or extract the data. It also excluded itself from ADB backups. One had to root their phone to extract the data.

Woah, those book wheels are like the 16th century version of having 200 browser tabs open.

I've used caddy-docker-proxy in production and it doesn't cause Caddy to drop connections when loading a new config.

I just tested it locally to check and it works fine.