However, in this last example, the logic gets totally scrambled! The elseif will now belong to the sub-if instead of the first if, and the rest of the logic will all behave as a "one single statement" in response to the first if only. Very confusing and error prone (be careful).

The differences are very subtle and can deceive the eyes (especially while debugging). For this reason, I strongly suggest the first example from this answer: when using IF-ELSEIF blocks (AKA "Alternative Syntax"), if another IF is required inside it, enclose it in between {} and don't forget to add a semicolon after the last }. Example:

After a long and useless discussion at https://bugs.php.net/bug.php?id=75138, while trying to place a bug report for this problem, I came to a sad conclusion that PHP developers nowadays rather live with the code syntax problem instead of fixing it, then blame issues to the developers' code style.

Well... I can accept it as not being a "BUG", as far as a "NEW SYNTAX requirement" is explicitly defined for it (rules are rules).

I'd suggest a modification in the language manual in regards to semicolon usage definition:

====================When using "alternative syntax for control structures" observe the fact that when an "IF" statement is required to be nested into another IF-ELSEIF-ELSE block and it casually ends up being the last statement of the nested block, it is a LANGUAGE REQUIREMENT to terminate it with double semicolon (;;) to prevent the "dangling else" effect.====================

Or, better, we can add it to the same (miss)interpretation concept that aread exist in this very same page, keeping documentation standards intact:

====================Note:Mixing syntaxes in the same control block is not supported.

Note:A nested "if" statement immediately before an "else:" or "elseif: " statement in control block is not supported.====================

Oh, that solves all problems, sure!!!!

Or, even better! Let's simply ignore it all and leave it as it is. What harm can an extra ";" after another ";" do anyway, right?

It is always developers' fault anyway... Poor bastards that don't know how to code! I can't believe anyone will have an IF statement as the last nested statement inside another IF... Can you imagine it? :P

The reason for the "workaround" jeremiah mentioned, in the case of the switch statement, can be understood as follows; in any place where you can have an echo statement (an if block, a switch's case, whatever), that's where you can have the raw HTML. In PHP this basically gets handled just like that -- like an echo statement.

In between a switch and a case, though, you can't echo anything. By placing the switch and the case in two separate blocks of PHP, with a raw HTML newline echo'ed in between them, PHP basically had to try to find where that statement would be. And it can't be there, hence the difficulty.

If it needs saying, this alternative syntax is excellent for improving legibility (for both PHP and HTML!) in situations where you have a mix of them.

Interface templates are very often in need of this, especially since the PHP code in them is usually written by one person (who is more of a programmer) and the HTML gets modified by another person (who is more of a web designer). Clear separation in such cases is extremely useful.

See the default templates that come with WordPress 1.5+ (www.wordpress.org) for practical and smart examples of this alternative syntax.

The reason temec987's approach of using boolean operators as an alternative to control structures won't work for an 'echo' is because the result of evaluating the expression will always be a boolean.

Other languages (e.g. ruby) are much better suited to this approach, as the expression evaluated will be the resultant value, e.g.:5 && 4

In ruby, this would be 4, but in PHP, this would be true (type-juggled equivalent is 1), which isn't useful for anything but further binary logic.

You can still use logical operators as conditionals, but only for executing logic, not for getting a value back, e.g.:<?phpdefined('USER_CAN_EXECUTE') or die('Access denied.');?>

is a nice one to use for access control, or say you want to put in a quick check that your object has all the data loaded it needs to call a webservice (functions are just examples):<?php$this->readyForService() and $this->postData('http://endpoint.com');?>

What you can't use them for is something like this:<?phpecho (strlen($mystring) > 5) and $mystring;?>