Why Would One Omit the Close Tag

Why would one omit the close tag?

Sending headers earlier than the normal course may have far reaching consequences. Below are just a few of them that happened to come to my mind at the moment:

1. While current PHP releases may have output buffering on, the actual production servers you will be deploying your code on are far more important than any development or testing machines. And they do not always tend to follow latest PHP trends immediately.

2. You may have headaches over inexplicable functionality loss. Say, you are implementing some kind payment gateway, and redirect user to a specific URL after successful confirmation by the payment processor. If some kind of PHP error, even a warning, or an excess line ending happens, the payment may remain unprocessed and the user may still seem unbilled. This is also one of the reasons why needless redirection is evil and if redirection is to be used, it must be used with caution.

3. You may get "Page loading canceled" type of errors in Internet Explorer, even in the most recent versions. This is because an AJAX response/json include contains something that it shouldn't contain, because of the excess line endings in some PHP files, just as I've encountered a few days ago.

4. If you have some file downloads in your app, they can break too, because of this. And you may not notice it, even after years, since the specific breaking habit of a download depends on the server, the browser, the type and content of the file (and possibly some other factors I don't want to bore you with).

5. Finally, many PHP frameworks including Symfony, Zend and Laravel (there is no mention of this in the coding guidelines but it follows the suit) and the PSR-2 standard (item 2.2) require omission of the closing tag. PHP manual itself (1,2), Wordpress, Drupal and many other PHP software I guess, advise to do so. If you simply make a habit of following the standard (and setup PHP-CS-Fixer for your code) you can forget the issue. Otherwise you will always need to keep the issue in your mind.

Bonus: a few gotchas (actually currently one) related to these 2 characters:

1. Even some well-known libraries may contain excess line endings after ?>. An example is Smarty, even the most recent versions of both 2.* and 3.* branch have this. So, as always, watch for third party code. Bonus in bonus: A regex for deleting needless PHP endings: replace (\s*\?>\s*)$ with empty text in all files that contain PHP code.

Why do some scripts omit the closing PHP tag, '?'?

Well, omitting the closing tag is just one solution for avoiding blanks and other characters at the end of file. For example any char which is accidentally added behind the closing tag would trigger an error when trying to modify header info later.

Removing the closing tag is kind of "good practice" referring to many coding guidelines.

Does omitting the closing tag of a PHP block at the end of a file remove any line feeds or whitespace,if present in a respective file?

I know that the closing tag of a block of PHP code automatically
implies a semicolon so we do not need to have a semicolon terminating
the last line of a PHP block.

Means <?php echo '' ?> is fine.

The closing tag for the block will include the immediately trailing
newline if one is present.

Means

<?php echo '' ?>
\n
\n
\n

Will output 3 line breaks.

But I think your asking, whether the following will output line breaks.

<?php echo '';
\n
\n
\n

Which it wont, for the same reason PHP comments don't get outputted.

PSR-2 guidelines 2.2. Files.

• All PHP files MUST use the Unix LF (linefeed) line ending.

• All PHP files MUST end with a single blank line. (not 10 ;p)

• The closing ?> tag MUST be omitted from files containing only PHP.

Is it safe to omit /TD and /TR tags?

It is safe, since optionality in the standard means that all the browsers (at least the ones which even remotely matter) would have implemented this - and the browser standards compliance usually runs to the opposite side, into trying to work correctly with even invalid HTML as opposed to failing on missing optional tags.

Having said that, I find that omitting such tags makes things harder to read, which may or may not matter to you if the goal is size optimization.

P.S. Also, if you have very large tables, I wonder whether there's any overhead incurred by the browser's HTML parser when dealing with such constructs? I am not sure without benchmarking or really deep thinking about how HTML parser works in detail, but it is something that could possibly be a factor if it happens.

Why does HTMLAgilityPack remove my closing tag?

As others said in the comments, it's an invalid HTML so that might be the reason why the HtmlDocument class itself is removing </p> in the end when you store it into a file using the Save method, but as a workaround, you can store it using System.IO.File class and store the document.Text at the output location.

var html = "<p><ol><li>A bunch of text</li></ol><em>some em text</em> more text here.</p>";
var document = new HtmlDocument();
document.LoadHtml(html);
File.WriteAllText("insert_your_path_here", document.Text);

PHP end tag ?

This is well documented. From the PHP Manual:

The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include() or require(), so unwanted whitespace will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted whitespace at the end of the parts generated by the included files.

Omitting the closing tag helps you prevent accidental whitespace or newlines from being added to the end of the file.

Closing HTML input tag issue

These are void elements. This means they aren't designed to contain text or other elements, and as such do not need — and in fact, cannot have — a closing tag in HTML.¹

However, they should have a <label> associated with them:

<input id="my_id" type="radio" name="radio_name">
<label for="my_id">Radio Label</label>

Radio buttons by nature can't contain text anyway, so it wouldn't make sense for them to accept text or other elements as content. Another issue with a control that does accept text as input: should its textual content then be its value, or its label? To avoid ambiguity we have a <label> element that does exactly what it says on the tin, and we have a value attribute for denoting an input control's value.

---

¹ _{XHTML is different; by XML rules, every tag must be opened and closed; this is done with the shortcut syntax instead of a </input> tag, although the latter is equally acceptable:}

<input id="my_id" type="radio" name="radio_name" />
<label for="my_id">Radio Label</label>

HTML Style Guide Google vs W3Schools (Omit Optional Tag)

Many times we use the optional closing tags because it makes the document more readable. As Google says, removing them reduces file size but, then, most of us don't have the traffic Google does. That suggestion is for those who do. Then, again, reducing download size is always a good thing.

I often leave out the body tag altogether because even the opening tag is optional in most cases. However, there is a danger that leaving that out, and leaving out closing tags, may cause issues later on. I would say putting body tags in and closing all elements removes the possibility of causing those issues. For example, you can only leave the html and body tags out under certain situations.

Reading the spec:

An html element's start tag can be omitted if the first thing inside
the html element is not a comment. An html element's end tag can be
omitted if the html element is not immediately followed by a comment.

For some, this is very important. To others it's not.

It can be more of an issue for dynamically generated sites where the content is created on the fly and the surrounding elements may not be known. Does one really know that the following element will cause a div element to be closed?

HTML 5: Is it br, br/, or br /?

Simply <br> is sufficient.

The other forms are there for compatibility with XHTML; to make it possible to write the same code as XHTML, and have it also work as HTML. Some systems that generate HTML may be based on XML generators, and thus do not have the ability to output just a bare <br> tag; if you're using such a system, it's fine to use <br/>, it's just not necessary if you don't need to do it.

Very few people actually use XHTML, however. You need to serve your content as application/xhtml+xml for it to be interpreted as XHTML, and that will not work in old versions of IE - it will also mean that any small error you make will prevent your page from being displayed in browsers that do support XHTML. So, most of what looks like XHTML on the web is actually being served, and interpreted, as HTML. See Serving XHTML as text/html Considered Harmful for some more information.

---

Related Topics