Asked  7 Months ago    Answers:  5   Viewed   35 times

What are all the valid self-closing elements (e.g. <br/>) in XHTML (as implemented by the major browsers)?

I know that XHTML technically allows any element to be self-closed, but I'm looking for a list of those elements supported by all major browsers. See for examples of some problems caused by self-closing elements such as <div />.



Every browser that supports XHTML (Firefox, Opera, Safari, IE9) supports self-closing syntax on every element.

<div/>, <script/>, <br></br> all should work just fine. If they don't, then you have HTML with inappropriately added XHTML DOCTYPE.

DOCTYPE does not change how document is interpreted. Only MIME type does.

W3C decision about ignoring DOCTYPE:

The HTML WG has discussed this issue: the intention was to allow old (HTML-only) browsers to accept XHTML 1.0 documents by following the guidelines, and serving them as text/html. Therefore, documents served as text/html should be treated as HTML and not as XHTML.

It's a very common pitfall, because W3C Validator largely ignores that rule, but browsers follow it religiously. Read Understanding HTML, XML and XHTML from WebKit blog:

In fact, the vast majority of supposedly XHTML documents on the internet are served as text/html. Which means they are not XHTML at all, but actually invalid HTML that’s getting by on the error handling of HTML parsers. All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”.

To test whether you have real XHTML or invalid HTML with XHTML's DOCTYPE, put this in your document:

<span style="color:green"><span style="color:red"/> 
 If it's red, it's HTML. Green is XHTML.

It validates, and in real XHTML it works perfectly (see: 1 vs 2). If you can't believe your eyes (or don't know how to set MIME types), open your page via XHTML proxy.

Another way to check is view source in Firefox. It will highlight slashes in red when they're invalid.

In HTML5/XHTML5 this hasn't changed, and the distinction is even clearer, because you don't even have additional DOCTYPE. Content-Type is the king.

For the record, the XHTML spec allows any element to be self-closing by making XHTML an XML application: [emphasis mine]

Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY.

It's also explicitly shown in the XHTML spec:

Empty elements must either have an end tag or the start tag must end with />. For instance, <br/> or <hr></hr>

Tuesday, June 1, 2021
answered 7 Months ago

This is a very good question and sadly many developers don't ask enough questions about IIS/ASP.NET security in the context of being a web developer and setting up IIS. So here goes....

To cover the identities listed:


This is analogous to the old IIS6 IIS_WPG group. It's a built-in group with it's security configured such that any member of this group can act as an application pool identity.


This account is analogous to the old IUSR_<MACHINE_NAME> local account that was the default anonymous user for IIS5 and IIS6 websites (i.e. the one configured via the Directory Security tab of a site's properties).

For more information about IIS_IUSRS and IUSR see:

Understanding Built-In User and Group Accounts in IIS 7


If an application pool is configured to run using the Application Pool Identity feature then a "synthesised" account called IIS AppPool<pool name> will be created on the fly to used as the pool identity. In this case there will be a synthesised account called IIS AppPoolDefaultAppPool created for the life time of the pool. If you delete the pool then this account will no longer exist. When applying permissions to files and folders these must be added using IIS AppPool<pool name>. You also won't see these pool accounts in your computers User Manager. See the following for more information:

Application Pool Identities

ASP.NET v4.0: -

This will be the Application Pool Identity for the ASP.NET v4.0 Application Pool. See DefaultAppPool above.


The NETWORK SERVICE account is a built-in identity introduced on Windows 2003. NETWORK SERVICE is a low privileged account under which you can run your application pools and websites. A website running in a Windows 2003 pool can still impersonate the site's anonymous account (IUSR_ or whatever you configured as the anonymous identity).

In ASP.NET prior to Windows 2008 you could have ASP.NET execute requests under the Application Pool account (usually NETWORK SERVICE). Alternatively you could configure ASP.NET to impersonate the site's anonymous account via the <identity impersonate="true" /> setting in web.config file locally (if that setting is locked then it would need to be done by an admin in the machine.config file).

Setting <identity impersonate="true"> is common in shared hosting environments where shared application pools are used (in conjunction with partial trust settings to prevent unwinding of the impersonated account).

In IIS7.x/ASP.NET impersonation control is now configured via the Authentication configuration feature of a site. So you can configure to run as the pool identity, IUSR or a specific custom anonymous account.


The LOCAL SERVICE account is a built-in account used by the service control manager. It has a minimum set of privileges on the local computer. It has a fairly limited scope of use:

LocalService Account


You didn't ask about this one but I'm adding for completeness. This is a local built-in account. It has fairly extensive privileges and trust. You should never configure a website or application pool to run under this identity.

LocalSystem Account

In Practice:

In practice the preferred approach to securing a website (if the site gets its own application pool - which is the default for a new site in IIS7's MMC) is to run under Application Pool Identity. This means setting the site's Identity in its Application Pool's Advanced Settings to Application Pool Identity:

enter image description here

In the website you should then configure the Authentication feature:

enter image description here

Right click and edit the Anonymous Authentication entry:

enter image description here

Ensure that "Application pool identity" is selected:

enter image description here

When you come to apply file and folder permissions you grant the Application Pool identity whatever rights are required. For example if you are granting the application pool identity for the ASP.NET v4.0 pool permissions then you can either do this via Explorer:

enter image description here

Click the "Check Names" button:

enter image description here

Or you can do this using the ICACLS.EXE utility:

icacls c:wwwrootmysite /grant "IIS AppPoolASP.NET v4.0":(CI)(OI)(M)

...or...if you site's application pool is called BobsCatPicBlogthen:

icacls c:wwwrootmysite /grant "IIS AppPoolBobsCatPicBlog":(CI)(OI)(M)

I hope this helps clear things up.


I just bumped into this excellent answer from 2009 which contains a bunch of useful information, well worth a read:

The difference between the 'Local System' account and the 'Network Service' account?

Sunday, June 6, 2021
answered 6 Months ago

This behavior was part of RFC 1808 (Section 4) which is about 16 years old, so every major browser should (and does) support this.

Sadly, there's a bug with IE7 and -8 that will make them download the resources twice if a protocol-relative URL is used on a link or @import - which shouldn't be a big problem, but is ugly and should be kept in mind.

Sunday, June 13, 2021
answered 6 Months ago

The solution is to properly convert the ogg file into mp3 or vice versa. The encoding was wrong when I just renamed the .ogg file to mp3, silly me. I used software called "Audacity" and "Switch" to accomplish this.

Saturday, June 19, 2021
answered 6 Months ago

The NTP client sends a packet with its local time orig_time, which the NTP server receives at the server time recv_time. The server then replies at server time tx_time and the client receives that reply at local time dest_time.

The round trip delay is calculated as recv_time - orig_time + dest_time - tx_time, and the offset between the clocks is offset = (recv_time - orig_time + tx_time - dest_time) / 2.

Assuming the two NTP packets take consistent paths, the correct adjusted time is simply dest_time + offset, which is equivalent to tx_time + delay/2.

Friday, October 1, 2021
Nicola Pesavento
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :