I've frequently seen a space preceding the closing slash in XML and HTML tags. The XHTML line break is probably the canonical example:
<br />
instead of:
<br/>
The space seems superfluous. In fact, I think that it is superfluous.
What is the reason for writing this space?
I've read that the space solves some "backwards compatibility issues." Which backwards compatibility issues? Are those issues still relevant, or are we still adding extra spaces for the sake of, say, IE3 compatibility? Does there exist some spec with the definitive answer on this?
If not backwards compatibility, then is it a readability issue? Similar to the Great Open Curly Brace debate?
void it_goes_up_here() {
int no_you_fool_it_goes_down_there()
{
I can certainly respect differing stylistic opinions, so I'll be happy to learn that writing the space is simply a matter of taste.
The answer is people wish to adhere to Appendix C of the XHTML1.0 specification. Which you only need to do if you are serving XHTML as text/html. Which most people do, because XHTML's real MIME type (application/html+xml) does not work in Internet Explorer.
No current browser cares for the space. Browsers are very tolerant of these things.
The space used to be required to ensure HTML parsers treated the trailing slash as an unrecognised attribute.
Supporting bobince's answer with screenshot of Netscape 4.80 showing documents
data:text/html,<title>space</title>foo<br />bar
(top left, linebreak rendered) and
data:text/html,<title>no space</title>foo<br/>bar
(bottom left, linebreak ignored).
Posting as answer to show the picture
Tangentially related: in fact I had a lengthy answer identifying the cause of such misbehaviour of ancient browsers (and resulting recommendation to include space) in misunderstood SGML specs, namely SGML Null End Tag (NET) (where 1<tag/2/3 equals 1<tag>2</tag>3 so 1<tag/>2 would actually mean 1<tag>>2), but not only I was unable to find good proof and concrete version of standard, I wasn't even able to grasp proper standard-complying behaviour. So few raw links for reference:
w3c validator notice mentioning problematic closing slash and pointing to
Empty elements in SGML, HTML, XML, and XHTML # www.cs.tut.fi/~jkorpela/
Beware of XHTML: Null End Tags (NET) stating, that
However, there are still some smaller user agents that properly support Null End Tags. One of the more well-known user agents that support it is the W3C validator.
(Unable to reproduce there now, but supports Lee Kowalkowski's statement about multiple browsers affected by this.)
XML W3C Working Draft 07-Aug-97 - latest specs draft that includes reference of Null End Tag in DTD snippet: NET "/>"
Are those issues still relevant or are we still adding extra spaces for the sake of, say, IE3 compatibility?
You were close - it is for Netscape 4.
It is interesting to see other rationalisations, but that's all it was meant for.
No, the space is not required but it is necessary for some older browsers to render those tags correctly. The proper way to do it is without the extra space as this is something XHTML inherited from XML.
In XHTML, br tags must be closed, but the space is not necessary. It's a stylistic thing. In HTML, br tags cannot be closed, so both are wrong.
The space just makes the tags more readable. I am a big proponent of formatting for more readable code. Little things like that go a long way. Without the space the closing tag blends in with the opening tag. It takes just an instant longer for me to process it as I am quickly reading the code.
I think that the white space is a way to reinforce the idea that this tag is empty and it closes itself.
Today i don't use the white space anymore because i never had a problem with no white space.
What if there was a very lazy html writer out there or maybe he had a fear of quotation marks.
Consider the following if you were his robot page crawler...
<img src=http://myunquotedurl.com/image.jpg />
versus
<img src=http://myunquotedurl.com/image.jpg/>
This might seem small but look what it can do if the space isn't there. The robot won't know if the slash is part of the url or part of the closing tag.
Related
More often than not I see HTML without the closing tags, especially body and html.
According to:
http://www.w3.org/TR/html5/sections.html#the-body-element
http://www.w3.org/TR/html5/semantics.html#the-html-element
This can be omitted, but what about cross device issues? Like running such HTML on androids or windows phone's or whatever you know where not having these closing tags this would not work.
Do we need it? Well that depends on your DTD. If you're using XHTML, then yes, you will need it to conform. For accessibility sake I would include the closing tags, you never know if there's a screen reader (or other piece of software) out there that only parses valid XHTML, you could be hindering partially sighted people for example.
Google will also, apparently, rank your valid documents higher than invalid documents in their listings.
Here's a document by a friend of a friend that answers your question a bit better; granted that it was written in 2008, I think some of the points still apply.
If you ever need to use the same html in an XHTML application you won't need to mess around with it, you can just copy it across and not have to worry about conforming (because you already are).
On a separate note, you are essentially future proofing your markup. Who's to say that the spec won't eventually change to "You must include the closing head and body tags"? You won't need to worry if you already have them. It is, however, highly unlikely that the spec will change to, "You must not include the closing head and body tags".
As a great man once said:
Should I close the lid of the toilet when I'm finished? Yes,
especially if the wife is going to use it after me.
- Darren Gourley (Nov 2015)
use https://validator.w3.org/
select your standards target... if that says it passes then I think its Gd enough.
Please bared in mind the HTML5 spec is still being defined/evolved.
Technically you could omit html, head and body tags all together as long as the markup follows the following conditions:
http://www.w3.org/TR/2011/WD-html5-20110525/syntax.html#optional-tags
In regards to your comment about half your team using them and half your team not I would suggest that as long as either option is technically standards compliant you just choose one and move on as the entire subject is open for discussion and interpretation. My personal opinion would be that it's probably more important for your team to get on the same page and produce work of a similar standard especially if you have more than one person working on a project simultaneously.
You can leave out the end tags. Indeed you can leave out the opening tags, too (obviously not if you are using any attributes on them).
Not only is that the case with the more recent standard, but it's been the case since the very beginning. (The obvious exception being if you are using the XML syntax, since XML itself requires all elements have an explicit closing tag.)
Browsers have been dealing with the existence of HTML documents lacking the trailing closing tags since the 1990s. If the standards hadn't allowed it they'd probably still have dealt with them, much as they try their best to deal with all manner of messy code. (This causes it's own problems, which was one of the motivations behind XML not allowing optional tags, but that's another matter).
Many people consider it poor style. I would be one of them. But it's certainly widely supported.
I posed a similar question some time ago and got a pretty good answer, now I would like to slightly modify that question in light of something I noticed while working with Google Maps.
The question is, I've always used <div style="clear:both"></div> to clear a float. There are other times when I've needed to create an empty element to be populated with JS, for example. Now, since HTML is a subset of XML, why can't I use <div style="clear:both" /> instead of typing the ugly closing tag.
I was given a great answer that I admittedly don't fully understand in my previous question, but while working with Google Maps I noticed that Google had the same idea that I did. In their very first code sample, they use <div id="map-canvas"/> without the ending tag.
So my new question is, even if this is not quite proper HTML, would there ever realistically be case where this would not work?
Please and thanks.
Now, since HTML is a subset of XML
HTML is not a subset of XML.
HTML 4 and earlier were SGML applications, but browsers never implemented the SGML specification properly.
XHTML 1.x is an XML application, but browsers will only use XML parsing rules if you serve XHTML with an XML content-type (like application/xhtml+xml).
HTML 5 has its own parsing rules that better reflect what browsers actually do. It allows a / character at the end of elements where the end tag must be omitted for the sake of people who are addicted to XML or have poor syntax highlighting software, but only those elements.
I noticed that Google had the same idea that I did. In their very first code sample, they use <div id="map-canvas"/> without the ending tag.
That is an error and is not allowed in HTML. It only "works" in browsers because the end of the document comes before the start of any element or text that is allowed as a child node of a div element.
The question is, I've always used <div style="clear:both"></div> to clear a float.
That's a nasty approach to the problem in the first place. It requires an extra element, and can add space where the element is rendered. Better, in almost every case, to set overflow: hidden on the containing element to cause it to wrap the floats.
HTML is not a subset of XML. HTML has a different structure. Some elements are singular (like image) and don't need a closing tag or ending / at all. The ones who do, need to be closed by a proper closing tag.
Some people use XHTML, though, which is basically HTML using XML syntax. It depends on the doctype you use.
Google's example is wrong in this case. It uses a Html 5 doctype. If you run their snippet through the W3 validator, it tells you:
Line 26, Column 26: Self-closing syntax (/>) used on a non-void HTML
element. Ignoring the slash and treating as a start tag.
<div id="map-canvas"/>
And that's what will probably happen in most browsers as well. They read it as if the div is just opened there. At a certain point it will be automatically closed. The / is ignored.
About the clearing of floats: the way you are doing it is old, and ugly because you need extra markup, for what is basically a CSS issue. Fortunately, there are better ways, a couple of which are described in detail here: What methods of ‘clearfix’ can I use?
I remember reading a while ago that in some cases leaving out end tags (</li>, for example) speeds up the rendering (and loading/parsing, since there is less bytes) of a webpage?
Unfortunately, I forgot where I read this, but I remember it saying this feature was specific to HTML 4.0.
Since I no longer have access to this source I was wondering if someone can confirm this or link to the documentation on w3c (since I wasn't able it find it myself)?
Thanks!
EDIT: Forgot to mention that I meant to ask if this behaviour is also available in HTML5.
EDIT 2: I manged to find the article again, and it does mention it only speeds the download speed of the page, not actual rendering:
One good reason for leaving out the end tags for these elements is because they add extra characters to the page download and thus slow down the pages. If you are looking for things to do to speed up your web page downloads, getting rid of optional closing tags is a good place to start. For documents that have lots of paragraphs or table cells this can be a significant savings.
Sorry for asking a pointless question! :(
Here is the list of HTML 4.01 elements.
http://www.w3.org/TR/html401/index/elements.html
The End Tag column says where end tags are optional.
However, take note that this is valid only in HTML 4.01. In Xhtml, all end tags are required. Not 100% sure about HTML5.
I wrote a HTML parser once, and believe me, if you're a parser and you're inside a <p> and you encounter a </table> end tag, it's slower to check in your document tree if that is correct, and if so, to close the current <p> first, than if you simply encounter a </p>.
Edit:
Ah, found it: http://dev.w3.org/html5/html-author/#index-of-elements
Same requirements as HTML 4.01.
New edit:
Oh, that was a page from 2009. This one is more up to date:
http://dev.w3.org/html5/spec/syntax.html#optional-tags
Some tags in some version of the HTML spec have optional end tags. However, I believe it is generally considered bad form to exclude the end tag.
As mentioned, the end tag of li is optional in html4:
http://www.w3.org/TR/html401/struct/lists.html#h-10.2
so technically this is valid:
<ul>
<li>
text
<li>
<span>stuff</span>
</ul>
But you are only saving 5 characters per li, not really worth what you lose in readability/maintainability.
EDIT: The HTML5 spec is sort of interesting:
An li element's end tag may be omitted if the li element is
immediately followed by another li element or if there is no more
content in the parent element.
Leaving out ending tags is usually forgivable by browsers (it's generally smart enough to know what you're doing). However, any css or js markup properties that the unclosed tag has can affect descendant and/or sibling tags, leaving you scratching your head as to what happened.
While XHTML does expect you to add a closing forward slash to self-contained tags, HTML 5 does not.
XHTML: <img src="" />
HTML5: <img src="">
If you're writing using an xhtml DOCTYPE, then the answer is 'yes', they are required. An xhtml document needs to be valid XML, which means that all tags need to be properly closed.
An HTML document is a bit less fussy. Some tags are specified as being 'self closing', which means you don't need to close them specifically. These include <br>, <img>, etc.
The browsers are generally pretty lenient, because they need to be able to cope with badly written code. But beware that sometimes skipping closing tags can result in different browsers interpreting your code differently, and producing hard-to-debug layout glitches.
In terms of page load speed, you might be right that there would be a marginal gain to be had in download speed and bandwidth costs, but it would be marginal. In terms of rendering, I suspect you'd actually lose speed if you provided invalid HTML, as the browser would have to work harder to parse it.
So even if there is a speed gain to be had it will be marginal, and I don't think skipping closing tags deliberately is a worthwhile exercise. It might possibly be helpful to reduce bandwidth if you're running a site that has massive traffic, but very few of us are writing for Facebook or Google; for virtually everyone else, it's better to write valid code than to try to shave those few bytes.
If you're that worried about bandwidth and page loading speeds, there are likely to be other better ways to reduce your page load sizes than this. For example, compressing your files with gZip will drastically reduce your bandwidth, with zero impact on your code or the browser. gZip compression can be configured in your web server, so you just switch it on and forget about it. You can also 'minify' your CSS and JS code by stripping out unnecessary white space. (HTML can also be minified to a certain extent, but beware that white space is syntactically relevant in HTML, so minifying may not be the right thing to do in all cases).
AFAIK, in XHTML you must always at least self-close a tag <img ... />
In HTML (non xml-html) some tags do not need to be closed. <img> for instance. However, I'd suggest making sure you know exactly which version you're targeting and use W3C's validation service to double-check.
http://validator.w3.org/
I don't see how this would speed things up except that you'd have to send less bytes of data per page (no /'s for some tags, no closing tags for others.) As for building the DOM, I don't know the details of a given implementation (webkit, mozilla, etc) to know which way is faster to parse. I would imagine XML is simply because it is more regular.
EDIT: Yes this behavior is available in HTML5. Note that the help pages are confusing, such as:
http://www.w3schools.com/html5/tag_meta.asp
Meta's in non-xml-html do not require the /, but they can have it. Because of the (in my opinion) leaning towards XML-flavored HTML's the ending slash is more prevalent in written HTML, but you can see they use both styles in the document. The Validator will let you know for sure what you can get away with. :)
In HTML 4.01, which became a W3C Recommendation way back in 1999, you're right:
9.3.1 Paragraphs: the P element
Start tag: required, End tag: optional
http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#h-9.3.1
And as for <li>,
Start tag: required, End tag: optional
http://www.w3.org/TR/1999/REC-html401-19991224/struct/lists.html#h-10.2
Some HTML1 closing tags are optional, i.e.:
</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>
Note: Not to be confused with closing tags that are forbidden to be included, i.e.:
</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>
Note: xhtml is different from HTML. xhtml is a form of xml, which requires every element have a closing tag. A closing tag can be forbidden in html, yet mandatory in xhtml.
Are the optional closing tags
ideally included, but we'll accept them if you forgot them, or
ideally not included, but we'll accept them if you put them in
In other words, should I include them, or should I not include them?
The HTML 4.01 spec talks about closing element tags being optional, but doesn't say if it's preferable to include them, or preferable to not include them.
On the other hand, a random article on DevGuru says:
The ending tag is optional. However, it is recommended that it be included.
The reason I ask is because you just know it's optional for compatibility reasons; and they would have made them (mandatory | forbidden) if they could have.
Put it another way: What did HTML 1, 2, 3 do with regards to these, now optional, closing tags. What does HTML 5 do? And what should I do?
Note
Some elements in HTML are forbidden from having closing tags. You may disagree with that, but that is the specification, and it's not up for debate. I'm asking about optional closing tags, and what the intention was.
Footnotes
1HTML 4.01
There are cases where explicit tags help, but sometimes it's needless pedantry.
Note that the HTML spec clearly specifies when it's valid to omit tags, so it's not always an error.
For example you never need </body></html>. Nobody ever remembers to put <tbody> explicitly (to the point that XHTML made exceptions for it).
You don't need </head><body> unless you have DOM-manipulating scripts that actually search <head> (then it's better to close it explicitly, because rules for implied end of <head> could surprise you).
Nested lists are actually better off without </li>, because then it's harder to create erroneous ul > ul tree.
Valid:
<ul>
<li>item
<ul>
<li>item
</ul>
</ul>
Invalid:
<ul>
<li>item</li>
<ul>
<li>item</li>
</ul>
</ul>
And keep in mind that end tags are implied whether you try to close all elements or not. Putting end tags won't automatically make parsing more robust:
<p>foo <p>bar</p> baz</p>
will parse as:
<p>foo</p><p>bar</p> baz
It can only help when you validate documents.
The optional ones are all ones that should be semantically clear where they end, without needing the end tag.
E.G. each <li> implies a </li> if there isn't one right before it.
The forbidden end tags all would be immediately followed by their end tag so it would be kind of redundant to have to type <img src="blah" alt="blah"></img> every time.
I almost always use the optional tags (unless I have a very good reason not to) because it lends to more readable and updateable code.
I am adding some links here to help you with the history of HTML, for you to understand the various contradictions. This is not the answer to your question, but you will know more after reading these various digests.
How Did We Get Here? – Dive Into HTML5
The History of the Web
Brief History of HTML
HTML’s History – HTML WG Wiki
Some excerpts from Dive Into HTML5:
[T]he fact that “broken” HTML markup still worked in web browsers led authors to create broken HTML pages. A lot of broken pages. By some estimates, over 99% of HTML pages on the web today have at least one error in them. But because these errors don’t cause browsers to display visible error messages, nobody ever fixes them.
The W3C saw this as a fundamental problem with the web, and they set out to correct it. XML, published in 1997, broke from the tradition of forgiving clients and mandated that all programs that consumed XML must treat so-called “well-formedness” errors as fatal. This concept of failing on the first error became known as “draconian error handling,” after the Greek leader Draco who instituted the death penalty for relatively minor infractions of his laws. When the W3C reformulated HTML as an XML vocabulary, they mandated that all documents served with the new application/xhtml+xml MIME type would be subject to draconian error handling. If there was even a single well-formedness error in your XHTML page […] web browsers would have no choice but to stop processing and display an error message to the end user.
This idea was not universally popular. With an estimated error rate of 99% on existing pages, the ever-present possibility of displaying errors to the end user, and the dearth of new features in XHTML 1.0 and 1.1 to justify the cost, web authors basically ignored application/xhtml+xml. But that doesn’t mean they ignored XHTML altogether. Oh, most definitely not. Appendix C of the XHTML 1.0 specification gave the web authors of the world a loophole: “Use something that looks kind of like XHTML syntax, but keep serving it with the text/html MIME type.” And that’s exactly what thousands of web developers did: they “upgraded” to XHTML syntax but kept serving it with a text/html MIME type.
Even today, millions of web pages claim to be XHTML. They start with the XHTML doctype on the first line, use lowercase tag names, use quotes around attribute values, and add a trailing slash after empty elements like <br /> and <hr />. But only a tiny fraction of these pages are served with the application/xhtml+xml MIME type that would trigger XML’s draconian error handling. Any page served with a MIME type of text/html — regardless of doctype, syntax, or coding style — will be parsed using a “forgiving” HTML parser, silently ignoring any markup errors, and never alerting end users (or anyone else) even if the pages are technically broken.
XHTML 1.0 included this loophole, but XHTML 1.1 closed it, and the never-finalized XHTML 2.0 continued the tradition of requiring draconian error handling. And that’s why there are billions of pages that claim to be XHTML 1.0, and only a handful that claim to be XHTML 1.1 (or XHTML 2.0). So are you really using XHTML? Check your MIME type. (Actually, if you don’t know what MIME type you’re using, I can pretty much guarantee that you’re still using text/html.) Unless you’re serving your pages with a MIME type of application/xhtml+xml, your so-called “XHTML” is XML in name only.
[T]he people who had proposed evolving HTML and HTML forms were faced with two choices: give up, or continue their work outside of the W3C. They chose the latter, registered the whatwg.org domain, and in June 2004, the WHAT Working Group was born.
[T]he WHAT working group was quietly working on a few other things, too. One of them was a specification, initially dubbed Web Forms 2.0, which added new types of controls to HTML forms. (You’ll learn more about web forms in A Form of Madness.) Another was a draft specification called “Web Applications 1.0,” which included major new features like a direct-mode drawing canvas and native support for audio and video without plugins.
In October 2009, the W3C shut down the XHTML 2 Working Group and issued this statement to explain their decision:
When W3C announced the HTML and XHTML 2 Working Groups in March 2007, we indicated that we would continue to monitor the market for XHTML 2. W3C recognizes the importance of a clear signal to the community about the future of HTML.
While we recognize the value of the XHTML 2 Working Group’s contributions over the years, after discussion with the participants, W3C management has decided to allow the Working Group’s charter to expire at the end of 2009 and not to renew it.
The ones that win are the ones that ship.
The reason i ask is because you just know it's optional for compatibility reasons; and they would have made them (mandatory | forbidden) if they could have.
That's an interesting inference. My reading of it is that just about any time a tag could be reliably inferred, the tag is optional. The design suggests that the intention was to make it quick and easy to write.
What did HTML 1, 2, 3 do with regards to these, now optional, closing tags.
The DTD for HTML 2 is embedded in the RFC which, along with the original HTML DTD, has optional start and end tags all over the place.
HTML 3 was abandoned (thanks to the browser wars) and replaced with HTML 3.2 (which was designed to describe the then current state of the web).
What does HTML 5 do?
HTML 5 was geared towards "paving the cowpaths" from the outset.
And what should i do?
Ah, now that is subjective and argumentative :)
Some people think that explicit tags are better for readability and maintainability by virtue of being in front of the readers eyes.
Some people think that inferred tags are better for readability and maintainability by virtue of not cluttering up the editor.
What does HTML 5 do?
The answer to this question is in the W3C Working Draft:
http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission
And what should i do?
It's a matter of style. I try to never omit end tags because it helps me to be rigorous and not omit tags that are necessary.
If it is superfluous, leave it out.
If it serves a purpose (even a seemingly trivial purpose, such as appeasing your IDE or appeasing your eyes), leave it in.
It's rare in a well-defined spec to see optional items that do not affect behavior. With the exception of "comments", of course. But the HTML spec is less of a design spec, and more of a document of the state of current major implementations. So when an item is optional in HTML and it seems to serve no purpose, we may guess that optional nature is merely documentation of a quirk in specific browser.
Looking at the HTML-5 spec RFC section linked above, you see that the optional tags are strangely linked to the presence of comments! That should tell you that the authors are not wearing design hats. They are instead playing the game of "document the quirks" in major implementations. So we can't take the spec too seriously in this respect.
So, the solution is: Don't sweat it. Move on to something that actually matters. :)
I think the best answer is to include closing tags for readability or error detection. However, if you have lots of generated HTML (say, tables of data), you could save significant bandwidth by omitting optional tags.
My recommendation is that you omit most optional close tags, and all optional attributes that you can get away with. Many IDEs will complain so you may not be able to get away with omitting some of these but it is generally better for smaller file size and less clutter. If you have code generators definitely omit end tags there because you can get some good size reduction from it. Usually it doesn't really matter one way or the other.
But when it does matter then act on it. On some recent work of mine I was able to reduce the size of my rendered HTML from 1.5 MB to 800 KB by eliminating most of the generated end and redundant value attributes for the open tag, where the text of the element was the same as the value. I have about 200 tags. I could implement this some other way entirely, but that would be more work ($$$), so this allows me to easily make the page more responsive.
Just out of curiosity I found that if I removed quotes around attributes that didn't need them I could save 20 KB, but my IDE (Visual Studio) doesn't like it. I also was surprised to find that the really long ID that ASP.NET generates account for 20% of my file.
The idea that we could ever get any relevant fraction of HTML strictly valid was misguided in the first place, so do whatever works best for you and your customers. Most tools that I have ever seen or used will say they generate xhtml, but they don't really work 100%, and there isn't any benefit to strict adherence anyway.
Personally, I'm a fan of XHTML and, like ghoppe, "I try to never omit end tags because it helps me to be rigorous and not omit tags that are necessary."
but
If you're deliberately using HTML 4.n, one can't argue that including them makes it easier to consume the document, as the notion of well-formedness as opposed to validity is an XML concept, and you lose that benefit when you forbid certain close tags. So the only issue becomes validity... and if it's still valid without them... you might as well save the bandwidth, no?
Using end tags makes dealing with fragments easier because their behaviour is not dependant on sibling elements. This reason alone should be compelling enough. Does anyone deal with monolithic html documents anymore?
In some curly bracket languages like C#, you can omit the curly braces around an if statement if its only two lines long. for example...
if ([condition])
[code]
but you can't do this...
if ([condition])
[code]
[code]
the third line won't be a part of the if statement. it hurts readability, and bugs can be easily introduced, and be difficult to find.
for the same reasons, i close all tags. tags like the img tag do still need to be closed, just not with a separate closing tag.
Do whatever you feel makes the code more readable and maintainable.
Personally I would always be inclined to close <td> and <tr>, but I would never bother with <li>.
If you were writing an HTML parser, would it be easier to parse HTML that included optional closing tags, or HTML that doesn't? I think the optional closing tags being present would make it easier, as I wouldn't have to infer where the closing tag should be.
For that reason, I always include the optional closing tags - on the theory that my page might render faster, as I'm creating less work for the browser's HTML parser.
For forbidden closing types use syntax like: <img /> With the /> to close the tag which is accepted in xml
I have a lot of empty span tags and so on in my code, due to CSS image replacement techniques.
They trigger a HTML validation warning.
Should I care?
I agree with #Gumbo, but having lots of warnings that make no difference can hide the ones that you do need to pay attention to. If you can put something in the span that gets rid of the warning but doesn't break your UI, you should at least think about doing it.
I've made validation part of my workflow because it helps me catch mistakes early. And while I don't consider empty elements to be a problem, it negates some of the value of using a validator if I have to mentally parse a list of warnings each time and decide whether a warning is important or not. So I try to keep my pages both error- and warning-free so that a quick glance at the HTML Validator icon in the Firefox status bar only changes when there is a real problem. To that end I keep empty elements "unempty" by inserting an empty comment.
<span><!-- --></span>
(At least that works with the Tidy validator.)
Now, that being said, I don't think this is at all necessary for many situations. It is perfectly reasonably to think that adding eight extra characters to your code just to avoid a validator warning is ridiculous. But it works for me.
You should consider the behavior of the page for things like screen readers. It is common to actually put a few words describing the image in the tag that are then hidden by the image replacement.
See the CSS Zen Garden where you can see examples like H1 spans with text being replaced in CSS by images.
This will improve the not only the accessibility of your site, but also the search-ability.
An "empty" tag has a very specific definition in HTML:
<span/>
versus
<span></span>
The former is not permitted by the HTML 4.0 Strict DTD, so should be flagged by a validator. The only tags that can use the former syntax are those specifically identified as "EMPTY" in the DTD (eg, <br>).
The second form is valid HTML, and does not get flagged by the W3C validator.
So I have to assume that either (1) your validator is broken, or (2) you are using the tag incorrectly.
A warning is not an error. It’s just a reminder that you should improve something.
I suppose if bandwidth was an issue, those empty tags could be revisited to see if you could get them from appearing alogether.
Eric Meyer also says that empy tags are bad, semantically.
Warning don't mean it's wrong, but say it could, or sometimes should, be better.
In the same way
if("value"==variable)
is better than
if(variable=="value")