#47707 [Bgs]: Swallowing a newline immediately following a closing tag is a poor idea
ID: 47707 User updated by: diepiapaopolopo at hotmail dot com Reported By: diepiapaopolopo at hotmail dot com Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: 5.2.9 New Comment: Please consider the option of an ini setting (collapse_tag_whitespace=yes|no|longtag) to enable the current behavior. While the example you give is obviously going to happen occasionally, it is certainly less likely than a user intending for everything outside the PHP tags to remain intact. Even if the default behavior is still to collapse the newline after the tag, having an ini option to not collapse would be much better than the current work around (putting a space or an additional newline after the closing tag). Previous Comments: [2009-03-22 16:40:23] johan...@php.net Not doing this might have unwanted effects in other cases - consider a file starting with a PHP block and then some raw output. We won't change this. [2009-03-18 18:12:50] diepiapaopolopo at hotmail dot com Description: Can the decision to call bugs #13954 and #21891 bogus be revisited, please? Reproduce code: --- Your apple is more than mine. Expected result: Your apple is more red than mine. Actual result: -- Your apple is more redthan mine. Even though the behavior is documented (http://www.php.net/manual/en/language.basic-syntax.instruction-separation.php), swallowing a newline that immediately follows a closing tag seems to be a pretty poor idea, especially if the rationale is to pretty up formatting as is alluded to (http://bugs.php.net/bug.php?id=13954) by jeroen. Swallowing the newline is a surprise to anyone who encounters this bug (yes, bug). Additionally, it can easily lead to malformatted output (see sample included in this report). This malformatting can be difficult to detect and the solution--adding a trailing space after every closing tag (seriously???)--is a kludge through and through. This malformatting becomes catastrophic if you're using PHP to generate input to another program, as is the case for many of the people that have discussed the issue over the years. I realize this discussion has been going on for nearly a decade. I have to assume this topic has become largely a political discussion, rather than a problem solving one, because the problem hasn't been solved yet. In the spirit of problem solving, several people have suggested adding a setting to php.ini to re-enable the current behavior, which should eliminate the need to refactor any scripts affected by the correction. In any case, the current behavior should not be the default behavior. -- Edit this bug report at http://bugs.php.net/?id=47707&edit=1
#47707 [NEW]: Swallowing a newline immediately following a closing tag is a poor idea
From: diepiapaopolopo at hotmail dot com Operating system: All PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: Swallowing a newline immediately following a closing tag is a poor idea Description: Can the decision to call bugs #13954 and #21891 bogus be revisited, please? Reproduce code: --- Your apple is more than mine. Expected result: Your apple is more red than mine. Actual result: -- Your apple is more redthan mine. Even though the behavior is documented (http://www.php.net/manual/en/language.basic-syntax.instruction-separation.php), swallowing a newline that immediately follows a closing tag seems to be a pretty poor idea, especially if the rationale is to pretty up formatting as is alluded to (http://bugs.php.net/bug.php?id=13954) by jeroen. Swallowing the newline is a surprise to anyone who encounters this bug (yes, bug). Additionally, it can easily lead to malformatted output (see sample included in this report). This malformatting can be difficult to detect and the solution--adding a trailing space after every closing tag (seriously???)--is a kludge through and through. This malformatting becomes catastrophic if you're using PHP to generate input to another program, as is the case for many of the people that have discussed the issue over the years. I realize this discussion has been going on for nearly a decade. I have to assume this topic has become largely a political discussion, rather than a problem solving one, because the problem hasn't been solved yet. In the spirit of problem solving, several people have suggested adding a setting to php.ini to re-enable the current behavior, which should eliminate the need to refactor any scripts affected by the correction. In any case, the current behavior should not be the default behavior. -- Edit bug report at http://bugs.php.net/?id=47707&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47707&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47707&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47707&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47707&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47707&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47707&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47707&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47707&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47707&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47707&r=support Expected behavior: http://bugs.php.net/fix.php?id=47707&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47707&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47707&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47707&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47707&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47707&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47707&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47707&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47707&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47707&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47707&r=mysqlcfg
