I've tried to gather all arguments for and against. To be clear. I suggest new operator like '<?~ $value ?>' which is equivalent of <?= htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE) ?>. It is only for HTML context. Flag combination is taken from most popular frameworks - Symfony, Zend, Yii, and Twig. Of course, exact form of operator and default flags are the details of implementation.
- You can write short function in userland. The problem is not that we have no function. The problem is that the same action is always repeated, and if we don't repeat it then it leads to security problems. More than 90% of output data - is data from DB and must be HTML-encoded. There is no such problem with other contexts. If we don't call json_encode when passing an array or object into javascript, this only breaks the script, and it will be noticeable, there won't be security problems. With new operator we can write or <?~ ?>, or <?= ?>, they are mutually exclusive, and we need specially write one or another, but with helper function we have the same beginning <?= and then can write helper function or not. Also there is a problem with function autoloading. - It is no place for such operators in the language. It is no place for a such operators in C++, or C#, or Java. But in the most popular language for web-programming it is very place for such operator. - There are many other contexts HTML is external context, but others are internal task-dependent contexts. HTML can be used together with other contexts. HTML context is the main context in every PHP file, and we write <?php at the beginning to switch it. Actually, on web page we have 3 external contexts - HTML, <script> tag, <style> tag. PHP+CSS usually is not used. PHP+JS is not just escaping. It is encoding in special notation. Escaping can be applied only to strings, but encoding can be applied to any type of variables. Only urlencode is really escaping (and it also can be used together with other contexts). But urlencode is an internal context. If we construct an URL, e.g. for filters, we should encode every part. $filterUrl = '/my_route/?state=active'; if ($postData['contains_text']) $filterUrl .= '&contains_text='.urlencode($postData['contains_text']); When we write data-attirbute, additional context is task-dependent, but HTML context is always present. <div class="some-class" data-url="<?= htmlspecialchars('/my_route/?state=active&category_id=123') ?>" data-settings="<?= htmlspecialchars(json_encode($settings) ?>" ></div> - Other people will ask about operator for another context And you can say: We already added an operator for the main web context, because it is the most frequently used context. If you have a lot of work with other contexts, please use template engine. - You want to add new operator just for your needs It's not only my needs for one project. I meet this problem in many projects without template engine. The results of the poll, which I wrote about in my previous message, show that it has a place not only for me. Some feature requests on http://bugs.php.net with the same question were created in 2002. - Some people can use various flags, or use third and fourth parameters of htmlspecialchars(). How many such projects of total number of projects? Default flags can be set to be enough safe. Third parameter can be chaged via ini_set. Fourth parameter is not required for many cases. Except maybe when some people encode the data before saving it into database. Also, new operator is not a replacement for htmlspecialchars, so it could still be used. It just is looked not very good - we use special set of parameters, so you cannot add operator which we could not use. This problem with flags can be solved by adding default value for them with PHP_INI_USER mode, and getter and setter for it. But I'm not sure you think this is a good idea. - Exact flags / Default flags In popular frameworks there are the following flags: Symfony — ENT_QUOTES | ENT_SUBSTITUTE Yii — ENT_QUOTES | ENT_SUBSTITUTE Zend — ENT_QUOTES | ENT_SUBSTITUTE Twig — ENT_QUOTES | ENT_SUBSTITUTE https://github.com/symfony/symfony/blob/f29d46f29b91ea5c30699cf6bdb8e65545d1dd26/src/Symfony/Component/Templating/PhpEngine.php#L421 https://github.com/yiisoft/yii2/blob/c370c17e93f364a843ed7c31e1e1f7fc8caef0a3/framework/helpers/BaseHtml.php#L104 https://github.com/zendframework/zend-escaper/blob/1a855b5f7074607b1260d85c5526a59b1ab36593/src/Escaper.php#L117 https://github.com/twigphp/Twig/blob/f0a4fa678465491947554f6687c5fca5e482f8ec/lib/Twig/Extension/Core.php#L1039 - Tilde sign There is a good argument about tilde sign. It is absent in keyboard layouts for some european languages. But it is the details of implementation. I think it should be special sign which is typed with Shift and is located rather far from "=" sign. Possible variants are "<?! ?>", "<?@ ?>", "<?^ ?>". First variant looks more suitable. I don't see any arguments, why other operators can be implemented but this operator cannot. So, please tell me, what do you think about RFC? 2016-06-29 21:39 GMT+05:00 Михаил Востриков <michael.vostri...@gmail.com>: > Hello. I've created an article on russian technical site habrahabr.ru. > https://habrahabr.ru/post/304162/ > > There is a poll about introducing of such operator. About 60% from those > people who have projects without template engine are "for" this operator. > And even a half of those who don't also think that such operator can be > useful. > > I think you can use Google Translate to read it, common sense and code > examples should be understandable. > > https://translate.google.com/translate?sl=en&tl=ru&js=y&prev=_t&hl=ru&ie=UTF-8&u=https%3A%2F%2Fhabrahabr.ru%2Fpost%2F304162%2F&edit-text=&act=url > > Current results: > > > How often do you work with the projects with template rendering on PHP > where template engines are not used? > 35% (163) Always > 22% (104) Quite often > 18% (86) Quite rare > 25% (117) Almost never > > Voted 470 people. Abstained 116 people. > > > How do you think, such an operator would be useful? > 56% (264) Yes > 44% (207) No > > Voted 471 people. Abstained 121 people. > > > I don't use PHP teplate rendering ... > 51% (147) and I think that such an operator is not needed > 49% (139) but I think that such an operator will come in handy > > Voted 286 people. Abstained 247 people. > > > Screenshot in Russian: > > https://habrastorage.org/files/675/9ac/883/6759ac8834044ef0b5a09163c791f376.png > > > 60% are "for" this operator, projects of others 40% will not be affected. > I think this is a good reason to create an RFC and discuss it on more > global level. > >