[RFC] [Discussion] Native Markup Expressions

On Tue, Jul 14, 2026 at 7:31 PM Liam Hammett
liam+phpinternals@liamhammett.com 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

Cool! I'm reading through it now, and one thing gave me pause:

Any tag whose name is capitalized, contains a namespace separator (), or names a static method (::) is a component; everything else is a literal HTML element.

Not so sure about that heuristic. PSR-4 is not a binding standard on
the language; class names can be lowercase, and therefore should be
valid as a component name. Instead of looking at whether the tag name
is capitalized, I'd think it would be better handled using the
standard fallback resolution strategy: look in the current namespace,
then look at imports, then global/root namespace, and only then
fallback to a literal HTML tag.

--
Garrett W.

On Tue, Jul 14, 2026 at 7:31 PM Liam Hammett
liam+phpinternals@liamhammett.com 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

So if I can do <ClassName::staticMethod ...>, what about
<$obj->method ...> if that method returns a Markup\Html (not a
string)? I didn't see that case addressed in the RFC, so I can only
assume that would be an error, but ... should it be allowed?

--
Garrett W.

Hi!
Firt of all thank you a lot for this RFC! It's a great idea!

I have one small addition.

PHP already provides a way to write extensions that hook into AST parsing.
However, it's too coarse grained. It forces you to intercept the entire AST
pipeline instead of extending PHP's behavior at specific points.

It would be much cleaner and honestly much cooler to make the PHP parser
extensible at well defined extension points. That would enable not only
JSX-like syntax, but also QL-like expressions to be integrated into PHP
cleanly.

In that case, PHP could provide them as separate ext modules.

Best Regards, Ed!

ср, 15 июл. 2026 г. в 16:11, Liam Hammett <liam+phpinternals@liamhammett.com

:

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

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:

Heh, just today by coincidence I was pointed toward https://jsx.lol/ -
which, despite the name is more about React in general.

I'm more partial to Edmond Dantes's suggestion of providing parser hooks
so that different markup expression syntaxes can be added via extension,
rather than locking in one that happened to be popular at one time.

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.

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.

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.

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

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