>> if ($context == 'html') {
> this is bad coding style since $context = 0 gives unexpected html
escaping.I know, it was just an example) > The RFC speaks of *operator*, where actually start-tags[1] are meant, to start with. > Using the word operator is rather confusing in this context. Technically yes, but there are echo operator, so it can be considered as special construction for using echo operator. I don't think that exact work is very important here. > But what happens to additional code, e.g. > <?* $str, 'html', 42 ?> > <?* $str, 'html'; echo 42 ?> This is new operator with new syntax. It will give parsing error. > Contrast that to the language specification which explains: > | If <?= is used as the start-tag, the Engine proceeds as if the > | statement-list started with echo statement. > Simple, yet precise. <?= '1'; echo '2' ?> which output '12' is simple? It does not seem clear for me. > I still don't see the benefit of being able to write > <?* $str ?> > instead of > <?=h($str)?> With new operator you cannot output unsafe value. It wiil be escaped or will not be output. > a few minutes ago, security updates for CVE-2016-2040 were published: > https://github.com/phpmyadmin/phpmyadmin/commit/edffb52884b09562490081c3b8666ef46c296418 > https://github.com/phpmyadmin/phpmyadmin/commit/75a55824012406a08c4debf5ddb7ae41c32a7dbc > https://github.com/phpmyadmin/phpmyadmin/commit/aca42efa01917cc0fe8cfdb2927a6399ca1742f2 Good examples, thanks. This is what I'm trying to explain. > It's not possible for multiple frameworks or libraries to declare different escape handlers in your proposal, either. It works similer to set_error_handler(). Is it poossible to declare different error handlers? I think, yes. > with <?=e()?> you have to define an e() function Or just write without e(). I.e. you have not to. > which is why I think it's bizarre that the current version doesn't even have a built-in HTML escaper at all. > This argument is only valid if the RFC includes an implementation, not just a syntax. Ok, if it will contain a default escape handler with a possibility to fully unregister it and set custom one, will it be better variant? I will add an additional voting about this option. But: > In my opinion, they are central to the feature, not an optional extra. If user will want to use different flags for htmlspecialchars(), it will anyway must unregister built-in handler. > OK, so I can dynamically redefine the same syntax to mean different things at different times, within the same application. I'm not entirely sure that's a particularly good thing. As I understand, you can do the same in Twig, setEscaper() function does not perform any checks. https://github.com/twigphp/Twig/blob/f0a4fa678465491947554f6687c5fca5e482f8ec/lib/Twig/Extension/Core.php#L29 > Then why is absolutely everything in the current RFC optional and configurable to the Nth degree? All that this RFC contains is just an escape handler. As we agreed, customization is required. > Frameworks are free to write all sorts of weird shit: And? You can do the same in Twig. Is it a bad template engine? Ok. Just ask you, why people ask the same question again since the time PHP was created? Why almost all feature requests mentioned in RFC are about an easy way to call htmlspecialchars()? You can vote up or down, I just want to get an official result about this feature. I think, it can be considered as official answer to community, to those people from community who would like to use default escaping mechanism in PHP.
