# [RFC] [Discussion] Native Markup Expressions

- Thread: https://externals.io/message/131925
- Original archive: https://news-web.php.net/php.internals/131925
- Started by Liam Hammett on 2026-07-14T23:36:21+00:00
- Messages: 10
- RFC: Native Markup Expressions (Under discussion) — https://externals.io/rfc/native_markup_expressions.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #131925 — Liam Hammett — 2026-07-14T23:36:21+00:00

URL: https://externals.io/message/131925#131925

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

---

## #131926 — Garrett W. — 2026-07-15T00:33:07+00:00

URL: https://externals.io/message/131925#131926 · In reply to: #131925

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.

---

## #131928 — Liam Hammett — 2026-07-15T00:50:26+00:00

URL: https://externals.io/message/131925#131928 · In reply to: #131926

>
> On Tue, Jul 14, 2026 at 7:31 PM Liam Hammett
> <liam+phpinternals@liamhammett.com> wrote:
> > […]
>
> Cool! I'm reading through it now, and one thing gave me pause:
>
> > […]
>
> 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.

That's fair - PSR-4 isn't binding, and lowercase class names are legal
in PHP - it's a real tradeoff. While in theory I agree, I'd note JSX
uses this exact heuristic (lowercase = regular HTML element,
capitalised = component) and it's held up well with the frontend
ecosystem at scale for more than a decade. A few reasons I think it's
the right call here too:

1. Fallback resolution turns typos into silent bugs. With the
capitalisation rule, `<Layuot />` fails loudly with a class-not-found
error. With fallback resolution, it silently renders as a literal
`<Layuot>` element and you find out in the browser, if you find out at
all.
2. Markup expressions lower to `new` expressions at compile time.
Fallback resolution requires knowing whether a class exists, which
means hitting the autoloader - so tag meaning could no longer be
decided at compile time. It would also make markup
load-order-dependent: whether `<div>` means an element or a component
would depend on whether any loaded code defines a class named `div`,
and defining one later would silently change the meaning of existing
markup elsewhere.
3. The common case is plain HTML with components sprinkled in. The
heuristic lets the compiler treat lowercase tags as pure data with
zero resolution work for a performance boon.

Best regards,
Liam


>
> On Tue, Jul 14, 2026 at 7:31 PM Liam Hammett
> <liam+phpinternals@liamhammett.com> wrote:
> > […]
>
> Cool! I'm reading through it now, and one thing gave me pause:
>
> > […]
>
> 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.

---

## #131931 — Garrett W. — 2026-07-15T01:24:08+00:00

URL: https://externals.io/message/131925#131931 · In reply to: #131925

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.

---

## #131936 — Edmond Dantes — 2026-07-15T13:16:41+00:00

URL: https://externals.io/message/131925#131936 · In reply to: #131925

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

---

## #131955 — Morgan — 2026-07-16T03:34:27+00:00

URL: https://externals.io/message/131925#131955 · In reply to: #131925

> 
> 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.

---

## #131982 — Edmond Dantes — 2026-07-16T19:58:38+00:00

URL: https://externals.io/message/131925#131982 · In reply to: #131955

Hello!

> > […]
https://github.com/true-async/php-src/compare/master...dsl-hooks

Your wish has been granted. 🙂

Here's an article explaining how it works. I didn't spend much time
thinking about the syntax—I simply borrowed it from JavaScript. 🙂
A huge thanks to Kirill for answering countless questions on this topic and
showing me the different approaches PHP has historically used to solve
problems like this.

https://x.com/Edmondif143061/status/2077842921827512720

The performance is expected to be excellent, especially if the parser is
implemented in C.

The generated code is compiled and cached immediately. There is no longer
any need to rely on backdoor techniques to implement features like this.

PHP could easily gain its own LINQ. This would also speed up SQL-like code,
since it would no longer need to be constructed at runtime. Doctrine, for
example, would no longer need to implement complex caching mechanisms to
compensate for that.

If there's anything I can do to help with the RFC, I'd be happy to
contribute.

чт, 16 июл. 2026 г. в 22:51, Morgan <weedpacket@varteg.nz>:

> 
> > […]
> expressions,
> > […]
> 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.

---

## #131983 — Edmond Dantes — 2026-07-16T20:05:06+00:00

URL: https://externals.io/message/131925#131983 · In reply to: #131955

I'd also like to point out that, with relatively small changes, PHP could
likely be taught to react to attributes at compile time. That would make it
possible to implement AOP, actors, and many other language extensions based
on macros.

Essentially, what you're seeing here is macros in their purest form the
same concept that exists in Rust today.

чт, 16 июл. 2026 г. в 22:51, Morgan <weedpacket@varteg.nz>:

> 
> > […]
> expressions,
> > […]
> 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.

---

## #132172 — T.J. L — 2026-08-05T16:44:34+00:00

URL: https://externals.io/message/131925#132172 · In reply to: #131925

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


> 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

---

## #132173 — T.J. L — 2026-08-05T16:45:17+00:00

URL: https://externals.io/message/131925#132173 · In reply to: #131928

> That's fair - PSR-4 isn't binding, and lowercase class names are legal
in PHP - it's a real tradeoff. While in theory I agree, I'd note JSX
uses this exact heuristic (lowercase = regular HTML element,
capitalised = component) and it's held up well with the frontend
ecosystem at scale for more than a decade.

Doing this also means there is no runtime enforcement or type-checking 
of HTML tags or their attributes. One of the original selling points of 
XHP is that it won't let you output invalid HTML, and runtime validation 
is important for that.

JSX gets away with it in large part because of the Typescript ecosystem, 
where static analysis covers a lot of ground. I don't think core PHP 
syntax should be assuming people are using such tools, though. Is the 
performance improvement of not instantiating every HTML tag expected to 
be significant?

-T.J. L


> 
> > […]
> That's fair - PSR-4 isn't binding, and lowercase class names are legal
> in PHP - it's a real tradeoff. While in theory I agree, I'd note JSX
> uses this exact heuristic (lowercase = regular HTML element,
> capitalised = component) and it's held up well with the frontend
> ecosystem at scale for more than a decade. A few reasons I think it's
> the right call here too:
>
> 1. Fallback resolution turns typos into silent bugs. With the
> capitalisation rule, `<Layuot />` fails loudly with a class-not-found
> error. With fallback resolution, it silently renders as a literal
> `<Layuot>` element and you find out in the browser, if you find out at
> all.
> 2. Markup expressions lower to `new` expressions at compile time.
> Fallback resolution requires knowing whether a class exists, which
> means hitting the autoloader - so tag meaning could no longer be
> decided at compile time. It would also make markup
> load-order-dependent: whether `<div>` means an element or a component
> would depend on whether any loaded code defines a class named `div`,
> and defining one later would silently change the meaning of existing
> markup elsewhere.
> 3. The common case is plain HTML with components sprinkled in. The
> heuristic lets the compiler treat lowercase tags as pure data with
> zero resolution work for a performance boon.
>
> Best regards,
> Liam
>
> 
> > […]