Hi Stas, This is not an input filter and PHP already suffers the same outrageous disadvantages by offering htmlspecialchars(), rawurlencode(), etc. The rules for escaping are well established and DO NOT change overnight. Those for Javascript and CSS are in their respective standards. Those for HTML/XML have been known since the 90s and still haven't changed. PHP seems quite happy about offering encoding mechanisms if anything - where did json_encode() spring from?
Browser defects are not PHP's problem. Folk seem to be missing the point that this is output oriented to a well understood set of rules. Paddy On Tue, Sep 18, 2012 at 5:51 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > >> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper. >> The RFC is a proposal to implement a standardised means of escaping >> data which is being output into XML/HTML. > > We already have filter extension. Is it really necessary to invent yet > another way of filtering data? > > Also, a problem with putting code of this complexity in core would be > that if it every had a defect - e.g. we forgot to account for some weird > browser quirk that does not follow RFCs, or some strange encoding > combination, or just a plain bug - it would be very hard for the users > to mitigate without upgrading PHP - which is not always under their > control. When using PHP code, they could just d/l new ZF class, but with > core implementation it'd be much harder. > > So far I am not convinced we should really do it. But if somebody > creates PECL extension and it proves popular, it may be merged into core > once it does. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
