v153 · navigation · feature removal

The fifth keyword that only Chrome had

A link's target is a browsing-context name, unless it is one of four reserved keywords. Blink quietly carried a fifth — _current, meaning "this frame" — that no specification describes and no other engine implements. Chrome 153 removes it, and the difference is something you can watch happen in a frame tree.

concepts

  1. Which frame actually moved

    Put a frame genuinely named _current next to the frame doing the linking and click for real. Whichever frame ends up somewhere new tells you which side of the removal your browser is on.

  2. The keywords that are real

    Sweep _self, _parent, a plain frame name and _current through the same tree, with _top and _blank resolved but deliberately not fired. The odd one out is visible in the table.

  3. Auditing your own targets

    Paste your markup in and every target is classified against the keywords and the frame names the document declares — including the case-insensitive spellings a grep misses. Plus the experiment that shows what _current becomes afterwards.

why it shipped

The rules for choosing a navigable are short: if the target is _self, _parent, _top or _blank, do the special thing; otherwise look for a browsing context with that name, and create one if there is none. Four keywords, then names. Every engine agrees, which is what makes frame names safe to choose.

Blink's copy of those rules had an extra branch for _current, behaving as _self. The cost was small but real: a document with a frame named _current could not target it from Chrome, and identical markup navigated a different frame depending on the engine. Chrome's own metrics put the usage at roughly 0.00009% of page loads, which is the shape of a removal that costs almost nobody anything and returns the engine to the specified behaviour.

the shape of the change

// Before Chrome 153, in Chrome only:
<a href="/next" target="_current">   // navigates this frame
<iframe name="_current">             // unreachable by name from this tree

// From Chrome 153, everywhere:
<a href="/next" target="_current">   // navigates the frame named _current,
                                     // or opens a new context if there is none
<a href="/next" target="_self">      // navigates this frame — always did

what these pages measure

The pages were built and driven on Chrome 150, which still has the keyword, so what they record is the before side of the removal: target="_current" navigates the source frame and ignores a sibling actually named _current, and the uppercase spelling _CURRENT reaches the same branch — keyword matching is ASCII case-insensitive. On a Chrome 153 or later the same pages report the other outcome without any change, because they read the frame tree rather than the user agent string.

One claim could not be measured directly on a browser that still has the keyword: that _current resolves as an ordinary name afterwards. The auditor page tests it with _notakeyword instead — an underscore-prefixed name no engine special-cases — and it resolves through the ordinary lookup, which is the mechanism _current falls back into.

references