tbody

J

j

Is tbody required?

My rough understanding is that if there only one body and no thead or
tfoot it is not.

<table>
<tr><td>cell<td></tr>
</table>

should be OK. I have an editor that corrects that. Or is having a tbody
always good html?


Jeff
 
J

Jukka K. Korpela

Is tbody required?

Definitely yes and no.

A table element always contains at least one tbody *element* (unless you
<table>
<tr><td>cell<td></tr>
</table>

should be OK.

It is valid, and it contains a tbody element. Use your browser's
developer tools (press F12 to enter) to see this.
I have an editor that corrects that.

That's nice.
Or is having a tbody
always good html?

In my book (under preparation), explicit <tbody> tag is good HTML,
because it acts as a useful remainder: a tr element element is never a
child of a table element. If you have <table class=foo> and you naively
write a CSS selector table.foo > tr, then it matches no element.
Instead, you need to write e.g. table.foo > * > tr, because there is
always an intervening element.
 
D

dorayme

Jukka K. Korpela said:
Definitely yes and no.

A table element always contains at least one tbody *element* (unless you


It is valid, and it contains a tbody element. Use your browser's
developer tools (press F12 to enter) to see this.

I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Not that I use it, I like closing tags. But I never bother with the
tbody tags in simple table situations. However JK's point is good for
those who might forget that the tbody element is the real child of the
table element. Perhaps those of us who know this should prepare for
when we are really old and forgetful. But I think I will wing it a
 
J

j

Definitely yes and no.

A table element always contains at least one tbody *element* (unless you


It is valid, and it contains a tbody element. Use your browser's
developer tools (press F12 to enter) to see this.


That's nice.


In my book (under preparation), explicit <tbody> tag is good HTML,
because it acts as a useful remainder: a tr element element is never a
child of a table element. If you have <table class=foo> and you naively
write a CSS selector table.foo > tr, then it matches no element.
Instead, you need to write e.g. table.foo > * > tr, because there is
always an intervening element.

OK. I'm sold.

Lets say we have this:

<table>
<thead>
<tr><th>col 1 label</th><th> col 2 label</th></tr>
</thead>

<tbody>
<tr>...
<tr>...
<!--
Now,lets say I wanted to break the data into sections,which is common
when you ORDER BY in SQL.
-->

<tr><th colspan="2">Section Heading</th></tr>

<tr>...
<tr>...

Should that require another set of thead and tbody? The thead here would
serve a different purpose than the original thead column headers.

Using F12 in Chrome (thanks for the shortcut), it appears to me that the
browser adds a tbody but does not care about the th rows.

Jeff
 
J

Jukka K. Korpela

[...]
I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Well it shouldn't. The table has two cells. The second one, an empty
cell, should not be removed by a clean-up program. It could be removed
by a human editor who decides that the cell was a mistake.
Not that I use it, I like closing tags.

They have pros and cons. Sometimes you mean to type </td> but actually
type <td>.

Yucca
 
J

Jukka K. Korpela

Now,lets say I wanted to break the data into sections,which is common
when you ORDER BY in SQL.
-->

<tr><th colspan="2">Section Heading</th></tr>

<tr>...
<tr>...

Should that require another set of thead and tbody?

No, and a second thead would be a syntax error: a table may have at most
one thead and at most one tfoot. The reason behind this is that those
elements contain column headers that apply to all data cells in a column
The thead here would
serve a different purpose than the original thead column headers.

Here the row would contain a header cell that has a header for a group
of rows to follow. By accessibility principles, the th cell should thus
have a scope attribute, since its meaning can hardly be inferred
automatically without it. This calls for scope=rowgroup, which in turn
calls for a tbody, since it means that "the header cell provides header
information for the rest of the row group that contains it".
http://www.w3.org/TR/REC-html40/struct/tables.html#adef-scope

So:

<tbody>
<tr><th colspan="2" scope="rowgroup">Section Heading</th></tr>

<tr>...
<tr>...
<tbody>
<tr><th colspan="2" scope="rowgroup">Next section Heading</th></tr>

But the <tbody> tags (and tbody elements), or the scope attributes, are
not required by HTML specifications. It's a matter of accessibility, and
its practical impact varies (assistive software might fail to make use
of scope="rowgroup", or the structure of the table might be so messy or
complicated that the accessibility attribute does not help much).
 
J

j

<table>
<tr><td>cell<td></tr>
</table>
[...]
I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Well it shouldn't. The table has two cells. The second one, an empty
cell, should not be removed by a clean-up program. It could be removed
by a human editor who decides that the cell was a mistake.
Not that I use it, I like closing tags.

They have pros and cons. Sometimes you mean to type </td> but actually
type <td>.

I saw an argument recently for leaving off the closing tag. I don't
quite remember the usage but it was something like this:

Lets say we have a string of inline blocks (or other inline content):

<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>

There would be undesired white space between the blocks from the line
break. Whereas without the closing tag:

<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content

There wouldn't be. I would never write that, but I can't help but feel
that I've screwed up the example, perhaps this was for an inline list.

Jeff
 
D

dorayme

....
I saw an argument recently for leaving off the closing tag. I don't
quite remember the usage but it was something like this:

Lets say we have a string of inline blocks (or other inline content):

<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>

There would be undesired white space between the blocks from the line
break. Whereas without the closing tag:

<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content

There wouldn't be. I would never write that, but I can't help but feel
that I've screwed up the example, perhaps this was for an inline list.


Certainly there is an issue of white space in lists, where list items
are styled to be horizontal (as in many menus):

<http://dorayme.netweaver.com.au/lists/horizlist1.html>

and ways to avoid. Simply leaving out the closing tags does not do the
trick as far as I can see.

and similar issues would arise with an example with DIVS styled to be
displayed inline where there *were* closing tags, to prevent the
browser thinking each was inside the previous one, Russian doll style!
 
S

se

j said:
<table>
<tr><td>cell<td></tr>
</table> [...]
I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Well it shouldn't. The table has two cells. The second one, an empty
cell, should not be removed by a clean-up program. It could be removed
by a human editor who decides that the cell was a mistake.
Not that I use it, I like closing tags.

They have pros and cons. Sometimes you mean to type </td> but actually
type <td>.

I saw an argument recently for leaving off the closing tag. I don't quite
remember the usage but it was something like this:

Lets say we have a string of inline blocks (or other inline content):

<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>

There would be undesired white space between the blocks from the line
break. Whereas without the closing tag:

<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content

There wouldn't be. I would never write that, but I can't help but feel
that I've screwed up the example, perhaps this was for an inline list.

Jeff


Because a div is a block element, it has a line-break at the end
(default). That's why divs are placed vertically (in default). When
using inline or inline-block on those elements this line-break is
preserved. This is what you se. If you want a collaps between
ajacent inline-blocks, then use float instead. It is same with lists.
/se
 
S

se

se said:
j said:
2013-11-26 4:10, dorayme wrote:

<table>
<tr><td>cell<td></tr>
</table>
[...]
I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Well it shouldn't. The table has two cells. The second one, an empty
cell, should not be removed by a clean-up program. It could be removed
by a human editor who decides that the cell was a mistake.

Not that I use it, I like closing tags.

They have pros and cons. Sometimes you mean to type </td> but actually
type <td>.

I saw an argument recently for leaving off the closing tag. I don't quite
remember the usage but it was something like this:

Lets say we have a string of inline blocks (or other inline content):

<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>

There would be undesired white space between the blocks from the line
break. Whereas without the closing tag:

<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content

There wouldn't be. I would never write that, but I can't help but feel
that I've screwed up the example, perhaps this was for an inline list.

Jeff


Because a div is a block element, it has a line-break at the end
(default). That's why divs are placed vertically (in default). When
using inline or inline-block on those elements this line-break is
preserved. This is what you se. If you want a collaps between
ajacent inline-blocks, then use float instead. It is same with lists.
/se
Modification of above said - perhaps inline just builds in a space
between ajacent. Using float: left, margin:0,padding:0 will work.
I tried having a horizontal line of ancher tags <a>...</a> wrapped
in a div container. This also have a distance between the links,
even ancher tag is an inline element.
 
B

BootNic

[snip]
Certainly there is an issue of white space in lists, where list items
are styled to be horizontal (as in many menus):

[snip]

Modern browsers could use word-spacing.

IE8 +

The following set the word-spacing to -1em and uses margin-left on the li +
li to set the space between them.

http://www.w3.org/TR/css3-text/#word-spacing

..yankee {
display: block;
margin: 0;
padding: 0;
text-align: center;
word-spacing: -1em;
}
..yankee > li {
background-color: rgb(255, 165, 0);
display: inline;
margin: 0;
padding: 1px;
/* word-spacing is inherited reset to normal */
white-space: nowrap;
word-spacing: normal;
}
..yankee > li + li {
/* set space between li */
margin-left: 1px;
}
..yankee,
..yankee > li {
list-style: none;
}

<ul class=yankee>
<li><a href="example.html">Homepage</a></li>
<li><a href="example.html">Services</a></li>
<li><a href="example.html">Protection</a></li>
<li><a href="example.html">Products</a></li>
<li><a href="example.html">Calculators</a></li>
<li><a href="example.html">Tutorials</a></li>
<li><a href="example.html">Links</a></li>
<li><a href="example.html">FAQ</a></li>
<li><a href="example.html">Downloads</a></li>
<li><a href="example.html">Help</a></li>
<li><a href="example.html">Contact Us</a></li>
</ul>


--
BootNic Tue Nov 26, 2013 10:49 am
It's not that some people have willpower and some don't. It's that some
people are ready to change and others are not.
*James Gordon*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlKUwwYACgkQOcdbyBqMFBEsMgCeNaXn2NLdhJJD9RR26MDjVJml
XY8AnRuUY+lyupLEYlS9EhnQNn1i2+Xa
=CsNQ
-----END PGP SIGNATURE-----
 
J

Jonathan N. Little

j said:
<table>
<tr><td>cell<td></tr>
</table> [...]
I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Well it shouldn't. The table has two cells. The second one, an empty
cell, should not be removed by a clean-up program. It could be removed
by a human editor who decides that the cell was a mistake.
Not that I use it, I like closing tags.

They have pros and cons. Sometimes you mean to type </td> but actually
type <td>.

I saw an argument recently for leaving off the closing tag. I don't
quite remember the usage but it was something like this:

Lets say we have a string of inline blocks (or other inline content):

<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>

There would be undesired white space between the blocks from the line
break. Whereas without the closing tag:

<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content

There wouldn't be. I would never write that, but I can't help but feel
that I've screwed up the example, perhaps this was for an inline list.

It certainly would screwed up because unlike P and TD elements DIV's
closing tag is NOT optional.
 
J

Jukka K. Korpela

Certainly there is an issue of white space in lists, where list items
are styled to be horizontal (as in many menus):
[...]
Modern browsers could use word-spacing.

IE8 +

Word-spacing is supported ever since IE 6. But it's a wrong tool for
setting the spacing between the items of the list. Even if your items
are "foo" and "bar", some day someone will add not only the item
"supercalifragilisticexpialidocious" but also the item "foo bar zap".
 
S

se

"BootNic" skrev i meddelelsen

It cab also be done with margins like this. I modified your code to show
how.
Strange; it won't work unless using both margin-left and margin-right. And
the
value used is somewhat suprisingly.

<!DOCTYPE html>
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<style type="text/css">
..yankee {
margin: 0;
padding: 0;
border-style:none;
}
..yankee li {
background-color: rgb(255, 165, 0);
display: inline;
margin-left: -0.15em;
margin-right:-0.15em;
white-space: nowrap;
list-style: none;
}
..yankee a {
text-decoration:none;
padding:0 3px 0 3px;
}
</style>
</head>
<body>
<ul class=yankee>
<li><a style="margin-left:0;"href="example.html">Homepage</a></li>
<li><a href="example.html">Services</a></li>
<li><a href="example.html">Protection</a></li>
<li><a href="example.html">Products</a></li>
<li><a href="example.html">Calculators</a></li>
<li><a href="example.html">Tutorials</a></li>
<li><a href="example.html">Links</a></li>
<li><a href="example.html">FAQ</a></li>
<li><a href="example.html">Downloads</a></li>
<li><a href="example.html">Help</a></li>
<li><a href="example.html">Contact Us</a></li>
</ul>
</body>
</html>
 
J

Jukka K. Korpela

"BootNic" skrev i meddelelsen
news:[email protected]...

What? (I do understand Swedish. But I do not understand an attribution
without a quotation.)
It cab also be done with margins like this.

What is this "it" you are talking about? The Subject line refers to
word-spacing, which is just a wrong approach (to a problem that was not
stated).

Thank you. This will save my time. I considered posting a constructive
comment on a previous problem of yours, but now I know I shouldn't bother.
 
J

j

j said:
2013-11-26 4:10, dorayme wrote:

<table>
<tr><td>cell<td></tr>
</table>
[...]
I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Well it shouldn't. The table has two cells. The second one, an empty
cell, should not be removed by a clean-up program. It could be removed
by a human editor who decides that the cell was a mistake.

Not that I use it, I like closing tags.

They have pros and cons. Sometimes you mean to type </td> but actually
type <td>.

I saw an argument recently for leaving off the closing tag. I don't
quite remember the usage but it was something like this:

Lets say we have a string of inline blocks (or other inline content):

<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>

There would be undesired white space between the blocks from the line
break. Whereas without the closing tag:

<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content

There wouldn't be. I would never write that, but I can't help but feel
that I've screwed up the example, perhaps this was for an inline list.

Jeff


Because a div is a block element, it has a line-break at the end
(default). That's why divs are placed vertically (in default). When
using inline or inline-block on those elements this line-break is
preserved. This is what you se. If you want a collaps between
ajacent inline-blocks, then use float instead. It is same with lists.


I don't like floats as a universal solution. If the line wraps you have
to make sure all the heights are the same. You also lack vertical-align
which can be very useful. Since newer versions of IE fix their
inline-block issues, I see no reason not to add to the toolbox.

Jeff

Jeff
 
S

se

"Jukka K. Korpela" skrev i meddelelsen
"BootNic" skrev i meddelelsen
news:[email protected]...

What? (I do understand Swedish. But I do not understand an attribution
without a quotation.)
It cab also be done with margins like this.

What is this "it" you are talking about? The Subject line refers to
word-spacing, which is just a wrong approach (to a problem that was not
stated).

Thank you. This will save my time. I considered posting a constructive
comment on a previous problem of yours, but now I know I shouldn't bother.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Didn't respond to you. But I now do:
FOAD
Do you understand this time!.

Through the years here, you've been steadily scolded, despised and assaulted
OPs. You have displayed the same behaviour on other newsgroups -
comp.lang.javascript
for instance. You're nothing, but an idiot!.
 
S

se

"j" skrev i meddelelsen
j said:
2013-11-26 4:10, dorayme wrote:

<table>
<tr><td>cell<td></tr>
</table>
[...]
I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Well it shouldn't. The table has two cells. The second one, an empty
cell, should not be removed by a clean-up program. It could be removed
by a human editor who decides that the cell was a mistake.

Not that I use it, I like closing tags.

They have pros and cons. Sometimes you mean to type </td> but actually
type <td>.

I saw an argument recently for leaving off the closing tag. I don't
quite remember the usage but it was something like this:

Lets say we have a string of inline blocks (or other inline content):

<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>

There would be undesired white space between the blocks from the line
break. Whereas without the closing tag:

<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content

There wouldn't be. I would never write that, but I can't help but feel
that I've screwed up the example, perhaps this was for an inline list.

Jeff


Because a div is a block element, it has a line-break at the end
(default). That's why divs are placed vertically (in default). When
using inline or inline-block on those elements this line-break is
preserved. This is what you se. If you want a collaps between
ajacent inline-blocks, then use float instead. It is same with lists.


I don't like floats as a universal solution. If the line wraps you have
to make sure all the heights are the same. You also lack vertical-align
which can be very useful. Since newer versions of IE fix their
inline-block issues, I see no reason not to add to the toolbox.

It's not fixed. Why do you think so. What you just got in answer to your
problem - is USERS fixing of a problem, which browser-coders did not yet
fix. Probably because it's not cathegorized as a browser error. For some
website developers, who choose using the inline option for a horizontal
menu, the distanse would not matter. Ajacent menu blocks are yet to have
a suitable distance between them. You can regulate the anchor padding.

Saying "I don't like floats" no website developer with even sparse
experience
would take your standpoint. Floats is compleatly indispensable in modern
webdesign. Nobody wants to go back to use of tables as a universal layout.

/se
 
D

dorayme

BootNic said:
[snip]
Certainly there is an issue of white space in lists, where list items
are styled to be horizontal (as in many menus):

[snip]

Modern browsers could use word-spacing.

IE8 +

The following set the word-spacing to -1em and uses margin-left on the li +
li to set the space between them.

http://www.w3.org/TR/css3-text/#word-spacing

.yankee {
display: block;
margin: 0;
padding: 0;
text-align: center;
word-spacing: -1em;
}
.yankee > li {
background-color: rgb(255, 165, 0);
display: inline;
margin: 0;
padding: 1px;
/* word-spacing is inherited reset to normal */
white-space: nowrap;
word-spacing: normal;
}
.yankee > li + li {
/* set space between li */
margin-left: 1px;
}
.yankee,
.yankee > li {
list-style: none;
}

<ul class=yankee>
<li><a href="example.html">Homepage</a></li>
<li><a href="example.html">Services</a></li>
<li><a href="example.html">Protection</a></li>
<li><a href="example.html">Products</a></li>
<li><a href="example.html">Calculators</a></li>
<li><a href="example.html">Tutorials</a></li>
<li><a href="example.html">Links</a></li>
<li><a href="example.html">FAQ</a></li>
<li><a href="example.html">Downloads</a></li>
<li><a href="example.html">Help</a></li>
<li><a href="example.html">Contact Us</a></li>
</ul>

Interesting, but it plays up with your word-spacing settings
(independent of text size). In my Safari, for example, the e is cut
off "Homepage", the s off Services etc. Setting it to 0.5em restores
the end list item letters on my Safari at least. My FF seems fine
enough with your setting.

Naturally, trusting this on a public site might be unwise, but
interesting point!
 
J

j

"j" skrev i meddelelsen
j said:
On 11/25/2013 11:37 PM, Jukka K. Korpela wrote:
2013-11-26 4:10, dorayme wrote:

<table>
<tr><td>cell<td></tr>
</table>
[...]
I have an editor with a Tidy that cuts it down even further

<table>
<tr>
<td>cell
</table>

Well it shouldn't. The table has two cells. The second one, an empty
cell, should not be removed by a clean-up program. It could be removed
by a human editor who decides that the cell was a mistake.

Not that I use it, I like closing tags.

They have pros and cons. Sometimes you mean to type </td> but actually
type <td>.

I saw an argument recently for leaving off the closing tag. I don't
quite remember the usage but it was something like this:

Lets say we have a string of inline blocks (or other inline content):

<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>
<div style="display: inline-block; border: 1px">content</div>

There would be undesired white space between the blocks from the line
break. Whereas without the closing tag:

<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content
<div style="display: inline-block; border: 1px">content

There wouldn't be. I would never write that, but I can't help but feel
that I've screwed up the example, perhaps this was for an inline list.

Jeff



Yucca

Because a div is a block element, it has a line-break at the end
(default). That's why divs are placed vertically (in default). When
using inline or inline-block on those elements this line-break is
preserved. This is what you se. If you want a collaps between
ajacent inline-blocks, then use float instead. It is same with lists.


I don't like floats as a universal solution. If the line wraps you have
to make sure all the heights are the same. You also lack vertical-align
which can be very useful. Since newer versions of IE fix their
inline-block issues, I see no reason not to add to the toolbox.

It's not fixed. Why do you think so. What you just got in answer to your
problem - is USERS fixing of a problem, which browser-coders did not yet
fix. Probably because it's not cathegorized as a browser error. For some
website developers, who choose using the inline option for a horizontal
menu, the distanse would not matter. Ajacent menu blocks are yet to have
a suitable distance between them. You can regulate the anchor padding.

Saying "I don't like floats" no website developer with even sparse
experience
would take your standpoint. Floats is compleatly indispensable in modern
webdesign.


I never said otherwise. Images float one way or another, columns float.
But not everything should be a float for the same reasons I gave above.
You either have to control height or work out clears at set lengths.
Inline-blocks have a lot more uses than menus.

Margins and paddings are just as settable on inline-blocks as on
anything else.


Nobody wants to go back to use of tables as a universal layout.

And nobody should be forced to have rows of blocks of product thumbs or
such using only floats.

Jeff
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top