On Wed, Dec 24, 2025, at 05:28, Sergei Issaev wrote:
> Hi Anton,
>
> > 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.
>
> The semantics of `<?: $expr ?>` would be equivalent to: `<?php echo
> htmlspecialchars($expr, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5); ?>` --
> that is, the encoding will be determined automatically via the current
> default_charset setting, as htmlspecialchars() does by default.
>
> Best regards,
> Sergei Issaev
>
I know this is not your intent, but this will give people a false sense of
security. Much like Twig and Blade do today.
Here's some examples where this breaks, written in the context of an html doc:
<script>
const name = "<?: $name ?>";
</script>
breaks with ";alert(1); //
<a href="/search?q=<?: $query ?>"...
double encodes
window.config = <?: json_encode($config ?>
doesn't technically break ... but that would be a fun bug which would encourage
devs to just turn off escaping, which defeats the purpose.
....
Maybe, you should consider something like this:
<?:html: or <?:h:
<?:attr:
<?:url:
<?:js:
<?:css:
Then you only choose the one for your context:
const name = <?:js: $name ?>
<a href="/search?q=<?:attr: $query ?>"...
window.config=<?:js: $config ?>
.size { width=<?:css: $width ?>; } //prevents ;}.size:after { content="<a..."
Its a bit more to type, but compared to googling the right way to do these in
all the right places and vetting/hoping that it is right... it seems worth it.
— Rob
