Re: [RFC] [Discussion] Native Markup Expressions

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 On 7/14/26 8:50 PM, Liam Hammett wrote:

On Wed, Jul 15, 2026 at 1:33 AM Garrett W. <cbdrum05@gmail.com> wrote:

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.

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 Wed, Jul 15, 2026 at 1:33 AM Garrett W. <cbdrum05@gmail.com> wrote:

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.