Chromium 147 → 151 — What BlinkGTK Gained

Version: 1.2.0-build2 / Language: English | 日本語

BlinkGTK embeds Chromium's rendering engine, Blink, as-is. When Chromium gains a new
web capability, moving BlinkGTK to a newer base gives you that capability directly.
This document walks through what changed across Chromium 147, 148, 149, 150 and 151 —
the versions BlinkGTK has been built on — from the side of what you can actually do.

It is not a digest of specifications. We diffed the engine source trees themselves,
version against version, and selected what matters to you. The exact method is at the end.


How to read this — "landed" is not "usable"

Web features do not reach every user the moment they are written. In Blink, each feature
carries a runtime flag, and its state decides whether the feature is on by default.
This document distinguishes three states. Mixing them up produces the worst kind of
documentation bug — "it's written here but it doesn't work" — so let us be explicit.

Label Flag state Meaning
On by default stable Works with no action. Available in BlinkGTK as-is
Experimental experimental Off by default; enable explicitly with a launch flag
In development test Test runs only. The property may parse, but rendering is unaffected

The third one is the trap. hanging-punctuation — hanging punctuation at line edges,
long awaited in Japanese typography — landed as a CSS property in 149. It parses,
and getComputedStyle() returns a value. But its implementation flag is still test
as of 151, so it does not affect line layout. "The property exists" and
"the typesetting changes" are two different events.

Measured, this mismatch shows up in a way that lies to feature detection
(BlinkGTK v1.2.0 / Chromium 151):

without the flag                                   -> CSS.supports(...) = false
with --enable-blink-features=CSSHangingPunctuation -> CSS.supports(...) = true
                                                      getComputedStyle = "allow-end"

CSS.supports() returns true, yet line layout does not change by a single pixel.
With a container exactly eight characters wide holding "eight characters + a full stop",
hanging would keep it on one line — but both none and allow-end produce two lines.

So CSS.supports('hanging-punctuation', ...) is not a usable feature check here.
Design your pages as if the feature does not exist yet.


The shape of it

Across five versions, the engine's feature flags grew from 1,103 to 1,214.

Chromium Feature flags Newly on by default Added Removed CSS properties BlinkGTK
147 1,103 800 v1.0.6 – v1.0.10-build16
148 1,116 34 47 34 800 v1.0.11-dev
149 1,140 39 52 28 803 (tracked only)
150 1,172 48 51 19 820 v1.1.0-build1 – build6
151 1,214 44 64 22 822 migration in progress (2026-08)

Each version turns on 30–50 features by default and removes 20–35. Removals are easy
to overlook, yet they are the more likely reason an upgrade breaks something. That is why
every section below ends with migration notes.


147 → 148 — Underlines and container queries settle down

In one line: fewer headline features, more CSS details brought into agreement.

Text

Underlines now skip descenders (wider application of text-decoration-skip-ink).
When an underline crosses the tail of a g or p — or a Japanese — legibility
drops visibly. This was experimental in 147 and became the default in 148.

Variable-font avar2 support also landed: the newer table format for varying weight and
width continuously within a single font file.

CSS

Elsewhere

Migration notes

Remnants of the <command> element were removed. Most applications are unaffected,
but check if you carry old code forward.


148 → 149 — Column rules, and a vessel for hanging punctuation

In one line: multi-column layout gained expressiveness, and Japanese typography
gained one container.

For Japanese typography

hanging-punctuation landed as a CSS property — hanging punctuation and brackets
outside the text block at line start or end (none / first / last / allow-end).
It maps directly onto what JIS X 4051 and JLReq require. Values parse, and
getComputedStyle() reports them.

But as noted above, the implementation flag is still test as of 151. You can write
it; it does not yet take effect. This is one to watch upstream, and BlinkGTK is
tracking it.

Caret movement across lines containing ruby was fixed. Pressing up/down in ruby-annotated
body text no longer behaves differently depending on whether ruby is present. Editors
benefit directly.

text-decoration-skip-spaces was added, controlling whether underlines skip inter-word spaces.

Column rules

Rules drawn between columns and rows (column-rule / row-rule) were substantially
extended. Where a rule stops, and how it behaves at junctions, is now expressible through
the *-inset-cap and *-inset-junction families. Rules running past the end of a column
can be solved in CSS alone.

Note that in 148 these were named column-rule-edge-inset and column-rule-interior-inset;
149 renamed them to -inset-cap and -inset-junction as the specification settled.

Elsewhere

Migration notes

The column-rule renames above mean stylesheets written with the pre-149 names
stop working. Rewrite them if you use them.


149 → 150 — Tools for tightening the text block

In one line: the richest of these five versions, and the foundation of BlinkGTK v1.1.0.

For Japanese typography

text-box-trim now works inside nested lists. This trims the font-derived space
(half-leading) above and below a line so the text block is built from the intended glyph
height. In Japanese layout you need this to bring the gap between a heading and body text
down to the designed value.

Full-width space handling was fixed. Reusing the offset mapping between text and
layout no longer breaks on full-width spaces, so selection ranges and break positions stay
correct in text that mixes them in.

