Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129680
Precedence: list
MIME-Version: 1.0
References: <7c592a80-76a5-4b16-9c7b-a354aa34802a@mail.ru> <dd9cb977-37d4-4e33-ae0f-65c02502d8f9@sandfox.me>
 <c35b9f9b-9896-4b40-82fa-6d69f33b901f@mail.ru>
In-Reply-To: <c35b9f9b-9896-4b40-82fa-6d69f33b901f@mail.ru>
Date: Tue, 23 Dec 2025 13:12:01 +0200
Message-ID: <CAPhkiZy4nRToyDbuY7ZWum176JYp93sVeJS6Azn12up+0RHmzA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC Idea] Short echo tag with automatic HTML escaping
 (<?~ ... ?>)
To: Sergei Issaev <sergei_vi@mail.ru>
Cc: Anton Smirnov <sandfox@sandfox.me>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008c18cb06469c9db3"
From: narf@devilix.net (Andrey Andreev)

--0000000000008c18cb06469c9db3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 23, 2025 at 12:30=E2=80=AFPM Sergei Issaev <sergei_vi@mail.ru> =
wrote:

>
> Yes, h() works =E2=80=94 and many projects already define it. But that=E2=
=80=99s 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 =E2=80=9Cit=E2=80=99s not b=
uilt in=E2=80=9D.
> - 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 =E2=80=94 without requiring them t=
o
> 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=
.

Cheers,
Andrey.

--0000000000008c18cb06469c9db3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Dec 23, 2025 at 12:30=E2=80=AFPM Serg=
ei Issaev &lt;<a href=3D"mailto:sergei_vi@mail.ru">sergei_vi@mail.ru</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Yes, h() works =E2=80=94 and many projects already define it. But that=E2=
=80=99s exactly <br>
the problem: everyone reinvents it, often with slightly different flags, <b=
r>
encoding assumptions, or error handling. This leads to:<br>
- Inconsistent escaping across projects or even within the same codebase.<b=
r>
- Junior developers skipping escaping because =E2=80=9Cit=E2=80=99s not bui=
lt in=E2=80=9D.<br>
- Security relying on project-specific conventions rather than <br>
language-level defaults.<br>
<br>
By providing a standard, secure-by-default output tag in core, PHP would:<b=
r>
- Reduce boilerplate.<br>
- Encourage safer habits out of the box.<br>
- Give small projects (e.g., WordPress plugins, scripts, internal tools) <b=
r>
a zero-dependency way to escape safely =E2=80=94 without requiring them to =
<br>
define or remember h().</blockquote><div><br></div><div>I can relate to the=
se pain points, but I also think your conclusions are a bit of wishful thin=
king.</div><div><br></div><div>Junior developers would still not use it, be=
cause they&#39;d need to know it first - just like h(). Even seasoned devel=
opers 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 protecti=
on, which is more dangerous than you&#39;d think - I&#39;ve seen it time an=
d time again, some feature offers limited security benefits, people only ca=
re to remember that &quot;it&#39;s secure&quot;, use it for everything with=
out critical thought,=C2=A0and you end up with masses of developers believi=
ng that they write secure code when it&#39;s not even close to that. Then P=
HP has to take the blame for providing insecure XSS escaping.</div><div><br=
></div><div>Cheers,</div><div>Andrey.</div></div></div>

--0000000000008c18cb06469c9db3--