Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129681
Message-ID: <ee607afa-7306-428d-9ca9-6f4070fc8940@mail.ru>
Date: Tue, 23 Dec 2025 16:42:38 +0500
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC Idea] Short echo tag with automatic HTML escaping
 (<?~ ... ?>)
To: Andrey Andreev <narf@devilix.net>
Cc: Anton Smirnov <sandfox@sandfox.me>, internals@lists.php.net
References: <7c592a80-76a5-4b16-9c7b-a354aa34802a@mail.ru>
 <dd9cb977-37d4-4e33-ae0f-65c02502d8f9@sandfox.me>
 <c35b9f9b-9896-4b40-82fa-6d69f33b901f@mail.ru>
 <CAPhkiZy4nRToyDbuY7ZWum176JYp93sVeJS6Azn12up+0RHmzA@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAPhkiZy4nRToyDbuY7ZWum176JYp93sVeJS6Azn12up+0RHmzA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: sergei_vi@mail.ru (Sergei Issaev)

On 12/23/25 16:12, Andrey Andreev wrote:
> On Tue, Dec 23, 2025 at 12:30 PM Sergei Issaev <sergei_vi@mail.ru> wrote:
>
>
>     Yes, h() works — and many projects already define it. But that’s
>     exactly
>     the problem: everyone reinvents it, often with slightly different
>     flags,
>     encoding assumptions, or error handling. This leads to:
>     - Inconsistent escaping across projects or even within the same
>     codebase.
>     - Junior developers skipping escaping because “it’s not built in”.
>     - Security relying on project-specific conventions rather than
>     language-level defaults.
>
>     By providing a standard, secure-by-default output tag in core, PHP
>     would:
>     - Reduce boilerplate.
>     - Encourage safer habits out of the box.
>     - Give small projects (e.g., WordPress plugins, scripts, internal
>     tools)
>     a zero-dependency way to escape safely — without requiring them to
>     define or remember h().
>
>
> I can relate to these pain points, but I also think your conclusions 
> are a bit of wishful thinking.
>
> Junior developers would still not use it, because they'd need to know 
> it first - just like h(). Even seasoned developers would avoid it 
> because many will deem the syntax to be ugly, and the solution 
> imperfect. And security gets a band-aid instead of proper protection, 
> which is more dangerous than you'd think - I've seen it time and time 
> again, some feature offers limited security benefits, people only care 
> to remember that "it's secure", use it for everything without critical 
> thought, and you end up with masses of developers believing that they 
> write secure code when it's not even close to that. Then PHP has to 
> take the blame for providing insecure XSS escaping.


You are correct that the <?~ ?> syntax alone cannot provide 
comprehensive XSS protection, and it is important not to create a false 
sense of security. I will remove direct mentions of XSS from the 
description to avoid misleading anyone.

My main goal is not to replace contextual escaping, but to offer a 
standard, recognizable syntax for a frequent operation — outputting 
HTML-escaped strings. Yes, developers currently use htmlspecialchars(), 
wrappers like <?=h(...)?>, etc. But it is precisely the lack of a 
unified, "native" method that creates inconsistency and inconvenience.

Language evolution often follows the path of simplifying routine 
operations: array() → [], cumbersome isset() checks → the concise ??. 
Similarly, <?~ ... ?> could become the same standard and expected way 
for safe output as <?= is for direct output. This will make the default 
code for embedding dynamic content into HTML structure not only faster 
to write but also instantly readable for any developer.

That is precisely why I am proposing this feature — not as a security 
panacea, but as a step toward making it as quick and habitual to write 
structurally correct HTML code as it is to write unsafe code.

Best regards,
Sergei Issaev