tags:

views:

330

answers:

10

According to w3c </TD> and </TR> tags are optional, so the following table is perfectly valid.

<table>
  <tr>
    <td>google
    <td>chrome
</table>

And all browsers I've tested it with render the table fine. I just wanted to ask if this is generally considered safe to use, or if older browsers, which I don't have access to, cause problems. Thanks.

It reduces gzip html size on a page with many tables by a few percent.

+15  A: 

This is valid HTML but invalid XHTML.
There's nothing intrinsically wrong with it.

If you look at the source for Google's privacy policy (or any of their other pages), you'll find some much terser HTML.

It does mean that your page will not be usable by an XML parser.

SLaks
It may be valid, but it is disgusting... personal opinion
Christopher W. Allen-Poole
Google has a different scale than most of us; a single byte can save gigabytes per day.
Greg Hewgill
Actually, if you remove the last script tag from the document (which is missing the customary <!-- and //--> pieces anyway), it can be read by PHP's DOMDocument HTML parser... not quite XML, but interesting none-the-less.
Christopher W. Allen-Poole
Oh sure. Google is amazing (and since this is policy, I'm sure it is more like gigabytes/hour or terabytes/day). But for most projects, that is hideous.
Christopher W. Allen-Poole
+9  A: 

I strongly recommend against doing that, though it is valid in HTML4 (and 5). The bandwidth savings are miniscule when compared to the technical debt you are incurring. Also keep in mind it is not valid in XHTML, so be sure your doctype is set appropriately.

Andrew Barber
Wow; someone is really religiously attached to their un-closed HTML tags!
Andrew Barber
What technical debt are you incurring?
Chuck
+9  A: 

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.

DVK
Readability isn't a problem because the tables are automatically generated by a Python script. However, I noticed a different problem. Many of the TDs have a mouseover/mouseout event attached to them to change/restore background color, and IE lags the background change when closing TD/TR is omitted. Other browsers don't.
pdknsk
@pdknsk - i thought that autogenerated HTML didn't matter readability wise... up till the first time I had to debug the resulting HTML/JS :)
DVK
Regarding performance: I would suggest that removing closing tags actually *improves* rendering time. When you get to `<td>` and you are already inside a `<td>`, browsers know that this element cannot be nested directly and creates a sibling node. With the closing tags, the browser has to read a few more characters before getting to the same point. (Obviously, this will be a negligible saving, even on a large table.)
DisgruntledGoat
A: 

Close all tags in HTML for a few reasons:

  1. Not closing tags is tolerated, but it is not correct modern XHTML. It's deprecated much in the same way that HTML style attributes are in favor of CSS
  2. It's more readable for the next guy if you close the tags
  3. Browsers will actually have an easier time parsing your source if it more strictly adheres to the rules, even if that makes the source longer
Rafe Kettler
Why verbosely close tags is HTML because it's required in another language? Do you mark all your global JavaScript variables with a $ because it's required in Ruby? Use only immutable data structures because it's required in Haskell?
Chuck
@Chuck: What a failure. JavaScript is not an updated version of Ruby. Your examples are ludicrous. It's more like comparing C90 to C99. Also, closing tags in HTML isn't verbose, it's clear. That's like saying using variable names longer than 1 character is verbose.
Rafe Kettler
@Rafe Kettler: And XHTML is not an updated version of HTML5 — it's a reformulation of HTML as an XML dialect. And I say "verbosely closing" because the tags are already closed just by creating another `tr` or by closing the `table`. Writing out a closing tag is a more verbose way of accomplishing the same thing as not writing out a closing tag. Whether it's clear or not is subjective, but it is unquestionably more verbose. And to say it "more strictly adheres to the rules" of HTML is plainly false.
Chuck
Like I said in my answer to the question, it is 1.) clearer, 2.) more compatible, and 3.) more modern. You can defend poor style all day long, but at the end of the day there's a better way to do it.
Rafe Kettler
Then you have "It's clearer" — which is subjective, but I do agree with it — and two falsehoods. HTML5 is the most recent (i.e. modern) HTML standard, and it says the closing tag is optional, so "more modern" is wrong. And it is compatible with every HTML standard and every browser AFAIK, so in the context of HTML, "more compatible" is wrong. You're welcome to your own opinion, but you still can't make up your own facts.
Chuck
Mobile browsers tend to stumble over it.
Rafe Kettler
+1  A: 

I advise always closing your tags. There's not really too good of a reason not to. Browsers can handle some improperly closed tags, but just to be on the safe side (and it's good programming practice!), close your tags!

Kevin Hwang
We're not talking about improperly closed tags. That markup is proper and the tags are properly closed according to the language standard.
Chuck
+2  A: 

Personally I don't consider it good practice. Looking at the spec it didn't give a whole lot of information. I know it's required for XHTML so I looked up the HTML 5 spec. HTML 5 seems to take the same take on it as HTML 4 which is what you've linked to, but gives a little more information:

A td element's end tag may be omitted if the td element is immediately followed by a td or th element, or if there is no more content in the parent element.

McAden
A: 

Certainly if you are using only HTML there is absolutly no problem thats not the case with XHTML nevertheless i don't think you can get that much, also i suggest dont abuse tables remember div are better than tables

Necronet
Divs are not better than tables for displaying tabular data.
Chuck
They have more flexibility that plain old Table i rather prefer a Div regular layout than trying to do the same with a <Table>
Necronet
+5  A: 

There have been optional tags in HTML since the very beginning — they are a feature inherited from SGML, and so the early browsers must have been able to deal with them. While XHTML moved away from this and required a much more uniform syntax, this doesn’t affect you unless you explicitly tell the browser to parse in XML mode. I’ve never seen a problem when using the standard parsers of HTML 4/5.

Since HTML5 so carefully describes when certain tags are optional, I would read that to imply that someone did lots of testing to make sure that in these cases, most browsers produce the same document tree.

And while the space savings are negligible, I find that leaving off the closing tags of <p>, <li>, <td>, and <tr> simply makes my life easier when I’m working in the markup, and makes me less likely to make an error.

jleedev
+2  A: 

Always close your tags!

Derek B.
A: 

It’s Ok with Static Pages not for Dynamic Pages …to debug

Sagar
i did not quite get this answer?.... what do you mean static yes but on dynamic no?
Necronet
@Necronet: I *think* what he's trying to get at is that this shorthand makes it harder to debug the output of your HTML generator (presumably because it's harder to read).
Chuck