Reflection June 2025, Week 26

You Don’t Need “maximum-scale” Most of Time

Web developers use the maximum-scale attribute, often found within the <meta name="viewport"> tag on websites, to control the maximum zoom level a user can apply to a webpage on their device. A value of 1 means the user cannot zoom in further than the initial page size, and a value greater than 1, like 2, means the user can zoom in twice the initial size.

This attribute was widely adopted due to several browser bugs, for example, the position:fixed does not work in Android or unexpected “zoom in” behavior in iOS when the user flip from portrait to landscape. However, these bugs are now rather irrelevant or best addressed with other fixes.

As a result, the maximum-scale attribute causes rather unnecessarily accessibility problems nowadays. Users cannot zoom in to see the tiny text on the graphic or some little hint text around form fields. Besides, this attribute does not work for recent iOS anyway because it gets ignored deliberately for the sake of accessibility.

Instead, use the touch-action CSS for controlling how touch gestures interact with the web elements. This attribute tells the browser which touch gestures it should handle natively (like scrolling, zooming) versus which ones your JavaScript should handle. For example:

touch-action: auto; /* Enable browser handling of all panning and zooming gestures*/
touch-action: none; /* Disable browser handling of all panning and zooming gestures*/

How to Use Other Models for Claude Code

The Claude Code only supports its own model, however, the Claude-Bridge can walk around that. It is basically a sophisticated man-in-the-middle proxy that intercepts Claude Code's API calls and redirects them to other LLM providers. Technically it spawn a subprocess for Claude Code in Node.js to allow injection timing and configuration, as well as bypassing anti-debugging, etc. And then it replaces the global.fetch method. This enables API call interception which converts Anthropic’s message format to a unified format, then to the target provider’s API, and reconstructs Anthropic-compatible Server-Sent-Events from the provider’s response.

This hack comes with drawbacks like unable to upload images or to use built-in tools. However, it is worth a try if one wants to save some costs.

A Styling Alternative to the “class” Attribute

In the early days of HTML, only a fixed list of tag names existed, and elements could not be styled. CSS was invented to provide layout and styling capabilities for web pages, first supported with the introduction of HTML 4.0 in 1997. The "class" attribute was introduced to identify elements in stylesheets, allowing developers to apply consistent styling across different elements.

As web development evolved far beyond its original scope, the limitations of CSS classes became clear. Issues like style collisions, combinatorial explosion, specificity conflicts, and maintenance challenges emerged. Different methodologies arose to address these issues—Block Element Modifier (BEM), CSS Modules, and Utility Classes—but they all share a fundamental weakness: the lack of effective validation for class application.

Keith Cirkel has proposed an intriguing alternative approach using HTML attributes and Custom Elements. Instead of relying on arbitrary class strings, this method leverages the key-value nature of attributes:

.Card {
  /* ... */
}
.Card[data-size='big'] {
  width: 100%;
}
.Card[data-size='medium'] {
  width: 50%;
}
.Card[data-size='small'] {
  width: 25%;
}

.Card[data-align='left'] {
  text-align: left;
}
.Card[data-align='right'] {
  text-align: right;
}
.Card[data-align='center'] {
  text-align: center;
}

<div class="Card" data-size="big" data-align="center"></div>

Taking this further with Custom Elements(Web Components)

my-card {
  /* ... */
}
my-card[data-size='big'] {
  width: 100%;
}

<my-card data-size="big"></my-card>

The appeal is clear: attributes can only have one value, preventing contradictory states like class="big small", and they provide semantic key-value pairs that are easier to reason about.

However, I see significant barriers to widespread adoption in today's ecosystem. First, there’s the inertia of established system: tooling, education, documentation, and developer mindsets are deeply ties to classes. Second, this approach doesn’t offer a compelling advantage over existing component-based approaches, like React, Vue or Angular, which already abstract away much of the mental burden of CSS management. For example, in React, you might write:

<Card size="large" align="center" loading={isLoading} />

Here, the underlying CSS class implementation becomes an implementation detail that developers rarely need to think about. Component frameworks already provide the type safety, state validation, and semantic clarity— goals that Keith's approach aims to achieve but within the existing ecosystem.

Moreover, Custom Elements(Web Components) challenge a key principle that has driven web success: standardization. A <my-card> element cannot be recognized by search engines, screen readers, or other tools that expect semantic HTML.

In conclusion, while Keith’s proposal is thought-provoking, it lacks a strong enough case to disrupt the status quo. Still, I appreciate the fresh perspective. Dissatisfaction often sparks progress, and ideas like this keep the web development community moving forward.