There's a convention to end files with a blank line:
http://stackoverflow.com/questions/2287967/why-is-it-recommended-to-have-empty-line-in-the-end-of-file
Many text editors follow it. Or at the least, we're not likely to think for each template file whether to put a blank line on the end of not. These blank lines can build up in the output.
Additionally what happens is that Tempcode will be written in these templates, neatly written if viewing the templates, but if IF directives don't pass, often the spacings used to make the template look nice then make the output XHTML look like it has alien space in it.
If the concern is for tidiness, best just to look at the DOM tree using the browser tools, or pass it through Tidy (e.g. http://infohound.net/tidy/).
If it's about performance, then actually the white-space is almost inconsequential because gzip encoding is very good at making any bytes used by white-space nominal.
We do recommend the mod_pagespeed extension though, if you have server access to install it (CloudFlare's optimisation options are similar, but have some other costs to them, e.g. latency), which can minify HTML output. That's written in C code so is nice and efficient, and will do more to save bytes than just stripping white-space.
We've considered the idea of Composr trying to minify it's own HTML output, but the performance lost in the PHP processing would be too high for it to make sense.
There's a convention to end files with a blank line:
http://stackoverflow.com/questions/2287967/why-is-it-recommended-to-have-empty-line-in-the-end-of-file
Many text editors follow it. Or at the least, we're not likely to think for each template file whether to put a blank line on the end of not. These blank lines can build up in the output.
Additionally what happens is that Tempcode will be written in these templates, neatly written if viewing the templates, but if IF directives don't pass, often the spacings used to make the template look nice then make the output XHTML look like it has alien space in it.
If the concern is for tidiness, best just to look at the DOM tree using the browser tools, or pass it through Tidy (e.g. http://infohound.net/tidy/).
If it's about performance, then actually the white-space is almost inconsequential because gzip encoding is very good at making any bytes used by white-space nominal.
We do recommend the mod_pagespeed extension though, if you have server access to install it (CloudFlare's optimisation options are similar, but have some other costs to them, e.g. latency), which can minify HTML output. That's written in C code so is nice and efficient, and will do more to save bytes than just stripping white-space.
We've considered the idea of Composr trying to minify it's own HTML output, but the performance lost in the PHP processing would be too high for it to make sense.