Filed from objectui, not fixed here: this is the upstream twin of
objectstack-ai/objectui#5661,
whose triage required the twin check and ruled that the cross-repo copy must be a
separate card rather than a rider on the objectui PR.
Measured, on origin/main (acb4dbc)
packages/sdui-parser/src/parse.ts, inside parseChildren's children loop:
// :167consttext=this.readTextRun();// :168consttrimmed=text.replace(/\s+/g,' ').trim();if(trimmed)children.push(trimmed);
The collapse (\s+ → one space) is correct and is HTML's own whitespace model.
The .trim() is not: HTML collapses a whitespace run to one space, it does not
delete it. What gets deleted is exactly the space separating a text run from an
adjacent inline sibling, so A <strong>x</strong> page parses to
['A', {strong}, 'page'] — the words run together wherever that tree is rendered.
The two copies have drifted — this is not a byte copy
Both files were diffed in full (objectui origin/main190fbd01d against
objectstack origin/mainacb4dbc). The whole difference is objectui's html-tier
provenance stamp (objectui#4000): one added import and an 8-line comment plus
markHtmlTierNode(...) at the node-construction site. That 9-line block is the
entire reason the line numbers differ (objectui :176/:177, objectstack
:167/:168); the defective statement itself is byte-identical in both.
So a patch cannot simply be cherry-picked by line number, and the two files should
be expected to keep drifting.
What is different about the consequence here
In objectui the parser output is rendered — the symptom is user-visible text with
its words run together. In this repo the only in-tree consumer measured is
packages/lint/src/validate-jsx-pages.ts, which uses parseJsx/compile for
build-time diagnostics; its findings do not depend on the whitespace, so nothing is
visibly broken today. The defect matters here as contract drift: the same authored
source produces a different tree in the two repos, and it produces the wrong one in
both.
The fix already ruled on downstream
objectui triage chose option (b) and it landed there as
objectstack-ai/objectui#5661: collapse the run, then keep one leading space when a
sibling precedes it and one trailing space when a sibling element follows; the
parent's own start/end still drop their edge space. It is mechanical — it invents no
block/inline taxonomy for a schema tree that has none. Its one bounded cost is that a
whitespace-only run between two siblings survives as a single space, so a
pretty-printed <ul> gains one ' ' child per inter-item gap; the objectui PR pins
that bound with a <ul> control.
Whether this repo takes the same rule is this card's decision, but adopting the
downstream ruling verbatim is the cheap answer and keeps the two parsers agreeing.
Filed from objectui, not fixed here: this is the upstream twin of
objectstack-ai/objectui#5661,
whose triage required the twin check and ruled that the cross-repo copy must be a
separate card rather than a rider on the objectui PR.
Measured, on
origin/main(acb4dbc)packages/sdui-parser/src/parse.ts, insideparseChildren's children loop:The collapse (
\s+→ one space) is correct and is HTML's own whitespace model.The
.trim()is not: HTML collapses a whitespace run to one space, it does notdelete it. What gets deleted is exactly the space separating a text run from an
adjacent inline sibling, so
A <strong>x</strong> pageparses to['A', {strong}, 'page']— the words run together wherever that tree is rendered.The two copies have drifted — this is not a byte copy
Both files were diffed in full (objectui
origin/main190fbd01dagainstobjectstack
origin/mainacb4dbc). The whole difference is objectui's html-tierprovenance stamp (objectui#4000): one added import and an 8-line comment plus
markHtmlTierNode(...)at the node-construction site. That 9-line block is theentire reason the line numbers differ (objectui
:176/:177, objectstack:167/:168); the defective statement itself is byte-identical in both.So a patch cannot simply be cherry-picked by line number, and the two files should
be expected to keep drifting.
What is different about the consequence here
In objectui the parser output is rendered — the symptom is user-visible text with
its words run together. In this repo the only in-tree consumer measured is
packages/lint/src/validate-jsx-pages.ts, which usesparseJsx/compileforbuild-time diagnostics; its findings do not depend on the whitespace, so nothing is
visibly broken today. The defect matters here as contract drift: the same authored
source produces a different tree in the two repos, and it produces the wrong one in
both.
The fix already ruled on downstream
objectui triage chose option (b) and it landed there as
objectstack-ai/objectui#5661: collapse the run, then keep one leading space when asibling precedes it and one trailing space when a sibling element follows; the
parent's own start/end still drop their edge space. It is mechanical — it invents no
block/inline taxonomy for a schema tree that has none. Its one bounded cost is that a
whitespace-only run between two siblings survives as a single space, so a
pretty-printed
<ul>gains one' 'child per inter-item gap; the objectui PR pinsthat bound with a
<ul>control.Whether this repo takes the same rule is this card's decision, but adopting the
downstream ruling verbatim is the cheap answer and keeps the two parsers agreeing.