Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129683
Message-ID: <03590ce8-8037-4409-bc0e-603c692fe349@sandfox.me>
Date: Tue, 23 Dec 2025 17:43:29 +0200
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC Idea] Short echo tag with automatic HTML escaping
 (<?~ ... ?>)
To: 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>
Content-Language: en-US
In-Reply-To: <c35b9f9b-9896-4b40-82fa-6d69f33b901f@mail.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: sandfox@sandfox.me (Anton Smirnov)



On 23/12/2025 12:26, Sergei Issaev wrote:
> However, I’d like to gently push back on two points:
> 1. <?~ vs <? (~$expr) under short_open_tag=On
> 
> You're correct that with short_open_tag=1, <?~ $x ?> would currently be 
> parsed as <? (~$x) ?>. But in practice:
> - short_open_tag has been disabled by default since PHP 5.4 (2012).

But there is no plan to remove them, see

https://wiki.php.net/rfc/deprecate_php_short_tags_v2
https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags

> - Most modern frameworks and coding standards explicitly discourage its 
> use.

Since they are still a valid code, so PHP and various coding standard 
tools must parse them correctly.

> - The <?= short echo tag is always available regardless of 
> short_open_tag, precisely because it’s treated specially.
> 
> If the RFC were to propose <?~ as a new short echo variant (like <?=), 
> it would follow the same rule: always enabled, independent of 
> short_open_tag. That would eliminate the ambiguity you mentioned.

No it doesn't. The grammar should stay consistent for every possible ini 
state. I have a feeling that the tokenizer won't even compile with this 
syntax. (not sure)

> 2. Why not just use h()?
> 
> 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.

That also leads to a tailored experience suitable for a specific project 
and context. I also don't see an inconsistent escaping as a huge problem 
as long as it does its job.

> 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().

Secure today does not mean secure tomorrow. With the existing function 
you can simply update the default flag set, or users can update their 
flag sets ahead of PHP. For the syntax approach to be as flexible, it 
needs to be configurable by some global state (set_escape_flags()? ini 
config?) which is also a big no-no, that would be magic quotes all over 
again, just slightly more explicit.

Magic quotes btw should be a lesson that you can't make stuff secure by 
a simple all size fits all solution.

> Think of it like <?= ... ?>: it didn’t add new capability, but it made 
> the common case easier and more consistent. <?~ ... ?> aims to do the 
> same for secure output.

<?= exists since forever and "= $expr" is not a valid code. You should 
at least choose another symbol (like "<?*")

> That said, I hear your concern about hardcoded flags. If the community 
> prefers, the escaping behavior could even respect default_charset and a 
> new html_output_flags ini setting — though I’d argue opinionated 
> security defaults are better here.

See above, also respecting default_charset is a must imho, not everyone 
uses UTF-8, East Asia specifically. Introducing a core syntax and 
excluding a huge portion of users is not a good move.

-- 
Anton