Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
163408 stories
·
33 followers

Coffee and Open Source Conversation - Jonathan Archer

1 Share
From: Isaac Levin
Duration: 1:05:41
Views: 4

Jonathan Archer is co-founder and CEO of OpenLLM, an AI gateway that specializes in subscription routing. He specializes in go-to-market strategy and finding product-market fit.

You can follow Jonathan on Social Media
https://x.com/apewithllm
https://www.linkedin.com/in/jonathan-archer1/

Also be sure to check out OpenLLM
https://www.openllm.sh/
https://x.com/OpenLLMsh
https://github.com/openllmsh

PLEASE SUBSCRIBE TO THE PODCAST

- Spotify: http://isaacl.dev/podcast-spotify
- Apple Podcasts: http://isaacl.dev/podcast-apple
- Google Podcasts: http://isaacl.dev/podcast-google
- RSS: http://isaacl.dev/podcast-rss

You can check out more episodes of Coffee and Open Source on https://www.coffeeandopensource.com

Coffee and Open Source is hosted by Isaac Levin (https://twitter.com/isaacrlevin)

Read the whole story
alvinashcraft
just a second ago
reply
Pennsylvania, USA
Share this story
Delete

Things are looking up

1 Share

Dave and Chris catch up on appliance repair nightmares, major career announcements, and hardware security threats. Dave shares his frustration attempting to fix a top-of-the-line Miele washing machine door interlock, while Chris recalls diagnosing a failed dishwasher sump pump. Chris then announces his new role as Developer Relations Lead at Hubble Network%, detailing their hybrid terrestrial and satellite Bluetooth infrastructure. The discussion shifts to semiconductor physics with Dave’s video on light erasing LCD pixels, cybersecurity supply chain vulnerabilities on Ledger crypto hardware wallets, AI voice-changing phone scams, the official End-Of-Life (EOL) of the Zilog Z80 microcontroller, running WebAssembly SDRs on an ESP32-S3, and open-source silicon with Bunnie Huang’s daBao RISC-V chip.

Timeline

  • Dave and Chris kick off the episode complaining about persistent microphone and gain issues in the studio. (00:00:30)
  • Dave details his ordeal trying to find spare parts for a failed Miele W1 washing machine door interlock teardown. (00:01:15)
  • They reminisce about washing machine “fuzzy logic” marketing from back in the day compared to modern AI buzzwerds. (00:01:45)
  • Dave breaks down the complex mechanical solenoid interlock required by European safety standards and the pain of shipping delays. (00:02:45)
  • Discussing the economics of white goods repair: repair technician quotes ($1,300 interlock + mainboard) versus buying a brand-new appliance. (00:06:15)
  • Chris shares his own recent experience diagnosing a failed sump pump on an 8-year-old dishwasher. (00:08:45)
  • Comparing basic household appliance automation to the extreme complexity and risks of home humanoid robots. (00:11:15)
  • The mystery of dishwasher wash cycles: why the 1-hour power wash uses less water than the eco mode according to the display. (00:12:45)
  • Chris announces “things are looking up” with his new role as Developer Relations Lead at Hubble Network, following up on Episode 728 with Alex Haro. (00:14:15)
  • Overview of Hubble’s hybrid Bluetooth architecture: a terrestrial network using 100M+ participating devices alongside satellite relays. (00:15:00)
  • How standard 2.4 GHz Bluetooth commercial off-the-shelf (COTS) chips use FSK narrowband modulation to transmit data directly to orbit. (00:17:30)
  • Satellite link budgets and power requirements: dropping from +20 dBm external preamps today down to +4 dBm for next-gen satellites. (00:19:00)
  • Reviewing Hubble’s terrestrial hexagon coverage map and plans to scale from CubeSats to larger, more sensitive satellites. (00:19:45)
  • How background location partner apps like Life360 help backhaul terrestrial Bluetooth advertisements. (00:21:00)
  • Satellite overpasses in North America (1–2 passes per day) and developer tooling for calculating satellite pass windows. (00:23:00)
  • Chris reflects on his 5-year tenure at Canonical (makers of Ubuntu) and staying dynamic in tech careers. (00:24:15)
  • A look at corporate identity: why Canonical kept its name rather than renaming to match its famous Ubuntu brand. (00:26:30)
  • Dave explains his video on erasing LCD pixels with light, diving into TFT storage capacitors and amorphous silicon band gap physics. (00:27:45)
  • Chris accidentally drops a Seeed Studio 60 GHz radar heartbeat monitor live in the lab while discussing physics. (00:30:00)
  • Teaching kids about physics: Dave shares how bringing a thermal camera into a kindergarten class demonstrated invisible light through a garbage bag. (00:33:45)
  • Nostalgic action movies that hold up: Predator, Terminator 2, and Jurassic Park’s “spare no expense” practical effects. (00:36:00)
  • Supply chain security issues explained: physical interception, seed phrase theft, and hardware wallet tampering. (00:38:00)
  • Elaborate hardware wallet scams: pre-printed fake seed phrase sheets, shipping company database breaches, and bogus CEO replacement letters. (00:41:45)
  • Credit card skimmers at gas pumps, fake ATM front panels, and a $100M supply chain hack via a Malaysian authorized reseller NDA purchase. (00:43:30)
  • The rise of AI voice-changing phone scams: Dave’s 25-minute call with scammers impersonating Australian Federal Police using real-time voice translation. (00:47:15)
  • Open-source CAD updates: the new FreeCAD release, plain-text CAD workflows, and Model Context Protocol (MCP) integrations. (00:51:00)
  • Dave’s video on getting paid $175/hr to eliminate your own PCB design job and single-prompt automated PCB/schematic generation tools. (00:53:00)
  • Reflecting on Episode 736 with Eric Pan and how Shenzhen manufacturing automation connects with AI hardware design outputs. (00:56:00)
  • Hacked YouTube creator channels (Kiss Analog & Learning Electronics Repair): session cookie hijacking via fake CAPTCHas on vintage datasheet websites. (00:57:30)
  • The end of an era: Littlefuse / IXYS officially places the iconic Zilog Z80 microcontroller on End-Of-Life (EOL) after 50 years. (01:01:00)
  • Asianometry’s video on Exxon’s Office Fling detailing Zilog’s history and Exxon’s foray into office automation. (01:02:45)
  • Modern browser capabilities: running Xbox games in browser windows via WebGPU and browser-based emulation. (01:04:00)
  • Chris’s internal prototyping tool: running Python in WebAssembly via WebSerial to process raw 2.4 GHz IQ data from an ESP32-S3 as a browser-based SDR. (01:04:45)
  • Dave and Chris add an ESP32 footprint to the Micro Timer project, opening up the possibility of connecting the timer directly to space. (01:09:15)
  • Crowd Supply versus Kickstarter: Mouser integration and Bunnie Huang’s custom daBao RISC-V co-processor products on Crowd Supply (why the daBaos were late). Cross-links to past interviews with [Bunnie Huang (Episode 260)]](https://theamphour.com/230-an-interview-with-bunnie-huang/) and Sean ‘xobs’ Cross (Episode 521). (01:12:00)
  • The open-source versus closed-source silicon security debate: why full RTL transparency doesn’t automatically prevent hardware exploits. (01:16:30)
  • Show wrap-up and a sneak peek at next week’s interview with the CTO of Ambiq. (01:17:30)




Download audio: https://traffic.libsyn.com/theamphour/TheAmpHour-737-ThingsAreLookingUp.mp3
Read the whole story
alvinashcraft
17 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Random.Code() - Resurrecting Partial Function Application in C#, Part 2

1 Share
From: Jason Bock
Duration: 50:46
Views: 33

In this stream, I'll continue the work to get my PartiallyApplied library up and running again.

https://github.com/JasonBock/PartiallyApplied/issues/23

#dotnet #csharp

Read the whole story
alvinashcraft
25 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

Powering the Agent Development Lifecycle with any framework, from ADK to LangChain and beyond

1 Share
The Agents CLI Extension System enables developers to use frameworks like LangChain, LangGraph, or custom enterprise stacks while retaining a unified deployment and evaluation workflow. It details a first-party LangChain template that scaffolds, runs, and deploys agents without requiring the Agent Development Kit (ADK). Additionally, it demonstrates how platform teams can author custom extensions to enforce policies such as automated software bill of materials (SBOM) scans during deployment.
Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete

Qwen and Gemma With Thinking On: Thinking Pays Qwen on Tool Calls, Gemma Still Leads

1 Share

This article follows Comparing Qwen and Gemma on the Low End, which ran Qwen3.5-2B and Gemma 4 E2B with thinking off. Here both models think, on the same card, the same llama.cpp binary and the same 4-bit files.

https://github.com/xbill9/qwen-dev/tree/main/local-llamacpp-1650ti-qwen352b-q4_0

Thinking is worth 17.7 points to Qwen3.5-2B on BFCL tool calling and nothing measurable to Gemma 4 E2B. On GSM8K math, thinking alone adds 3.7 points to Qwen, a range that includes zero. With both models thinking, Gemma still leads by 10.3 points on math and 5.0 on tool calls. Qwen's thinking runs to a median of 7,607 tokens per math answer against Gemma's 808.

What is this project trying to Do?

The first article found Gemma 4 E2B ahead of Qwen3.5-2B on every task, with thinking off for both. Qwen3.5 is built to think, so the first question a Qwen user asks is what happens with thinking on.

This article answers it on the GTX 1650 Ti, a 4 GB laptop card, for the two generation tasks: GSM8K math word problems and BFCL simple tool calls. Both models run as 4-bit GGUF files: Qwen's standard Q4_0 and Gemma's QAT Q4_0.

At This Point You Should Have…

  • An NVIDIA GPU with a CUDA driver — here a GTX 1650 Ti (4 GB, Turing)
  • llama.cpp built with CUDA — commit 7182ef71e here
  • The two GGUF files from the first article: Qwen3.5-2B-Q4_0.gguf and Gemma's gemma-4-E2B-it-q4_0-exact.gguf
  • Python 3 for the task runner — the system python3, no virtualenv
  • The repository cloned, and jev-tpu-v5e1/ holding gen_eval.py

Step 1 — Turn Thinking On

One server flag turns thinking on for both models:

llama-server -m Qwen3.5-2B-Q4_0.gguf --host 127.0.0.1 --port 8080 -ngl 99 \
  -c 131072 --parallel 4 -ctk f16 -ctv f16 -fa 1 -t 6 -tb 12 --reasoning on --metrics

llama-server puts the thinking in message.reasoning_content and the answer in message.content. Only content is scored; the task runner keeps the thinking in each record for reading later.

-c 131072 --parallel 4 gives each of 4 slots 32,768 tokens, so a request has room to think. The server log confirms the split:

0.01.412.127 I srv    load_model: initializing, n_slots = 4, n_ctx_slot = 32768, kv_unified = 'false'

Step 2 — Use Each Vendor's Sampling Settings

The thinking-off runs used greedy decoding. With thinking on, greedy decoding breaks Qwen. On 16 GSM8K problems with an 8,192-token limit:

trial-greedy-8k/gsm8k-qwen.jsonl: n=16 limit=8192 right=5 hit_limit=11 ends_in_loop=9 still_thinking=11

Qwen got 5 of 16 right. It hit the limit on 11, every one still thinking, and 9 of those ended in one sentence repeated dozens of times:

    Wait, I need to check if the prompt requires the thinking steps to be in the final output. Yes.
    Okay.
    Wait, I need to check if the prompt requires the thinking steps to be in the final output. Yes.
    Okay.

Qwen's model card gives settings for thinking mode, and Gemma's generation_config.json gives its own:

Qwen3.5-2B, thinking mode for text tasks: temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0
Gemma 4 E2B: "temperature": 1.0, "top_k": 64, "top_p": 0.95

Each model ran at its own vendor's settings. gen_eval.py merges them into every request from one variable:

JEV_SAMPLING='{"temperature":1.0,"top_p":0.95,"top_k":20,"min_p":0.0,"presence_penalty":1.5,"repeat_penalty":1.0}' \
JEV_GEN_MAX_TOKENS=32000 python3 gen_eval.py run http://127.0.0.1:8080 Qwen/Qwen3.5-2B gsm8k gsm8k-qwen.jsonl \
  --ids gsm8k-300-ids.txt --concurrency 4

Step 3 — Give Thinking Room

Qwen's card recommends an output length of 32,768 tokens for most queries. Both models got a 32,000-token limit on both tasks.

At that length Qwen's math takes hours on this card, so GSM8K is a fixed random 300 of its 1,319 problems, drawn once with a fixed seed and used for both models. BFCL is all 400. With thinking off, the 300 score Qwen at 0.730 and Gemma at 0.927, against 0.734 and 0.901 on all 1,319: the sample matches the full set for Qwen and favours Gemma by 2.6 points. Gemma's math leads below are about 3 points larger than the full set would give: with thinking off its lead is 16.7 points on all 1,319 and 19.7 on the 300.

Step 4 — Score Both Models

Each model with thinking on is paired question by question against its own thinking-off records on the same 300 problems and 400 requests, with a 95% range from 10,000 resamples:

GTX 1650 Ti Qwen off Qwen on Gemma off Gemma on
GSM8K, 300 0.730 0.827 0.927 0.930 🥇
BFCL simple, 400 0.688 0.838 0.917 🥇 0.887
Thinking on − thinking off Change 95% range
Qwen, GSM8K +0.097 +0.043 to +0.150
Qwen, BFCL +0.150 +0.100 to +0.198
Gemma, GSM8K +0.003 −0.023 to +0.030
Gemma, BFCL −0.030 −0.058 to −0.005
Gemma's lead over Qwen GSM8K BFCL
Both thinking off 19.7 points 23.0 points
Both thinking on 10.3 (6.3 to 14.3) 5.0 (1.3 to 9.0)
Gemma off, Qwen on 10.0 8.0
  • Qwen rises 9.7 and 15.0 points, both ranges clear of zero.
  • Gemma is level on math and loses 3.0 points on tool calls. Gemma with thinking off still beats Qwen with thinking on.
  • On BFCL, Qwen now calls the tool. Replies with no tool call fall from 88 of 400 to 8. Its misses are now mostly wrong argument values.

Step 4 changed two things at once: thinking, and greedy decoding to each vendor's sampling. Step 5 separates them.

Step 5 — Separate Thinking From Sampling

One more run holds the sampling and turns thinking off: the same server, files, limit, problems and settings as Step 4, with --reasoning off. The greedy runs kept the first article's 2,048 and 512-token limits, and the sampled runs had 32,000, so the first step changes the sampling and the limit together. Three runs per model, compared in pairs:

GTX 1650 Ti Greedy, thinking off Vendor sampling, thinking off Vendor sampling, thinking on
Qwen, GSM8K 0.730 0.790 0.827
Qwen, BFCL 0.688 0.660 0.838
Gemma, GSM8K 0.927 0.910 0.930 🥇
Gemma, BFCL 0.917 🥇 0.885 0.887
Change, 95% range Sampling and limit Thinking alone
Qwen, GSM8K +0.060 (+0.003 to +0.117) +0.037 (−0.013 to +0.087)
Qwen, BFCL −0.028 (−0.068 to +0.013) +0.177 (+0.128 to +0.228)
Gemma, GSM8K −0.017 (−0.047 to +0.010) +0.020 (−0.010 to +0.050)
Gemma, BFCL −0.033 (−0.055 to −0.013) +0.003 (−0.025 to +0.030)
  • On tool calls, thinking is the whole of Qwen's gain: +17.7 points. With thinking off, Qwen still answers 83 of 400 in prose; with thinking on, 8.
  • On math, thinking adds 3.7 points to Qwen, a range that includes zero. The other 6.0 points come with the sampling and the longer limit together. Greedy, 26 of 300 replies reached the 2,048-token limit, 24 of them with no loop at the end; with the card's settings and 32,000 tokens, 4 of 300 reached the limit. Scored as right, those 26 would put greedy at 0.797, level with the sampled 0.790.
  • Gemma's 3-point BFCL loss is the sampling. Gemma's greedy replies stayed well inside both limits (longest 1,586 tokens on math, 92 on tool calls), so for Gemma that column is sampling alone. Thinking changes neither of Gemma's scores beyond its range.

At matched settings Gemma leads by 12.0 and 22.5 points with thinking off, and by 10.3 and 5.0 with thinking on.

Step 6 — Count What Thinking Costs

From the records and the task runner's own wall times, 4 requests at a time:

qwen gsm8k: n=300 right=248 wall_s=36269.8 wall_min=604.5 wall_h=10.07 s_per_right=146.2 tokens_total=3407907 tokens_per_right=13742 tokens_median=7607
qwen bfcl: n=400 right=335 wall_s=1456.4 wall_min=24.3 wall_h=0.40 s_per_right=4.3 tokens_total=109946 tokens_per_right=328 tokens_median=160
gemma gsm8k: n=300 right=279 wall_s=1872.6 wall_min=31.2 wall_h=0.52 s_per_right=6.7 tokens_total=270970 tokens_per_right=971 tokens_median=808
gemma bfcl: n=400 right=355 wall_s=949.5 wall_min=15.8 wall_h=0.26 s_per_right=2.7 tokens_total=117153 tokens_per_right=330 tokens_median=284
GTX 1650 Ti, thinking on Qwen Gemma
GSM8K reply, median tokens 7,607 808 🥇
GSM8K tokens per right answer 13,742 971 🥇
GSM8K seconds per right answer 146.2 6.7 🥇
GSM8K, 300 problems 10.1 hours 31 minutes 🥇
BFCL tokens per right answer 328 🥇 330

On math, Qwen spends about 14 times Gemma's tokens and 22 times its time for each right answer. On tool calls the two spend the same tokens.

31 of Qwen's 300 math replies used all 32,000 tokens; 20 of them were still thinking and 21 ended in repeated text. Scoring all 31 as right gives Qwen 0.913, still below Gemma's 0.930.

🔎 Tip: Do Not Run Qwen Greedy

Greedy decoding is the usual setting for repeatable scores. With thinking on it loops Qwen: 9 of 16 math problems ended in repeated text, and 5 of 16 were right against 12 of 16 at the card's settings. Use the card's settings, and keep presence_penalty in them; it is the one aimed at repetition.

🔎 Tip: The Token Limit Covers the Thinking

max_tokens counts thinking tokens as well as the answer. A limit sized for thinking-off answers (512 for tool calls, 2,048 for math here) cuts a thinking model off mid-thought, with an empty content. Size the limit, and each slot's share of -c, for the thinking.

Compare and Contrast

GTX 1650 Ti, thinking on Qwen3.5-2B Q4_0 Gemma 4 E2B QAT Q4_0
GSM8K / BFCL 0.827 / 0.838 0.930 / 0.887 🥇
Gain from thinking alone +3.7 / +17.7 +2.0 / +0.3
Gain from sampling and limit +6.0 / −2.8 −1.7 / −3.3
GSM8K median reply 7,607 tokens 808 tokens 🥇
GSM8K, 300 problems 10.1 hours 31 minutes 🥇
Greedy thinking loops runs 🥇

So, Which One?

Gemma 4 E2B, with thinking off and greedy decoding. It scores higher than Qwen with thinking on, on both tasks, and answers math in a fraction of the time.

If you use Qwen, use its card's sampling settings, and turn thinking on for tool calls: it is worth 17.7 points there for few tokens. On math, thinking adds 3.7 points that may not be real, at 14 times Gemma's tokens per right answer. Leave Gemma's thinking off for these tasks; it gains nothing.

Summary

The goal of this article was to measure Qwen3.5-2B and Gemma 4 E2B with thinking on, where the first article ran them with thinking off. The key to the solution was running each model at its vendor's thinking-mode sampling with room to think, and a third run with the same sampling and thinking off, so that thinking's effect is measured with everything else held, question by question. The results were:

  • 🟢 Thinking lifts Qwen on tool calls: +17.7 points on BFCL, with replies that skip the tool down from 83 to 8.
  • ⚠️ On math, thinking adds little to Qwen: +3.7, a range that includes zero; the other +6.0 came with the card's sampling and the longer limit together.
  • ❌ Thinking does not lift Gemma: +2.0 on GSM8K and +0.3 on BFCL, neither clear of zero.
  • 🟢 Gemma still leads: by 10.3 and 5.0 points with both thinking, and by 10.0 and 8.0 with only Qwen thinking.
  • ⚠️ Qwen's math thinking is expensive: 13,742 tokens and 146 seconds per right answer, against Gemma's 971 and 6.7.
  • ⚠️ Greedy decoding loops Qwen's thinking; its card's sampling settings fix it.

Scope: one GTX 1650 Ti (4 GB), llama.cpp 7182ef71e, the same Q4_0 files as the first article, measured 2026-10-18 and 2026-10-19. Two tasks: GSM8K on a fixed random 300 of 1,319 problems and BFCL simple on all 400; the classification suite was not run with thinking on. The two sampled runs used each vendor's thinking-mode sampling and a 32,000-token limit, 4 requests at a time, once per model; the greedy thinking-off records are from the first article's runs, with 2,048 and 512-token limits, 8 at a time. Thinking with greedy decoding was run on 16 problems only. Each sampled setting was run once, and a re-run gives different text, so the 95% ranges cover the choice of questions but not run-to-run variation. With --reasoning off, Gemma still wrote reasoning on 26 of 400 sampled BFCL replies, 25 of them right; the greedy runs have none. The task prompts and scoring code were written for this repository's Gemma work.

The strategy for measuring thinking on Qwen3.5-2B and Gemma 4 E2B on a local GPU was validated with an incremental step by step approach.

References

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete

When the Web Was Actively Trying to Kill You: A Field Guide to Early Front-End Lore

1 Share

In the ongoing retrospective series I have kicked off on LinkedIn and YouTube about the maturation of the web platform, I am going to be focusing on how Boston and Cambridge served as ground zero for modern front-end engineering between 2008 and 2013.

We will talk about the launch of HTML5 Boilerplate, the transition to automated build systems, and the moments JavaScript went from a despised browser toy to an enterprise-grade discipline.

Before you can fully appreciate why we spent so much energy building those tools, you have to understand the hostile operating environment we were trying to escape.

If you entered front-end engineering in the last decade, you grew up believing browsers are cooperative runtimes. You think a rendering engine is broken if a CSS flexbox rule behaves unexpectedly on mobile Safari.

Let me take you back to an era when the web platform was pure trench warfare.

1. Table Layouts and the Load-Bearing Spacer GIF

Before CSS layouts stabilized, we did not align elements with math or anything approaching an elegant solution. We built layouts through structural abuse. If a client needed a header, a navigation sidebar, and a three-column content area, that meant nesting <table> tags seven layers deep.

To prevent empty table cells from collapsing, every commercial website on earth carried an invisible architectural wedge: the transparent one-pixel GIF (spacer.gif). You set its width and height explicitly in HTML attributes to physically pry open cells like a car jack. Miss one closing tag, and the entire page shattered into disconnected tiles.

2. DHTML and the ActiveX Precursor to AJAX

In the late nineties and early 2000s, “Dynamic HTML” was the buzzword. In practice, DHTML was just marketing speak for Netscape and Microsoft waging open warfare inside your script files.

Netscape 4 gave us document.layers. Internet Explorer gave us document.all. If you wanted an element to move across the screen, you sniffed the user-agent string and maintained two parallel codebases in the same file.

Asynchronous data loading was even wilder. Back in August 2008, I wrote an article titled “Some Internet Explorer Innovations You Probably Forgot About While Waiting for IE6 to Die.” It hit the front page of Digg(? Slashdot? One of those.) My argument was straightforward: despite everything IE got wrong, Microsoft effectively invented AJAX.

Before fetch() or standardized XMLHttpRequest, you did not invoke a native browser API. In Internet Explorer, you initialized an actual Windows COM component: new ActiveXObject("Microsoft.XMLHTTP"). You had to wake up the underlying Windows operating system just to update a fragment of text without triggering a full page reload.

3. The Mark of the Web

Local development during the Windows XP Service Pack 2 era came with its own brand of security theater. If you opened a local HTML file directly from your hard drive that contained any JavaScript, Internet Explorer threw an aggressive yellow warning banner across the viewport and froze script execution.

The official Microsoft workaround was a magic comment pasted at the very top of your HTML:

<!-- saved from url=(0014)about:internet -->

The 14 represented the exact character count of about:internet. If your character count was off by one, the parser disregarded the directive and your local scripts remained locked down.

4. The Occult Arts: hasLayout, zoom: 1, and DirectX Filters

Once CSS finally took over layout, Internet Explorer 6 introduced developers to hasLayout. It was an undocumented internal engine flag. If an element lacked layout, margins doubled on floats, background colors vanished, and containers refused to contain their children.

To fix it, we resorted to superstition. You injected zoom: 1 or height: 1% into your stylesheets. The properties had no logical business being there, but they tricked Trident into setting that internal flag to true.

Transparent PNGs were worse. IE6 rendered 24-bit alpha channels as solid matte-gray or baby-blue blocks. In a 2006 tutorial I published on cross-browser PNG transparency, the only viable solution was running proprietary Microsoft DirectX filters:

filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='image.png', sizingMethod='crop');

It destroyed scrolling performance, broke hyperlink click targets, and required hasLayout to be toggled on just to render the graphic.

Why We Built What We Built

We did not invent modern front-end tooling because we were bored and wanted complex build pipelines. We built automated builds, linting, reset sheets, and boilerplates because we spent our twenties writing duct tape around runtimes that actively fought us.

The next time your build step throws a type warning or a CSS grid gap requires a minor fallback, take a breath. It beats debugging spacer.gif and toggling zoom: 1 at 2:00 AM.

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories