DEV Community: Vishal Singh

CSS field-sizing Is Baseline 2026: Auto-Growing Inputs and Textareas Without JavaScript

Vishal Singh — Tue, 01 Sep 2026 12:10:29 +0000

Forms often start with a sizing compromise.

An input is wide enough for the average value but wastes space for short values. A textarea begins at a fixed height and either shows a scrollbar too early or needs JavaScript to measure scrollHeight after every edit.

CSS field-sizing gives form controls a content-based sizing mode. With one declaration, an input can grow with its value and a textarea can expand as the user types.

MDN marks field-sizing as Baseline 2026 Newly available since June 2026. That means the latest core browser versions support it, but older browsers and devices still exist. The practical approach is progressive enhancement: keep a usable default, add content sizing where supported, and set defensive minimum and maximum sizes.

The two sizing modes

The property has two keyword values:

field-sizing: fixed;
field-sizing: content;

fixed is the initial value. The control uses its normal preferred size, along with CSS dimensions and HTML attributes such as size, rows, and cols.

content tells the control to adjust its preferred size around its current content.

The smallest useful enhancement is:

input,
textarea,
select {
  field-sizing: content;
}

That line changes the sizing model, but it is not enough for production. An empty text field can collapse close to the width of its caret, while a long value can push the layout much farther than intended. Content-based sizing needs boundaries.

Build an auto-growing textarea

Start with ordinary, accessible HTML:

<label for="reply">Reply</label>
<textarea
  id="reply"
  name="reply"
  placeholder="Write your reply"
></textarea>

Then keep a dependable fallback and enhance it:

textarea {
  box-sizing: border-box;
  inline-size: 100%;
  min-block-size: 6rem;
  max-block-size: 18rem;
  resize: vertical;
}

@supports (field-sizing: content) {
  textarea {
    field-sizing: content;
    inline-size: 100%;
  }
}

In an unsupported browser, the textarea remains a normal six-rem-high control that the user can resize vertically.

In a supporting browser, its block size grows with the entered content until it reaches max-block-size. After that limit, the control can scroll instead of expanding forever.

This replaces a common JavaScript pattern:

textarea.addEventListener("input", () => {
  textarea.style.height = "auto";
  textarea.style.height = `${textarea.scrollHeight}px`;
});

Removing that measurement loop means less event code and fewer layout reads. It also lets CSS remain responsible for presentation.

Let a short input grow with its value

Content sizing is also useful for compact fields such as a coupon code, quantity, slug, or inline editable label.

<label for="project-slug">Project slug</label>
<input
  id="project-slug"
  name="project-slug"
  type="text"
  value="docs"
  maxlength="40"
>

@supports (field-sizing: content) {
  #project-slug {
    field-sizing: content;
    min-inline-size: 10ch;
    max-inline-size: min(32ch, 100%);
  }
}

The input starts at a useful minimum, grows with the value, and stops before it can break its container. maxlength also limits the amount of accepted text, although layout limits should still exist independently.

Use logical properties such as inline-size and block-size when the component may appear in different writing modes. They describe the text flow rather than assuming that width is always horizontal.

Understand the textarea growth order

A textarea with field-sizing: content can grow in both directions.

If its inline size is unconstrained, it may first grow wider with the content. Once it reaches an inline constraint, text wraps and the textarea begins growing in the block direction. When the block-size limit is reached, scrolling becomes necessary.

For most form layouts, the intended behaviour is simpler: keep the textarea as wide as its container and let only its height respond to content.

@supports (field-sizing: content) {
  .message-field {
    field-sizing: content;
    inline-size: 100%;
    min-block-size: 5lh;
    max-block-size: 14lh;
  }
}

The lh unit follows the element's line height, so the limits describe an approximate number of text lines instead of unrelated pixels.

Placeholders participate in sizing

A placeholder is content for intrinsic sizing. A long placeholder can make an otherwise empty control much wider.

<input
  type="email"
  placeholder="name@company.example"
>

With field-sizing: content, that placeholder influences the initial preferred width. When the user starts typing, the field can resize around the actual value.

Do not use a long placeholder as a substitute for instructions. Keep a visible label, place supporting guidance beside the control, and set min-inline-size and max-inline-size so placeholder copy cannot dictate the entire layout.

HTML sizing attributes change meaning

The HTML size attribute normally influences the preferred width of an input. rows and cols normally influence a textarea's starting size.

When field-sizing: content controls the preferred size, those attributes no longer provide the same sizing behaviour. Put the production boundaries in CSS instead:

.profile-bio {
  min-inline-size: 20ch;
  max-inline-size: 100%;
  min-block-size: 5lh;
  max-block-size: 16lh;
}

Keep semantic HTML attributes that have independent value, such as maxlength, required, autocomplete, and the correct input type.

Select controls can shrink to the chosen option

For a regular <select>, the browser normally reserves enough width for the longest option. With content sizing, the closed control can adjust to the currently selected option.

@supports (field-sizing: content) {
  select.compact {
    field-sizing: content;
    min-inline-size: 8ch;
    max-inline-size: 100%;
  }
}

This can help compact toolbars, but changing width after every selection can also make surrounding controls move. Use it only where that movement is acceptable, and test long localized option labels.

Multi-select list boxes behave differently: content sizing can make them large enough to display their options without the usual scrolling. That may be useful for a short fixed list and harmful for a long dynamic one.

Fixed dimensions can defeat the feature

If you set a fixed width or height, you are reintroducing a fixed size. Prefer minimums and maximums around content sizing.

/* Flexible */
input {
  field-sizing: content;
  min-inline-size: 8ch;
  max-inline-size: 28ch;
}

/* This prevents inline growth */
input.fixed-example {
  inline-size: 18rem;
}

The property is not magic layout containment. The parent grid or flex layout, available space, padding, borders, fonts, placeholder, and overflow rules all affect the final result.

Accessibility checks still matter

Auto-sizing can remove JavaScript, but it does not remove form-design responsibilities.

Test the component with:

keyboard-only navigation
browser zoom at 200% and 400%
increased text size and spacing
long unbroken strings
autofilled values
validation messages
localized labels and placeholders
right-to-left and vertical writing modes where relevant

Keep an associated <label>. Do not hide overflow merely to preserve a compact design. Make sure focus indicators remain visible as the control changes size. For textareas, retaining resize: vertical gives users a manual option when your automatic limits do not match their needs.

Also watch for layout shift. A field that grows inside a toolbar or card can move buttons and surrounding content. Content-based sizing should improve the interaction, not surprise the user after every character.

A safe rollout plan

Choose one field currently using a JavaScript auto-resize handler.
Keep the existing usable dimensions as the default.
Add field-sizing: content inside @supports.
Define minimum and maximum inline and block sizes.
Test empty, placeholder, typical, maximum, and autofilled values.
Test zoom, localization, keyboard use, and small containers.
Remove the JavaScript measurement loop only after the CSS path meets your browser-support policy.

Conclusion

field-sizing turns a common scripted behaviour into a native sizing option.

The property is small, but the implementation decision is still a design decision. An input should not collapse to a caret or expand across the page. A textarea should not grow without limit. A select should not shift an entire toolbar unexpectedly.

Use content sizing as progressive enhancement, surround it with sensible constraints, and test the states that real form controls experience. When those boundaries are in place, one line of CSS can replace a surprising amount of measurement code.

Sources

CSS :open Is Baseline 2026: Style Open UI States with One Selector

Vishal Singh — Tue, 01 Sep 2026 11:55:56 +0000

Web interfaces contain several elements that can be open or closed: disclosure widgets, dialogs, select pickers, date inputs, and color pickers.

Historically, styling those states required different selectors. A disclosure could use details[open], while native picker state often had no equivalent general selector.

The CSS :open pseudo-class provides one semantic selector for elements that are currently in an open state. MDN marks it Baseline 2026 Newly available since May 2026 across the latest core browser versions.

Older browsers still exist, so production use should include fallbacks where the open styling is essential.

Start with details

The familiar approach is:

details[open] > summary {
  background: #eef2ff;
}

With the pseudo-class, the selector expresses the state directly:

details:open > summary {
  background: #eef2ff;
}

Both can coexist during migration:

details[open] > summary,
details:open > summary {
  background: #eef2ff;
}

The attribute selector is a dependable fallback for details and dialog because those elements reflect their state through the open attribute.

Style an open select

One of the more interesting uses is a native select while its picker is displayed.

select {
  border: 1px solid #94a3b8;
  border-radius: 0.625rem;
  padding: 0.65rem 0.8rem;
}

select:open {
  border-color: #4f46e5;
  box-shadow: 0 0 0 3px rgb(79 70 229 / 20%);
}

That state was difficult to target consistently with older CSS alone.

Style the parent with :has()

:open becomes more useful when combined with :has().

.field:has(select:open) {
  background: #f8fafc;
}

The field wrapper can now react when its child select is open without JavaScript adding and removing a class.

Keep the visual change helpful and subtle. Opening a picker should not cause nearby content to jump.

Inputs with picker interfaces

The selector can also match inputs while a browser-provided picker is open, including controls such as date or color inputs where supported.

:is(input[type="date"], input[type="color"]):open {
  outline: 3px solid rgb(14 165 233 / 30%);
  outline-offset: 2px;
}

The exact picker presentation varies by platform, so test real operating systems rather than relying only on desktop screenshots.

:open is not :popover-open

Popover elements have their own showing state and selector.

[popover]:popover-open {
  opacity: 1;
}

Use :open for elements with semantic open and closed states. Use :popover-open for a popover that is currently showing.

These states can coexist in the platform, so choosing the correct selector makes the CSS easier to understand.

Open does not necessarily mean visible

Semantic state and visual rendering are different.

A details element can have its open state even if an ancestor hides it. :open reports the state; it does not guarantee that a user can currently see or interact with the element.

Avoid using it as a substitute for visibility or layout checks.

Feature detection

Use selector detection when the enhancement has no simple fallback.

@supports selector(:open) {
  select:open {
    border-color: #4f46e5;
  }
}

For details and dialog, the [open] attribute remains a practical fallback. For native picker states, make sure the closed appearance is already complete and accessible.

Animation considerations

An open-state selector can trigger a transition, but not every element's hidden-to-visible behaviour is automatically animatable.

details > .content {
  opacity: 0;
  transition: opacity 180ms ease;
}

details:open > .content {
  opacity: 1;
}

@media (prefers-reduced-motion: reduce) {
  details > .content {
    transition: none;
  }
}

Test closing as well as opening. Some elements stop rendering content immediately when they close, which can prevent the reverse transition from appearing as expected.

Accessibility rules still apply

CSS state selectors do not replace semantics.

Use <summary> as the interactive label for <details>.
Give dialogs an accessible name.
Keep focus visible.
Do not communicate open state through color alone.
Ensure controls remain operable by keyboard.
Respect reduced-motion and forced-colors preferences.

The browser supplies a state; your design still has to communicate it clearly.

A practical migration

Keep [open] fallbacks for existing details and dialogs.
Add :open for select and native picker enhancements.
Use @supports selector(:open) for isolated new styling.
Test keyboard interaction, zoom, and multiple operating systems.
Use :popover-open instead when the component is a popover.

Conclusion

:open is a small CSS feature with a useful effect: it gives several native controls a shared vocabulary for their active state.

It can remove JavaScript classes from simple visual changes, improve styling for native pickers, and make selectors read more like the interface behaviour they represent.

Use it as an enhancement, keep sensible fallbacks, and remember that state selection is only one part of an accessible component.

Sources:

Customizable Select: Style Native Dropdowns Without Rebuilding Accessibility

Vishal Singh — Tue, 01 Sep 2026 11:55:38 +0000

Native <select> elements provide keyboard interaction, form submission, focus behaviour, and platform integration. They are also famously difficult to style.

That tension has pushed many teams to replace a real select with divs, ARIA roles, and a large JavaScript component. The result may match the design system, but it also inherits responsibility for every keyboard, focus, scrolling, and assistive-technology detail.

Customizable select features aim to provide a better middle ground: keep the native element and behaviour while opting into new styling hooks.

Support is still limited. MDN does not classify the complete feature set as Baseline, and framework or server-rendering interactions need testing. Use progressive enhancement rather than replacing every production dropdown immediately.

Opt into the base-select appearance

The central CSS opt-in is appearance: base-select on both the select and its picker.

select,
::picker(select) {
  appearance: base-select;
}

This gives the control browser-defined base behaviour that can be styled more directly.

select {
  min-inline-size: 14rem;
  padding: 0.75rem 1rem;
  border: 1px solid #cbd5e1;
  border-radius: 0.75rem;
  background: white;
  color: #0f172a;
}

::picker(select) {
  border: 1px solid #cbd5e1;
  border-radius: 0.75rem;
  box-shadow: 0 1rem 2rem rgb(15 23 42 / 18%);
}

Style the open state

The :open pseudo-class can target the select while its picker is displayed.

select:open {
  border-color: #4f46e5;
  box-shadow: 0 0 0 3px rgb(79 70 229 / 20%);
}

The picker icon also has a dedicated pseudo-element:

select::picker-icon {
  color: #64748b;
  transition: rotate 160ms ease;
}

select:open::picker-icon {
  rotate: 180deg;
}

Remember to respect reduced-motion preferences if an animation is not essential.

Style options without losing their meaning

Options can receive richer visual treatment in supporting browsers.

option {
  padding: 0.75rem 1rem;
}

option:hover,
option:focus {
  background: #eef2ff;
}

option:checked {
  background: #e0e7ff;
  font-weight: 700;
}

::checkmark can style the visual indicator for the selected option, while ::picker-icon targets the closed control's disclosure icon.

Selected content can be richer

The evolving customizable-select model permits a button as the first child of the select and introduces <selectedcontent> to display a clone of the chosen option's content.

<select name="plan">
  <button>
    <selectedcontent></selectedcontent>
  </button>

  <option value="starter">
    <span aria-hidden="true">🌱</span>
    Starter
  </option>

  <option value="growth">
    <span aria-hidden="true">🚀</span>
    Growth
  </option>
</select>

Keep option labels concise and meaningful without their decorative icons.

Progressive enhancement is the safest rollout

Start with valid, ordinary select markup. Browsers without the new rendering path should retain a usable classic control.

@supports (appearance: base-select) {
  select,
  ::picker(select) {
    appearance: base-select;
  }

  /* Enhanced styling lives here. */
}

Do not hide the select and replace it with an unsupported picker. The fallback is a feature, not a failure.

Framework and hydration risks

Modern parsing rules allow richer children inside a select, but some framework versions may still assume the older content model. Server-rendered markup can also differ from the client-side tree and cause hydration warnings.

Before adopting the richer markup:

test the exact framework and version
test server rendering and hydration
inspect the DOM produced in supporting and non-supporting browsers
keep a classic markup variant if your framework cannot preserve the structure

CSS-only enhancement of a normal select is a smaller first step than immediately using every new element and pseudo-element.

Accessibility testing remains necessary

Native semantics reduce risk, but visual customization can still create problems.

Check:

visible focus indication
keyboard selection and dismissal
high-contrast and forced-colors modes
zoom and text resizing
long labels and localization
disabled options and optgroups
screen-reader announcements
touch target size

Do not remove outlines without providing an equally strong focus indicator.

When to keep a custom component

A select is appropriate when a user chooses from a list of options. It is not automatically a replacement for every combobox, searchable command palette, tree picker, or multi-step menu.

If your interface needs asynchronous search, arbitrary text input, virtualized results, or complex option actions, a purpose-built component may still be necessary. Use the semantic pattern that matches the interaction.

A safe migration plan

Choose one simple single-select field.
Keep the current native markup.
Add base-select styling inside @supports.
Test all required browsers and assistive technologies.
Introduce richer option content only after framework and hydration checks pass.
Preserve the ordinary native control as the fallback.

Conclusion

Customizable select is exciting because it may finally reduce the trade-off between design control and native behaviour.

The best adoption strategy is incremental. Improve a real select where support exists, keep the classic control everywhere else, and let accessibility and compatibility tests—not a screenshot—decide whether the result is ready.

Sources:

CSS text-fit: Responsive Headlines Without JavaScript Font-Sizing Loops

Vishal Singh — Tue, 01 Sep 2026 11:55:14 +0000

Designers often want a headline to fill its container regardless of whether it contains twelve characters or forty.

Developers usually solve that with breakpoint-specific font sizes, container queries, or JavaScript that measures the text and repeatedly adjusts font-size. Each option works, but none directly expresses the real intent: make this text fit the available inline space.

Chrome 150 introduced the experimental CSS text-fit property to target that problem.

This is currently a new and limited-support feature. Treat it as an enhancement, verify the exact syntax against current specifications, and keep a readable fallback.

The problem with viewport-only typography

A common responsive rule looks like this:

.hero-title {
  font-size: clamp(2rem, 7vw, 6rem);
}

clamp() is excellent when text size should respond to the viewport. But the same viewport can contain cards, sidebars, split layouts, and translated text with very different available widths.

The container and content length matter too.

The idea behind text-fit

text-fit lets the browser scale text so it fits the width of its containing box. Chrome's examples include syntax such as:

.headline {
  text-fit: grow per-line-all;
}

The browser performs the fitting as part of layout. You do not need a resize observer and a loop that repeatedly measures text until it reaches a target width.

Because the feature is experimental, confirm the supported values in your target Chrome release before shipping a demo.

Always start with a fallback

The unsupported declaration will be ignored, so the base style must remain usable.

.headline {
  max-inline-size: 18ch;
  font-size: clamp(2rem, 8cqi, 5.5rem);
  line-height: 0.95;
  text-wrap: balance;
}

@supports (text-fit: grow) {
  .headline {
    font-size: 2rem;
    text-fit: grow per-line-all;
  }
}

Here, clamp() and container-query units provide a dependable baseline. Supporting browsers receive the fitting enhancement.

Where it can help

Good candidates include:

short editorial headlines
dashboard numbers
poster-style cards
campaign banners with controlled copy
data visualizations with bounded labels

It is less suitable for long body text. Consistent reading size and line length matter more than filling every pixel.

Content still controls the design

Automatic fitting does not make every string readable.

A long translation may be technically fitted but become too small. A short word may become uncomfortably large. User-generated text can contain one unbreakable token. Browser zoom and custom fonts can change the result.

Use sensible bounds in the component design:

.metric {
  min-block-size: 5rem;
  overflow-wrap: anywhere;
}

Also consider a content-length limit when the interface owns the copy.

Avoid layout instability

Web fonts can change glyph widths after they load. That can cause fitted text to recalculate.

Reduce surprises by:

preloading only genuinely critical fonts
using accurate font fallback metrics
reserving enough block space
testing with a cold cache
checking layout shifts in real devices

Do not trade a JavaScript sizing loop for a visible font jump.

Accessibility checks

Fitted text must still respond to user needs.

Test at 200% and 400% zoom. Check browser text-size settings where available. Make sure the text is not clipped when the user increases spacing. Confirm that fitting does not reduce important copy below your product's minimum readable size.

Never put critical information into a fixed-height box that hides overflow merely to preserve a visual composition.

Compare it with existing tools

clamp() controls a value between minimum and maximum sizes, usually based on the viewport.

Container-query units such as cqi respond to component size.

text-wrap: balance improves line distribution but does not change font size.

text-fit responds to the rendered text and the available box. These tools can complement one another; they do not need to compete.

A practical experiment plan

Choose one non-critical marketing headline.
Keep the current typography as the fallback.
Add the enhancement inside @supports.
Test the shortest and longest approved copy.
Test localized strings, browser zoom, font loading, and narrow containers.
Measure layout shift and compare screenshots across supported browsers.
Keep it experimental until the syntax and compatibility are stable enough for your policy.

Conclusion

text-fit expresses a real design goal that CSS has historically handled only indirectly. Letting the layout engine fit display text could remove a surprising amount of measurement code.

The feature is new, so the responsible approach is simple: use it on controlled display text, keep a strong fallback, and test readability rather than judging only whether the text fills the box.

Sources:

HTML focusgroup: Arrow-Key Navigation Without Roving Tabindex

Vishal Singh — Tue, 01 Sep 2026 11:53:59 +0000

Toolbars, tab lists, menus, and other composite widgets usually need two keyboard behaviours:

one Tab stop for the entire widget
arrow keys to move between items inside it

Today, developers normally implement that pattern with JavaScript and a “roving tabindex.” One item has tabindex="0", every peer has tabindex="-1", and keyboard handlers constantly move those values.

The proposed HTML focusgroup attribute moves much of that repeated work into the browser.

It is important to be precise about availability: focusgroup is still an evolving web-platform feature. Chrome announced it for developer feedback and later included it in Chrome 150, but you should verify your required browsers and keep a fallback before using it in production.

The roving tabindex problem

A simple toolbar often starts like this:

<div role="toolbar" aria-label="Formatting">
  <button tabindex="0">Bold</button>
  <button tabindex="-1">Italic</button>
  <button tabindex="-1">Underline</button>
</div>

JavaScript must then listen for arrow keys, find the next enabled item, update tabindex values, and move focus.

A robust implementation also handles:

right-to-left layouts
vertical writing modes
wrapping at the first and last items
disabled or hidden controls
dynamically inserted items
restoring the last-focused item
nested widgets

That is a lot of duplicated code for a common interaction pattern.

The focusgroup version

With the proposed attribute, the toolbar becomes:

<div focusgroup="toolbar wrap" aria-label="Formatting">
  <button type="button">Bold</button>
  <button type="button">Italic</button>
  <button type="button">Underline</button>
</div>

The browser can provide arrow-key movement, one Tab stop, direction-aware navigation, and last-focused memory.

The wrap modifier lets navigation continue from the final item back to the first.

Navigation is not selection

Moving focus is only one part of many widgets.

In a tab list, arrow keys may move focus, but your application still needs to:

update aria-selected
show the selected panel
hide other panels
decide whether selection follows focus
update the URL when deep linking is supported

focusgroup does not replace the business or state logic that makes a component work. It targets the repeated keyboard-navigation layer.

A tab-list example

<div focusgroup="tablist wrap nomemory" aria-label="Account sections">
  <button
    id="profile-tab"
    aria-controls="profile-panel"
    aria-selected="true"
    focusgroupstart
  >
    Profile
  </button>

  <button
    id="security-tab"
    aria-controls="security-panel"
    aria-selected="false"
  >
    Security
  </button>
</div>

focusgroupstart marks the initial entry point. The nomemory modifier tells the browser not to restore the previously focused item when the user returns, which can be useful when focus should enter on the currently selected tab.

Application JavaScript still switches the panels and selected state.

Logical directions matter

The proposal uses logical directions instead of assuming every interface is horizontal and left-to-right.

An inline focus group usually responds to left and right arrows in an English layout. In another writing mode or direction, the browser can adapt the navigation to the document.

That behaviour is hard to reproduce correctly when every design system ships its own keyboard handler.

Feature detection and fallback

Do not remove your proven roving-tabindex implementation until your browser policy supports the new attribute.

if ("focusgroup" in HTMLElement.prototype) {
  // Use the native focusgroup path.
} else {
  // Initialize the existing roving-tabindex fallback.
}

Your HTML should retain meaningful labels and appropriate semantics in both paths.

Accessibility testing is still required

A browser primitive can reduce implementation mistakes, but it cannot decide whether you chose the correct widget pattern.

Test:

Tab and Shift+Tab entry and exit
every relevant arrow key
Home and End if your pattern expects them
disabled and dynamically removed items
zoom and reflow
right-to-left content
screen readers in your supported browser combinations
touch and pointer interaction

Also check for controls such as text inputs that use arrow keys internally. A keyboard user must always have a clear way to navigate and leave the component.

A safe migration plan

Find a small existing toolbar with a tested fallback.
Document its current keyboard behaviour.
Add focusgroup behind feature detection.
Keep state and selection logic separate from focus movement.
Run the same automated and manual accessibility tests on both paths.
Expand only after browser support and real-world behaviour meet your policy.

Conclusion

focusgroup is promising because it turns a common accessibility pattern into a platform capability. It can reduce repeated JavaScript while giving the browser more responsibility for writing modes, memory, and focus order.

It is not a reason to stop thinking about semantics or testing. Use it as progressive enhancement, keep the current path, and let support evidence decide when the fallback can be retired.

Sources:

WebMCP: Make Your Website Agent-Ready Without Screen Scraping

Vishal Singh — Tue, 01 Sep 2026 11:53:32 +0000

AI agents can already operate websites by reading text, inspecting accessibility trees, and clicking visible controls. That works, but it asks the agent to reverse-engineer an interface designed for humans.

WebMCP proposes a different model: a website can expose supported actions as structured tools. Instead of guessing which button completes a booking, an agent can discover a bookSlot tool with a description, typed inputs, and a defined result.

WebMCP is currently an emerging Chrome capability and origin-trial technology, not a cross-browser production standard. That makes it useful to study and experiment with, but too early to use as the only path for an important workflow.

Why screen-driven automation is fragile

A human can look at a page and understand that “Continue” advances a checkout. An agent has to infer that meaning from surrounding text and interface state.

That approach can break when:

button labels change
a responsive layout moves controls
a modal covers the next step
the page renders differently for another account
an A/B test changes the interface
an action has an important side effect that is not obvious from the label

A structured tool gives the browser and agent a clearer contract.

The basic WebMCP model

A site registers tools. Each tool has a name, description, input schema, and implementation. A compatible browser can expose those tools to an agent, and the agent supplies structured arguments.

For a consultation form, the conceptual flow looks like this:

The website registers bookSlot.
The tool describes required fields such as date, time, name, and email.
The browser presents the tool to an agent within the page's origin and permission context.
The agent asks for or confirms the required information.
The website's own code performs the booking.

The agent does not need to guess the DOM path to a submit button.

Declarative tools for existing forms

The declarative API is designed for standard HTML forms. A form can be annotated with a tool name and description while its controls become tool parameters.

<form
  action="/consultations"
  method="post"
  toolname="book_consultation"
  tooldescription="Book a 30-minute consultation slot"
>
  <label>
    Date
    <input name="date" type="date" required>
  </label>

  <label>
    Email
    <input name="email" type="email" required>
  </label>

  <button type="submit">Book</button>
</form>

The important idea is progressive enhancement. The form should remain a real, usable form for people and browsers that do not support WebMCP.

Imperative tools for application actions

Some actions do not map neatly to one form. The imperative API lets application code register a tool with a JSON schema and an execute function.

document.modelContext.registerTool({
  name: "checkOrderStatus",
  description: "Return the latest status for an order owned by the signed-in user",
  inputSchema: {
    type: "object",
    properties: {
      orderId: { type: "string" }
    },
    required: ["orderId"]
  },
  execute: async ({ orderId }) => {
    return await api.getOrderStatus(orderId);
  }
});

The tool should call the same trusted application layer used by the normal interface. WebMCP is an interaction surface, not a replacement for authorization or business rules.

Security responsibilities do not disappear

A structured action can be more reliable than screen scraping, but it can also make a sensitive capability easier to invoke. Treat every tool call as untrusted input.

Good rules include:

authenticate and authorize on the server
validate every input again on the server
make read-only and state-changing actions easy to distinguish
require confirmation for purchases, deletion, publication, or account changes
return the minimum necessary data
log important tool calls for audit and debugging
use idempotency protection for actions that must not run twice

Never assume that a tool is safe because it was called through a browser agent.

Start with narrow, high-confidence actions

The best first tool is usually not “control my entire application.” Choose one action with clear inputs, predictable output, and an existing server-side permission check.

Useful candidates include:

search public documentation
check an order status
calculate a quote without purchasing
find available appointment times
save a draft without publishing it

These actions are easier to test than a broad tool that hides many decisions.

How to evaluate a WebMCP tool

Test more than the happy path.

Ask whether the agent:

chooses the tool for the right user request
avoids it for unrelated requests
asks for missing required information
rejects invalid values cleanly
explains a failure without inventing a result
requests confirmation before a consequential action
behaves correctly when the user is signed out or unauthorized

Chrome's developer tooling and Lighthouse work around WebMCP are useful for inspecting registered tools, but application-level tests are still necessary.

A practical adoption plan

Keep the existing human interface fully functional.
Select one narrow action.
Define a clear name, description, and input schema.
Reuse existing server authorization and validation.
Add confirmation for meaningful side effects.
Test successful, invalid, unauthorized, cancelled, and repeated calls.
Treat the implementation as experimental while the API and browser support evolve.

Conclusion

WebMCP points toward a web where agents do not have to guess how every interface works. Sites can expose supported capabilities as explicit tools while preserving their normal human-facing experience.

The opportunity is not to give agents unlimited control. It is to make a small set of user-approved actions clearer, safer, and more reliable.

Sources:

CSS Anchor Positioning in 2026: Build Tooltips and Popovers Without Coordinate Math

Vishal Singh — Tue, 01 Sep 2026 11:51:43 +0000

A tooltip belongs next to a button. A menu belongs next to its trigger. A validation message belongs next to its input.

The design sounds simple, but the implementation often becomes a small geometry engine: read getBoundingClientRect(), calculate an offset, watch scrolling, handle resizing, detect viewport collisions, and update everything again when the layout changes.

CSS Anchor Positioning gives the browser a declarative way to tether one element to another.

In January 2026, the core anchor() function became Baseline Newly available across the latest major browser versions. The wider module is still evolving, and MDN marks some individual properties as limited availability, so production code still needs feature checks and a fallback.

This guide builds a practical tooltip, explains overflow handling, and shows where JavaScript and accessibility are still required.

What you will learn

how to tether a floating element to a trigger with CSS
how to keep a dependable fallback for older browsers
how anchor positioning works with tooltips and the Popover API
which accessibility and interaction responsibilities still need attention

The basic mental model

Anchor positioning has three parts:

Name the anchor element.
Associate the positioned element with that anchor.
Place the positioned element relative to an anchor edge.

Here is a small tooltip structure:

<span class="help">
  <button
    class="help__trigger"
    type="button"
    aria-describedby="billing-help"
  >
    What is a billing cycle?
  </button>

  <span class="help__tooltip" id="billing-help" role="tooltip">
    The period covered by one invoice.
  </span>
</span>

The wrapper is useful for the fallback. The CSS enhancement names the button as an anchor:

.help__trigger {
  anchor-name: --billing-trigger;
}

.help__tooltip {
  position: absolute;
  position-anchor: --billing-trigger;

  top: calc(anchor(bottom) + 0.5rem);
  left: anchor(center);
  translate: -50% 0;

  max-inline-size: 18rem;
  padding: 0.65rem 0.75rem;
  border-radius: 0.5rem;
  background: #111827;
  color: white;
  box-shadow: 0 0.75rem 2rem rgb(0 0 0 / 20%);
}

The browser now calculates the button's bottom edge and horizontal centre. The tooltip stays tethered even when responsive layout changes move the trigger.

No getBoundingClientRect() loop is needed for the position.

Add a dependable fallback first

New CSS should not turn an unsupported browser into a broken interface.

Start with a classic containing-block fallback:

.help {
  position: relative;
  display: inline-block;
}

.help__tooltip {
  position: absolute;
  z-index: 10;
  inset-block-start: calc(100% + 0.5rem);
  inset-inline-start: 50%;
  translate: -50% 0;
}

Then place the anchor-specific rules inside @supports:

@supports (anchor-name: --billing-trigger) {
  .help__trigger {
    anchor-name: --billing-trigger;
  }

  .help__tooltip {
    position-anchor: --billing-trigger;
    top: calc(anchor(bottom) + 0.5rem);
    left: anchor(center);
    inset-block-start: auto;
    inset-inline-start: auto;
  }
}

Browsers that do not support anchor positioning keep the wrapper-based layout. Supporting browsers use the anchor.

Feature detection is better than checking a user-agent string because it asks the browser about the capability you need.

Keep the interaction accessible

CSS can calculate position, but position is only one part of a tooltip.

A keyboard user must be able to reveal the content. A touch user cannot depend on hover. The trigger and tooltip need a meaningful relationship.

A simple visual state can start with both hover and focus:

.help__tooltip {
  opacity: 0;
  visibility: hidden;
  pointer-events: none;
}

.help:has(.help__trigger:hover) .help__tooltip,
.help:has(.help__trigger:focus-visible) .help__tooltip {
  opacity: 1;
  visibility: visible;
}

For short, non-interactive supplementary text, role="tooltip" and aria-describedby can be appropriate.

If the floating content contains buttons, links, form controls, or substantial information, it is not a tooltip. Use a dialog, menu, or popover pattern with correct focus management and keyboard behaviour.

CSS Anchor Positioning does not replace semantic HTML or interaction logic.

Place a popover next to its trigger

Anchor positioning works well with the Popover API because the two features solve different problems:

the Popover API controls top-layer display and light-dismiss behaviour
anchor positioning controls geometry

<button
  class="account-button"
  popovertarget="account-menu"
>
  Account
</button>

<div class="account-menu" id="account-menu" popover>
  <a href="/profile">Profile</a>
  <a href="/settings">Settings</a>
</div>

.account-button {
  anchor-name: --account-button;
}

.account-menu {
  position-anchor: --account-button;
  position: fixed;

  top: calc(anchor(bottom) + 0.5rem);
  right: anchor(right);

  margin: 0;
  min-inline-size: 12rem;
}

Using fixed positioning can be useful for top-layer content, but test the exact combination in the browsers you support. Popover behaviour, anchor association, scrolling, transforms, and containing blocks can interact in ways that are easy to miss in a small demo.

Also choose the correct accessible pattern. A list of normal navigation links does not automatically need ARIA menu roles. Native link and button semantics are often simpler and more robust.

Handle viewport overflow

A tooltip below a trigger can be clipped when the trigger is near the bottom of the viewport.

Anchor positioning includes position-try fallbacks that let the browser test alternate placements.

.help__tooltip {
  position-try-fallbacks:
    flip-block,
    flip-inline,
    flip-block flip-inline;
}

The browser can try flipping the block direction, the inline direction, or both when the preferred placement does not fit.

You can also define a custom fallback:

@position-try --above-trigger {
  top: auto;
  bottom: calc(anchor(top) + 0.5rem);
}

.help__tooltip {
  position-try-fallbacks: --above-trigger;
}

Support for the complete position-try feature set may differ from support for the core anchor() function. Check each property you depend on, not just one general compatibility badge.

A practical rollout can therefore have two levels:

anchor positioning for the main placement
your existing overflow logic retained until the required position-try features meet your support target

Progressive enhancement does not need to be all or nothing.

Repeated components need anchor scoping

Imagine a product list with 20 help buttons. If every button uses the same anchor name, an unscoped positioned element can associate with the last matching anchor in source order.

The anchor-scope property is designed to limit an anchor name to a subtree.

.product-card {
  anchor-scope: --details-trigger;
}

.product-card__button {
  anchor-name: --details-trigger;
}

.product-card__panel {
  position-anchor: --details-trigger;
}

This lets repeated components reuse a meaningful anchor name without all panels attaching to one button.

Because anchor-scope is newer than the basic technique, verify its current compatibility. Until it fits your browser policy, unique generated anchor names are a reasonable fallback for component libraries.

When anchor() is better than position-area

The anchor() function works inside inset properties such as top, right, bottom, and left. It is explicit and combines naturally with calc().

.notification {
  left: calc(anchor(right) + 12px);
  top: anchor(center);
  translate: 0 -50%;
}

The position-area property provides a higher-level grid-like placement vocabulary.

.notification {
  position-area: center right;
}

position-area can be concise, while anchor() gives precise control. They are complementary. Choose the smallest feature set that expresses your layout and is supported by your target browsers.

What this replaces—and what it does not

Anchor positioning can replace a lot of coordinate calculation for:

tooltips
dropdown panels
contextual help
callouts
labels attached to controls
floating action panels
autocomplete surfaces

It does not automatically provide:

show and hide state
focus management
Escape-key handling
click-outside behaviour
accessible roles and labels
collision support in every target browser
application-specific placement policy

Libraries such as Floating UI still provide value when you need mature cross-browser collision handling, virtual anchors, framework integration, or one abstraction across older browsers.

The new CSS lets you reduce that dependency when your use case and browser matrix allow it.

A safe migration plan

Step 1: Measure the current complexity

Find components that read layout coordinates, subscribe to scroll and resize events, or repeatedly update inline top and left styles.

Step 2: Choose one low-risk component

A non-interactive tooltip or simple contextual label is easier to migrate than a complex editor menu.

Step 3: Keep the current fallback

Write the old layout as the default and add the anchor enhancement inside @supports.

Step 4: Test real layout conditions

Test:

viewport edges
zoom at 200%
long translated text
right-to-left layout
nested scrolling containers
transforms on ancestors
mobile touch interaction
keyboard navigation
the browser versions in your support policy

Step 5: Measure before deleting JavaScript

If the CSS path works across your required conditions, remove only the geometry code it actually replaces. Keep state and accessibility logic that is still necessary.

Common mistakes

Making the tooltip visible only on hover

Hover does not cover keyboard or touch interaction. Include focus behaviour and choose a suitable disclosure pattern for mobile.

Using a tooltip for interactive content

A tooltip should not contain buttons or form fields. Use a popover, dialog, or other interactive pattern.

Assuming one support badge covers the whole module

Core anchor() support and newer properties such as anchor-scope or some position-try features can have different compatibility states.

Forgetting the fallback

Unsupported CSS is ignored. If the anchor rules are the only placement rules, the element may appear in the wrong location.

Replacing tested code too early

The goal is not to delete a library because a demo works. The goal is to simplify a real component without losing behaviour.

Conclusion: let CSS own the geometry

Floating interfaces have historically asked JavaScript to measure the layout and then tell CSS where to draw.

Anchor positioning gives more of that work back to the browser's layout engine.

That can mean less code, fewer scroll and resize listeners, and a more direct relationship between the trigger and the floating element. The win is strongest when it is combined with semantic HTML, accessible state handling, honest compatibility checks, and a tested fallback.

Start with one tooltip. Keep the old path. Let the browser handle the geometry where it can.

Sources

JavaScript Temporal Reached Stage 4: A Practical Migration Guide Beyond Date

Vishal Singh — Mon, 10 Aug 2026 06:45:55 +0000

JavaScript's Date object has carried the web for decades, but almost every experienced developer has a story about it: an off-by-one-day bug, a daylight-saving surprise, a month numbered from zero, or a date-only value that silently became a timestamp.

In July 2026, the TC39 Temporal proposal reached a Stage 4 draft. That is a major standardisation milestone: the API has completed the proposal process and is ready to become part of the ECMAScript standard.

But Stage 4 does not mean you can assume every current browser already has Temporal. MDN still marks the API as limited availability. The practical approach is to learn the model now, use feature detection, and add the official polyfill when your support policy requires it.

This guide explains the mental model, the most useful types, and a safe migration path from Date.

What you will learn

how Temporal models dates, times, instants, zones, and durations
which Temporal type fits each common use case
how to migrate from Date without a risky rewrite
how to handle current browser support safely

Why Date causes so many bugs

Date tries to represent several different concepts with one mutable object:

an exact instant on the global timeline
a calendar date such as a birthday
a local wall-clock time
a date and time in a named time zone
a duration between two values

Those concepts are not interchangeable.

Consider the string 2026-08-10. It might mean a birthday, a billing date, or midnight in some time zone. Turning it into a Date can introduce a time zone that the original value never had.

Date also has historical API traps. Months are zero-indexed in the numeric constructor, parsing behaviour has edge cases, and methods can mutate an existing value.

Temporal solves the modelling problem by using separate immutable types.

The Temporal types you should know

You do not need to memorise the whole API. Start by choosing the type that matches the data.

Temporal.PlainDate

Use PlainDate for a calendar date with no time and no time zone.

Good examples include:

birthdays
public holidays
invoice due dates
check-in dates

const launchDate = Temporal.PlainDate.from("2026-08-10");
const reviewDate = launchDate.add({ months: 1 });

console.log(launchDate.toString()); // 2026-08-10
console.log(reviewDate.toString()); // 2026-09-10

Temporal values are immutable. add() returns a new value; it does not change launchDate.

Temporal.PlainTime

Use PlainTime for a wall-clock time without a date or time zone.

const openingTime = Temporal.PlainTime.from("09:30");
console.log(openingTime.hour); // 9

This works for a recurring local concept such as "the store opens at 09:30." It does not identify one exact moment globally.

Temporal.Instant

Use Instant for an exact point on the timeline.

This is the closest Temporal equivalent to a Unix timestamp or a Date used as an event timestamp.

const deployedAt = Temporal.Instant.from("2026-08-10T06:30:00Z");
console.log(deployedAt.epochMilliseconds);

Instants are useful for logs, database timestamps, audit events, and API data that ends in Z or includes an offset.

Temporal.ZonedDateTime

Use ZonedDateTime when the named time zone matters.

const meeting = Temporal.ZonedDateTime.from(
  "2026-08-10T10:00:00+05:30[Asia/Kolkata]"
);

console.log(meeting.timeZoneId); // Asia/Kolkata
console.log(meeting.toString());

The named zone is important because an offset such as +05:30 and a time zone such as Asia/Kolkata are different kinds of information. Time-zone rules can change, and many regions use daylight saving time.

Temporal.Duration

Use Duration for an amount of time.

const sprint = Temporal.Duration.from({ weeks: 2 });
console.log(sprint.toString()); // P2W

Be careful when converting calendar units into clock units. A day is not always exactly 24 hours in a zone with daylight-saving changes. Temporal makes you provide the context when that context is required.

A DST-safe example

Imagine a recurring meeting at 10:00 in New York. Adding one calendar day should keep the meeting at 10:00 local time, even if the UTC offset changes.

const beforeChange = Temporal.ZonedDateTime.from(
  "2026-03-07T10:00:00-05:00[America/New_York]"
);

const nextDay = beforeChange.add({ days: 1 });

console.log(nextDay.hour); // 10
console.log(nextDay.offset); // may change with DST rules

This is exactly why a named time zone is more useful than manually adding 86,400,000 milliseconds.

A practical migration map

Do not replace every Date in one giant refactor. First classify what each value means.

Date-only form values

Old approach:

const selected = new Date(input.value);

Safer Temporal model:

const selected = Temporal.PlainDate.from(input.value);

An HTML date input returns a date-only string. PlainDate preserves that meaning without introducing midnight or a time zone.

API timestamps

If an API returns an exact timestamp:

const createdAt = Temporal.Instant.from(apiResponse.createdAt);

If your UI needs a local representation, convert it with an explicit zone:

const local = createdAt.toZonedDateTimeISO("Asia/Kolkata");
console.log(local.toLocaleString());

Current time

For a timestamp:

const now = Temporal.Now.instant();

For the current calendar date in a chosen zone:

const todayInIndia = Temporal.Now.plainDateISO("Asia/Kolkata");

These two calls answer different questions, which is the point.

Calendar arithmetic

Old code often adds milliseconds:

const tomorrow = new Date(Date.now() + 24 * 60 * 60 * 1000);

For a calendar date, write the intent directly:

const tomorrow = Temporal.Now.plainDateISO().add({ days: 1 });

Interoperating with existing Date code

Most projects will use Date and Temporal together during migration.

Convert a Date to an Instant:

const legacyDate = new Date();
const instant = Temporal.Instant.from(legacyDate.toISOString());

Convert an Instant back to Date:

const legacyAgain = new Date(instant.epochMilliseconds);

This boundary is useful when an existing library still expects Date.

Do not convert a PlainDate to Date unless you decide what time and time zone that calendar date should represent. That decision cannot be inferred safely.

Browser support and the polyfill

Before using the global Temporal object, check your runtime support.

if ("Temporal" in globalThis) {
  // Native Temporal is available.
}

For production code that must work in browsers without native support, use the @js-temporal/polyfill package and follow its current installation documentation.

import { Temporal } from "@js-temporal/polyfill";

A polyfill has bundle-size and compatibility implications, so apply it deliberately. For a small isolated date task, an existing well-tested library may still be the right short-term choice. For new domain modelling, Temporal gives the platform a consistent long-term direction.

Common mistakes to avoid

Using PlainDateTime for a real event

PlainDateTime has a date and clock time but no time zone. "10 August at 10:00" is not one exact global moment until a zone is supplied.

Use ZonedDateTime or Instant for events that must be coordinated across locations.

Storing only a formatted string

A string such as "10 Aug, 11:30 AM" is presentation, not durable data. Store a machine-readable Temporal string or the underlying structured value, then format it for the user.

Assuming an offset is a time zone

An offset tells you the relationship to UTC at one moment. A named time zone carries rules for future and historical changes.

Comparing objects with normal operators

Temporal objects intentionally avoid ambiguous coercion. Use methods such as Temporal.PlainDate.compare(), equals(), since(), or until().

Ignoring availability

Stage 4 is a standards milestone, not proof that all users have upgraded browsers. Test the environments in your support matrix and provide a polyfill or fallback when needed.

A simple decision checklist

Before creating a Temporal value, ask:

Is this only a calendar date? Use PlainDate.
Is this only a clock time? Use PlainTime.
Is this one exact timestamp? Use Instant.
Does a named time zone affect the meaning? Use ZonedDateTime.
Is this an amount of time? Use Duration.

That small modelling decision prevents many bugs before arithmetic or formatting begins.

Conclusion: clearer intent is the real upgrade

Temporal is valuable not because it has more methods than Date, but because the type tells another developer what the value means.

A birthday is not a timestamp. A meeting in New York is not just an offset. One calendar day is not always 24 hours.

Temporal puts those distinctions into the API.

The safest adoption plan in 2026 is straightforward: classify existing date values, migrate one boundary at a time, use native support when available, and include the polyfill where your browser matrix needs it.

Sources

Tags: javascript, webdev, temporal, tutorial

Stop Guessing Browser Support: A Practical Guide to Web Platform Baseline in 2026

Vishal Singh — Mon, 10 Aug 2026 06:09:49 +0000

Liquid syntax error: 'raw' tag was never closed

Why Lighthouse and Real-User Core Web Vitals Show Different Results

Vishal Singh — Wed, 22 Jul 2026 08:34:57 +0000

You run Lighthouse and get a green performance score. Then you open PageSpeed Insights and the Core Web Vitals assessment says your page needs improvement.

Or the opposite happens: Lighthouse reports a slow page, while real-user data looks healthy.

Nothing is necessarily broken. The two results answer different questions.

Lighthouse gives you lab data from one controlled test. Chrome UX Report, usually called CrUX, gives you field data collected from real Chrome users. Understanding that difference can save hours of debugging the wrong problem.

Lab data: a controlled experiment

Lighthouse loads a page using predefined device and network conditions. A typical mobile run applies CPU and network throttling and usually behaves like a new visitor with a cold cache.

This makes Lighthouse useful because the test can be repeated. You can change your code, run it again, and compare the results under similar conditions.

Lighthouse is particularly useful for:

finding render-blocking resources
identifying large images or JavaScript bundles
diagnosing main-thread work
detecting layout shifts during the initial load
catching performance regressions before deployment

But a Lighthouse result is still one test from one environment. It is not a survey of every person visiting your website.

Field data: what real users experienced

CrUX collects performance measurements from eligible real Chrome users. PageSpeed Insights uses this dataset in its field-data section.

Instead of testing one simulated device, field data includes a distribution of real visits across different:

phones and computers
network speeds
locations
cache states
browsing sessions
user behaviours

CrUX generally reports a rolling 28-day view and evaluates Core Web Vitals at the 75th percentile. In simple terms, the reported value is intended to represent an experience that at least 75% of visits met or beat.

This makes field data the better answer to: “What experience are our users actually getting?”

Why the numbers disagree

1. The tested device is not your users' devices

A Lighthouse mobile test simulates a particular level of CPU and network performance. Your visitors may use faster devices, slower devices, or a completely different mix.

One lab run cannot reproduce that entire distribution.

2. Lighthouse often tests a cold load

A lab test commonly loads the page without the benefit of previously cached assets. Returning users may already have fonts, scripts and images cached.

This can make Lighthouse look worse than field data. The reverse can happen when real users face slow networks, overloaded devices or third-party content that did not appear in the lab run.

3. Real users interact with the page

A default Lighthouse audit focuses heavily on the initial page load. Real visitors scroll, open menus, accept cookie banners, load more content and use interactive components.

This difference is especially important for CLS and INP.

A page may have no obvious layout shift during loading but shift later when a lazy-loaded component, advertisement or embedded widget appears. CrUX can capture that real experience even when a basic Lighthouse run does not.

Similarly, Interaction to Next Paint depends on actual interactions. A load-only test cannot reproduce every slow click, tap or keyboard action your users encounter.

4. You may be comparing a URL with an entire origin

PageSpeed Insights shows URL-level field data when enough data is available. When it is not, it may fall back to origin-level data.

That means you could accidentally compare:

Lighthouse data for one specific page
CrUX data representing many pages across the domain

Always check whether the field section says “This URL” or “Origin” before investigating a mismatch.

5. Field data is historical; Lighthouse is happening now

Lighthouse tests the current version of the page. CrUX uses a rolling window of recent user experiences.

After deploying a performance improvement, your Lighthouse result can improve immediately while CrUX changes gradually as new visits replace older data.

6. The page is not identical for every visitor

A/B tests, ads, consent banners, personalisation, authentication state and third-party scripts can change what gets loaded.

Lighthouse may see one version while different groups of users see something else. Even repeated Lighthouse runs can fluctuate when the page or underlying conditions change.

Which result should you trust?

Trust field data when judging the experience your real users receive and whether your site meets Core Web Vitals in practice.

Use Lighthouse to diagnose problems, reproduce controlled scenarios and prevent new regressions.

It is not field data versus Lighthouse. A useful workflow needs both:

Field data tells you that a real problem exists and how widespread it may be.
Lab data helps you understand, reproduce and fix specific causes.

The overall Lighthouse performance score is also not the same thing as the Core Web Vitals assessment. Compare the individual metrics—LCP, INP and CLS—rather than expecting the two headline results to match.

A practical debugging workflow

Step 1: Read the field-data label

In PageSpeed Insights, confirm whether the CrUX result represents the exact URL or the whole origin.

Step 2: Compare individual metrics

Identify whether the disagreement is mainly in LCP, INP or CLS. Each metric points toward different causes.

Step 3: Re-run Lighthouse consistently

Use the same test mode, device category and environment. Run it more than once and look for a pattern instead of treating one score as absolute truth.

Step 4: Investigate what the lab test misses

If field data is worse, examine real user journeys:

scroll through the full page
interact with menus and forms
test consent banners and embedded widgets
check slower devices and networks
investigate post-load layout shifts
collect your own Real User Monitoring data when possible

The web-vitals JavaScript library can help collect field measurements and attribution information from your own users.

Step 5: Use Lighthouse diagnostics to fix reproducible causes

If the lab and field metrics point in the same direction, Lighthouse audits can help locate heavy resources, long tasks, delayed content and layout-shift culprits.

Step 6: Monitor after deployment

Confirm the immediate improvement in a controlled test, then watch field data over time. CrUX will not fully reflect a deployment immediately because its reporting window includes earlier visits.

A simple way to remember it

Lighthouse is a crash test performed under controlled conditions.

CrUX is information collected from cars being driven by real people on real roads.

The crash test helps engineers find weaknesses. The road data shows what drivers actually experience. You need both to build something reliable.

The next time Lighthouse and Core Web Vitals disagree, do not ask which tool is wrong. Ask what population, time window, device conditions and user journey each result represents.

Sources:

Grok Build Is Now Open Source: What Developers Can Learn from Its Coding-Agent Architecture

Vishal Singh — Mon, 20 Jul 2026 10:15:56 +0000

AI coding tools are often discussed as black boxes: you give them a task, they inspect a repository, run commands, edit files, and return a result. Grok Build is now a useful exception.

SpaceXAI has open-sourced Grok Build, its terminal-based coding agent and full-screen TUI. The public repository exposes the harness behind the product, so developers can inspect how context is assembled, model responses are parsed, tools are dispatched, and long-running work is managed.

What has been open-sourced?

The published Rust code includes:

the agent loop that connects model responses to tool calls
tools for reading, editing, searching, and running commands
the terminal UI, including plan review and inline diffs
the extension system for skills, plugins, hooks, MCP servers, and subagents

This matters because an AI coding agent is more than a model. The surrounding harness decides what context the model sees, which actions it can take, how failures are handled, and how a developer stays in control.

Three useful takeaways for developers

1. Context assembly is a product feature

A coding agent must decide which files, instructions, tool results, and previous decisions belong in the next model request. Better context is not simply more context; it is the right information at the right time.

2. Tool execution needs a feedback loop

The model can propose an edit or command, but the harness must execute it, capture the result, surface errors, and feed useful evidence back into the next step. Reliability comes from this loop, not from one perfect prompt.

3. Extensibility should have clear boundaries

Grok Build supports skills, plugins, hooks, MCP servers, subagents, AGENTS.md instructions, and configuration. The architecture is a good reference for anyone building an internal developer agent that must adapt to different repositories and workflows.

Can you run it yourself?

The repository contains the Rust source for the Grok CLI/TUI and its agent runtime. You can compile it locally, and the official announcement says it can be pointed at local inference through config.toml. Prebuilt installers are also available for macOS, Linux, and Windows.

One important distinction: an open-source agent harness does not automatically make every hosted model or service free. The code, model access, authentication, and usage costs are separate layers, so check the current terms before choosing a setup.

Why this release is worth studying

Even if you do not plan to switch coding assistants, the repository is valuable as a real-world reference for agent loops, terminal UX, tool dispatch, sandboxing, memory, and extensibility.

Open-source coding agents make an important question easier to answer: not only "What can the model do?" but also "How does the system decide, act, verify, and recover?"

Would you explore the Grok Build source to learn from the architecture, contribute your own extension, or run it with local inference?