Grapheme cluster bounds checking landed, making it harder to split emoji ligatures
and combining sequences when moving the caret or deleting.

text-transform now applies to ::first-line, and line-breaker abort handling improved.

CSS

Elsewhere

Migration notes


150 → 151 — Ruby and emphasis marks come into their own

In one line: for Japanese typography, the most direct gain in these five versions.

For Japanese typography

Ruby overhang (ruby-overhang) is on by default. Experimental since 147, it finally
becomes the default in 151. It controls how far ruby text may extend over neighbouring
base characters when the annotation is longer than what it annotates. A none value
arrived alongside it. This is the engine meeting JLReq head-on on how ruby may be placed.

Emphasis marks (boten) are now processed through the ruby path. This sounds like an
internal detail, but the typeset result changes. Previously, adding emphasis marks
grew the line box itself; in 151 the line box stays at line-height and the outer
container grows instead.

We measured the effect on a 151 build: vertical writing mode, font-size: 16px,
text-emphasis-style: sesame, reading the actual paragraph pitch.

Leading available Without marks With marks Delta
Yes (line-height: 2.6 = 41.59px) 150 41.59 44.09 +2.50
151 41.59 41.59 0
No (line-height: 1.75 = 28px) 150 28.00 37.00 +9.00
151 28.00 30.00 +2.00

Given room in the leading, emphasis marks no longer grow the line pitch. Without
room, the growth shrinks from +9.00 in 150 to +2.00. In Japanese vertical documents that
use emphasis marks heavily, the line count of the text block can change, and total page
count can drop
. That is why we suggest verifying existing layouts — the change is for
the better, but it is still a change.

text-autospace now ignores ruby annotations, so automatic spacing between Latin and
Japanese is no longer perturbed by ruby text.

Line breaking is allowed after a space preceding an open tag, which reduces breaks
landing in unintended places in markup such as 日本語 <span>語</span>.

Experimentally, AnnotationSpaceOnStart (space on the start side of an annotation)
landed. It is off by default, but worth watching as it concerns spacing around ruby and
emphasis marks.

Editing and selection

Elsewhere

Migration notes — things may break here

Change Impact
Emphasis marks via ruby path Line height and total line count may change in documents using them
readyState of document.implementation.createHTMLDocument() The state right after creation now follows the specification
Nested popover hint Showing one nested now throws
getComputedStyle outside the flat tree Off by default
Sub Apps API Removed

Where Japanese typography stands — the five versions at a glance

Given that BlinkGTK is used mainly for Japanese vertical-writing e-books, here are the
relevant items alone. A dash means the item did not exist in that version.

Item 147 148 149 150 151
Ruby overhang (ruby-overhang) exp. exp. exp. exp. default
Emphasis marks via ruby path default
text-autospace ignores ruby default
Break after space before open tag default
Annotation space on start exp.
text-box-trim in nested lists default default
Full-width space offset mapping fix default default
Caret movement across ruby lines default default default
Underlines skip descenders exp. default default default default
Hanging punctuation property only (in dev.) same same
Vertical multi-column fragmentation (BlinkGTK) exp. exp.

Two things follow.

First, ruby and emphasis marks advanced sharply in 151. ruby-overhang, held in
experimental status for four versions, became the default, and the emphasis mark
implementation was reorganised. If you are building a vertical-writing reader, a
151-based BlinkGTK is distinctly worth having.

Second, hanging punctuation has not arrived. The property was provided in 149, but the
implementation is still in development as of 151. Full JLReq conformance needs this one
move, and BlinkGTK continues to track it.

The last row is a feature upstream Chromium does not have — fragmentation for multi-column
layout in vertical writing mode, which BlinkGTK adds itself. Receiving from Chromium is
not the whole story; where something is missing, we fill it in.


Sources, and how this diff was taken

To keep speculation out, everything here was extracted mechanically from the engine source
trees. Anyone can reproduce it.

What we read File
Feature flags and their default state third_party/blink/renderer/platform/runtime_enabled_features.json5
The CSS property list third_party/blink/renderer/core/css/css_properties.json5

For 151 we went further and checked what a BlinkGTK build actually does. Upstream may
declare a feature stable while the final default still depends on build configuration.
The table below is read from the generated code (runtime_enabled_features.cc).

Feature Default in the BlinkGTK 151 build
Ruby overhang (CSSRubyOverhang) on
Emphasis marks via ruby path (TextEmphasisAsRuby) on
text-autospace ignores ruby annotations on
Break after space before open tag on
Hanging punctuation (CSSHangingPunctuation) off
Vertical multi-column fragmentation (BlinkGTK) off (opt-in)

The prose above matches these measurements. We say hanging punctuation is unusable
because it is off in the actual build, not merely by upstream declaration.

For each version we parsed these two files into a feature-name → state map and diffed
adjacent versions. Every count quoted above — newly-default, added, removed — is an actual
figure from that diff.

Inferring meaning from a feature name invites error, so items we could not confirm are
not in this document
. That is why the counts exceed the number of items described.