On 12/23/25 16:12, Andrey Andreev wrote:
On Tue, Dec 23, 2025 at 12:30 PM Sergei Issaev <[email protected]> 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
