To the Directors of White Space
Dear Sirs,
It has come to my attention that our White Space is running wild. Would it be possible to tame that beast back into submission please.
Seriously, I would like to propose adding another rule to the coding standards: when outputting HTML directly, leave all white space in PHP. Currently we do something like this:
if ( something ) {
?>
<div id=...>some more</div>
<div id=...>even more</div>
<?php
}
That’s all nicely readable on the PHP side but the outputted HTML is surrounded by quite a bit of redundant space. What I’m proposing is to stop/start PHP immediately around the HTML:
if ( something ) {
?><div id=...>some more</div><?php
?><div id=...>even more</div><?php
}
This doesn’t impact the readability on the PHP side and produces “tight” HTML with no white spaces as it should be for production. In fact the HTML source would be “pseudo-minified”.
Of course the readability of the HTML source will be affected but not that much. Currently our HTML output is all over the place which makes it pretty hard to read. Considering that most people never look at the HTML source directly any more thanks to FIrebug and friends and all coding oriented text editors have a function to reformat HTML, I believe outputting “minified” HTML is an advantage. This also reduces the size of our output from 3% to 15% depending on the page.
Of course I’m not proposing for everybody to rush and reformat the whole codebase if this is accepted. But we can apply it to new code and clean up functions that are being patched for other reasons.
Ken 8:20 pm on April 4, 2011 Permalink
This would be fine with me, I also use firebug when examining html.
Joseph Scott 8:25 pm on April 4, 2011 Permalink
Wouldn’t it be better to optimize for the code that is read more often (PHP)? For HTML there are plenty of options to minify automatically if you want to go that route.
Alex M. 8:44 pm on April 4, 2011 Permalink
This is my thoughts as well. While pretty HTML is nice, pretty PHP should be the priority IMO. Stepping into PHP just to step right back out again on the next line seems like a waste and makes it a lot harder to read.
As for size, if that’s a concern then gzip should be used.
Andrew Ozz 8:55 pm on April 4, 2011 Permalink
Yes, we can minify the HTML automatically but that’s just another (although minimal) overhead. IMHO if we leave all white space in PHP we are optimizing both at the same time.
Our code is already pretty much optimized for readability on the PHP side. If we accept this as coding standard, it would enhance the PHP side a bit (as we won’t have to think about HTML output formatting at all and can place it anywhere we need) and also enhance the HTML output a lot.
Andy Skelton 9:07 pm on April 4, 2011 Permalink
I agree with Joseph. I spend so little time looking at the HTML output that I couldn’t care less what whitespace there is. When I’m looking at PHP, I don’t want to have to look at the beginning and end of every line. That’s even worse than reading a long column of echoes.
Andrew Nacin 11:17 pm on April 4, 2011 Permalink
I agree with Joseph and Andy as well.
Brian Layman 2:28 pm on April 6, 2011 Permalink
I’m in this camp too.
Plus this may appear moderately readable with two lines but once you get into more it doesn’t hold up nearly as well. I’d rather be consistent in our handling and also save 7 bytes per line of code.
Jon Brown 8:36 pm on April 4, 2011 Permalink
Isn’t what you’re proposing the opposite of the existing coding standards which are to open/close php around the actual PHP? More like:
if ( something ) { ?> <div id=...>some more</div> <div id=...>even more</div> <?php }Which is compact and doesn’t needlessly open and close php (although I’m pretty sure that’s been shown not to be a performance issue, right?)
Ramoonus 12:33 pm on April 5, 2011 Permalink
this is what I prefer, much easier to read
and most programs can do color coding with this format
Mike Schinkel 8:50 pm on April 4, 2011 Permalink
Here’s a question I don’t know the answer to: Is there any performance penalty for excessive context switches between PHP and HTML? Also, rather than context switching, why not use HEREDOCs instead?
Andrew Ozz 8:59 pm on April 4, 2011 Permalink
As far as I can tell, no. No performance penalty for switching in and out of PHP at all. IMHO HEREDOC is quite hard to read and is inflexible in many cases.
Mike Schinkel 10:09 pm on April 4, 2011 Permalink
Regarding HEREDOC, to each his own.
I find them great to work with.
scribu 9:06 pm on April 4, 2011 Permalink
We should avoid context switches, not for site performance, but for developer performance, as Joseph Scott already mentioned.
Adding more characters to reduce whitespace doesn’t seem like a sweet deal to me. A standard in this area would be good, but not that one.
How about:
if ( something ) { ?> <div id=...> <p>lines</p> </div> <div id=...><?php inline_call(); ?></div> <?php }Multi-line blocks should never be indented.
Alex M. 9:09 pm on April 4, 2011 Permalink
This is how I write and prefer code.
Andy Skelton 9:12 pm on April 4, 2011 Permalink
I recently banished all thoughts of pretty HTML and decided to focus on PHP indentation. So I indent the PHP tags. Here’s my example:
if ( $lines ) { ?> <div id="lines"> <?php foreach ( $lines as $line ) { ?> <p class="line"></p> <?php } ?> </div> <?php }Peter Westwood 9:17 pm on April 4, 2011 Permalink
This is what I do too.
PHP readability is much more important that the HTML.
Ken 9:09 pm on April 4, 2011 Permalink
Alternatively, we can recommend NOT using indents for html blocks, but rather line-breaks and comments:
if ( something ) { ?> <!-- #someid --> <div id="someid">some more</div> <div id=...>even more</div> <!-- /#someid --> php }I’d just be happy with any standard.
Brian Layman 2:30 pm on April 6, 2011 Permalink
I imagine my preferred standard of making the HTML indented to the correct level when the HTML source is viewed would be generally hated by all
miqrogroove 9:24 pm on April 4, 2011 Permalink
The only time this white space has ever mattered to me is when dealing with textarea elements, which have a required trailing linefeed. At any other time, I would prefer the former syntax for simplicity and let the HTML look slightly out of alignment. I would never try to minify my HTML.
Ken 9:30 pm on April 4, 2011 Permalink
There was a trac ticket a while back about white space between Nav LIs that caused styling issues… He was setting the menu items to display: inline. That and your textareas are the only things I can think of.
demetris 10:12 pm on April 4, 2011 Permalink
I think the gain in size is not worth it because, when the document is gzipped, the reduction in percentage is much smaller: 2 or 3 percent at most. (Which, in absolute numbers, is an even smaller gain.)
My personal preference at present is to always stay in PHP mode. I use echoes with a line feed at the end of the string. So, the only white space in the generated HTML is line feeds. (One reason I started using this style is that HTML highlighting with a PHP document distracts me.)
Andrew Ozz 10:33 pm on April 4, 2011 Permalink
Agreed. Assuming that most hosting companies gzip HTML by default the gain will be even smaller: about 0.1% and under as white space compresses extremely well.
Jan Fabry 6:47 am on April 5, 2011 Permalink
Indeed, I also prefer to stay in PHP mode. With this proposal the difference will be even smaller, so if there would be a change, I propose it is to PHP-with-echo everywhere.
arena 10:59 pm on April 4, 2011 Permalink
ok for me and please please remove the trailing and useless ?> in most wordpress php files
Peter Westwood 7:15 am on April 5, 2011 Permalink
It’s not useless – it is good practice in my opinion and makes it easier to identify when people have uploaded part of a file by FTP
Mike Schinkel 7:21 am on April 5, 2011 Permalink
I’ve seen whitespace after a trailing ?> cause syntax errors. I’ve never seen those same syntax errors occur when there is not a trailing ?>. FWIW.
Peter Westwood 7:24 am on April 5, 2011 Permalink
Syntax errors seems unlikely, Headers already sent is probably what you saw.
Mike Schinkel 7:28 am on April 5, 2011 Permalink
Possibly. Either way it was a fiddly error that can take a while for many people to track down. Again, FWIW.
Dion Hulse (dd32) 8:50 am on April 5, 2011 Permalink
Mike: Thats the exact reason why user editable files in WordPress don’t have the closing php marker (wp-config-sample.php and themes functions.php)
But for all other files, no user should edit them, so its a useless argument there
Mike Schinkel 8:57 am on April 5, 2011 Permalink
@dd32 – Although it’s not worth debating as an attempt to change the opinions of the core team related to the source files in WordPress, as a point of note it is not completely useless.
People accidentally modify files all the time. If they open a core file to learn what it does but accidentally add white space to the end they can spend quite a bit of time trying to figure out why their site code now fails although they can’t “see” any difference.
Again, FWIW.
arena 11:28 am on April 5, 2011 Permalink
@peter
having or not having a ?> at the end of a file do not mean you have reached the end of the file ….
then change the
trailing ?>
by
/* end of file */
Ramoonus 12:34 pm on April 5, 2011 Permalink
which is much more work to type
therefore -1
hakre 9:30 pm on April 5, 2011 Permalink
#EOF
miqrogroove 6:05 pm on April 8, 2011 Permalink
return; ?>
Ramoonus 8:51 am on April 10, 2011 Permalink
your still closing things
John James Jacoby 1:22 am on April 12, 2011 Permalink
I’m against the grain with everyone here. Go figure.
I think having pretty HTML output is important, because scanning through randomly indented HTML output is as irritating as scanning through randomly indented PHP. Call me old school, but I miss the days of having poetically formatted HTML when viewing HTML source on a site.
I also prefer not to echo out HTML from inside PHP, and rather close out of PHP and output raw HTML. PHP is a scripting language that essentially provides logic to HTML. Using it to output complete lines or blocks of HTML seems counter-intuitive to me, so it’s reserved in my toolbox for special cases where I may want to filter that chunk of HTML through a WordPress filter.
This was one of my original kvetches about WordPress when I stopped lurking and started posting in the support forums. (Embarrassing reading my tone back then as an outsider to the community.)
The problem arrises from having tabs in front of the PHP open brace. It’s good for PHP code readability, but bad for HTML output readability.
This example taken from index.php of twentyten:
…should really be…
The differences being the whitespace before the opening and closing PHP braces is gone, and there is an additional empty line before and after the context switch to ensure the output of get_template_part() has breathing room. In the above example, the next problem is that loop.php starts out only indented 1 tab in, rather than 4, which starts the cycle of messy HTML whitespace over again.
Alex M. 1:28 am on April 12, 2011 Permalink
I agree 100% with the leading tabs. Adding a space after the closing PHP tag can also make PHP add the line break (a line break immediately following a closing PHP tag is ignored).
scribu 1:28 am on April 12, 2011 Permalink
Actually, that’s what I suggested: http://wpdevel.wordpress.com/2011/04/04/to-the-directors-of-white-space/#comment-17986
John James Jacoby 1:35 am on April 12, 2011 Permalink
Minus the empty lines before and after the PHP block.
scribu 1:12 pm on April 18, 2011 Permalink
After actually running into a ticket that has to deal with this problem, I say we integrate the style described by JJJ above into the current coding standards.
Peter Westwood 1:17 pm on April 18, 2011 Permalink
I disagree – opening PHP tags should be intended to match the level of HTML they are within.
scribu 1:25 pm on April 18, 2011 Permalink
Why should they be indented? As noted above, they make the HTML output less readable.
NB: I sense a storm brewing behind the bike shed
Peter Westwood 1:27 pm on April 18, 2011 Permalink
They should be indented because they make the code easier to read.
The code is for me the programmer to read and I care about whitespace.
The html is for the browser to read and it doesn’t care about whitespace one bit.
John James Jacoby 1:35 am on April 12, 2011 Permalink
Maybe we should write a plugin to format the HTML output for us?
http://gdatatips.blogspot.com/2008/11/xml-php-pretty-printer.html
Mike Schinkel 1:41 am on April 12, 2011 Permalink
Yep, sounds like plugin-territory to me!