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.
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.
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.
In one line: fewer headline features, more CSS details brought into agreement.
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.
at-rule() function is usable inside
@supports, so you can branch onrevert keyword now works in @rule
contextsloading="lazy") for
<video> and <audio> is on by
defaultRemnants of the <command> element were removed.
Most applications are unaffected,
but check if you carry old code forward.
In one line: multi-column layout gained
expressiveness, and Japanese typography
gained one container.
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.
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.
shape-outside accepts path(),
shape(), rect() and xywh(), so
text can wrapCSSPseudoElement interface for handling
pseudo-elements as JavaScript objectsposition: sticky tracks overflow per axiscurrentColorThe column-rule renames above mean stylesheets written with the
pre-149 names
stop working. Rewrite them if you use them.
In one line: the richest of these five versions, and the foundation of BlinkGTK v1.1.0.
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.
corner, includingcorner-block-starttext-fit — automatically size text to fit a given
boximage() function, and image support in
light-dark() for light/dark variantsbackground-clip: border-areabalance for even line distribution under
flex-wrapscroll-axis-lockfocusgroup — declare arrow-key focus movement as a
groupcorners property was renamed to
cornerhint behaviour changedIn one line: for Japanese typography, the most direct gain in these five versions.
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.
<textarea>
fixedTextStream method, UserMediaElementfeImage honours EXIF orientation| 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 |
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.
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.