Just came across this RFC. Given I've been maintaining XHP as a
functioning PHP extension for years now (not sure if sending links in my
very first internals message is going to flag something but it's
TJ09/xhp-php-extension on github) I wanted to weigh in on the proposal
here.
1.
> Technically, markup must begin at a bare < in operand position, and
telling that apart from the comparison and shift operators requires the
scanner change described under Backward Incompatible Changes - state no
extension can reach. The only route open to an extension is rewriting
source text before compilation (the original XHP extension's approach),
which shifts line numbers in errors and stack traces and leaves the raw
file something token_get_all() - and therefore every tool built on it -
cannot tokenize.
The extension takes care to avoid shifting line numbers; the
preprocessed code ends up looking quite messy as a result but human
readability was I think never the goal for what is functionally an
intermediate representation.
> Practically, a syntax lives or dies by its ecosystem. Code using an
extension-only syntax cannot be reasonably published to Packagist - it
is a parse error on any install without the extension - and no IDE,
formatter, or static analyser updates its grammar for syntax that may
not exist on a given machine. That chicken-and-egg is part of where XHP
for PHP stalled, while the same feature thrived in Hack, where it is
part of the language. Shipping in core is what makes markup part of PHP
itself: parsers, IDEs, and analysis tools implement it once, and every
developer's markup gets the same highlighting, formatting, and static
analysis their ordinary code already enjoys.
This, though. This is the big thing. While it is *technically* possible
for extensions to add new syntax, it is unreasonable to expect tools to
be aware of that syntax. I can absolutely confirm that the biggest point
of friction in using XHP today is the fact that static analysis tools
like psalm or phpstan can't analyze files, code using XHP cannot be
formatted or linted with php-cs-fixer, etc.
2.
One thing I think is missing that is commonly used in both my own XHP
code but also various JSX frameworks is the idea of context. That is,
the ability to pass data through parts of a tree without explicitly
passing it through attributes. Factories/decorators may solve some of
the need for this, but they seem to be global, so it doesn't seem
possible to inject context into only a single subtree.
3.
> This RFC is deliberately narrower than XHP: it targets HTML
specifically, not general XML.
Does this mean that inline SVG is out of the question? It's not uncommon
to embed SVG in HTML, but it does often rely on XML features...
-T.J. L
On 7/14/26 7:36 PM, Liam Hammett wrote:
Hi internals,
I'd like to open discussion on a new RFC, "Native Markup Expressions":
RFC: https://wiki.php.net/rfc/native_markup_expressions
Implementation (with tests): https://github.com/php/php-src/pull/22661
It proposes a native syntax for HTML fragments as first-class PHP expressions,
akin to how the frontend community has adopted JSX, with composition and
escape-by-default output:
class Greeting implements Markup\Html
{
public function __construct(public string $name) {}
public function toHtml(): Markup\Html
{
return <>
<h1 class="title">Hello, {$this->name}!</h1>
<p>Welcome to PHP, where markup is a first-class
expression.</p>
</>;
}
}
echo <Greeting name="Rasmus" />; // rendered HTML, values escaped
Despite appearances, this is not a template language grafted onto the engine -
the syntax is pure compile-time sugar. Every markup expression lowers
during compilation to a plain `new` expression:
$html = <button class="btn">Sign in</button>;
// compiles to exactly:
$html = new \Markup\Element('button', ['class' => 'btn'], ['Sign in']);
The RFC already answers many anticipated questions, and I am open
to making further adjustments so this can become a feature the whole
community benefits from.
Looking forward to your feedback.
Best regards,
Liam
