Help - Search - Members - Calendar
Full Version: Fixing the height of a table row
HTMLHelp Forums > Web Authoring > Cascading Style Sheets
Brian Chandler
In a document which is actually a printed form, I would like to fix the height of a row, and let anything which overflows just disappear. This is internal, so I can't immediately show you a copy, and it's also for use in Firefox, so browser independence isn't really an issue.

Q1: Should I be able to do this with CSS, and how?

Yes, I have tried... I tried adding the following:

CODE

style="height: X; overflow: hidden"


where I tried values for X like 1em, 0.5em, 4mm, and I tried adding this to the <tr> or to the <td> in question. None of this seems to have any effect whatsoever.

Q2: Am I somehow doing the (obviously) wrong thing here? If what I am doing 'should' work, I'll make a copy of the page for more specific comments.

Thanks
Christian J
QUOTE(Brian Chandler @ Dec 27 2011, 08:15 AM) *

Q1: Should I be able to do this with CSS, and how?

CSS overflow only applies to block elements, which AFAIK doesn't include table rows and cells. You might change that with

CODE
td {display: block;}

Or you could put the cell's content in a DIV inside the cell, and let the DIV overflow instead.
Brian Chandler
QUOTE(Christian J @ Dec 28 2011, 12:37 AM) *

CSS overflow only applies to block elements, which AFAIK doesn't include table rows and cells.


Thanks. I would never have guessed.

I found some W3C stuff which purports to describe "Block-level boxes" here:
http://www.w3.org/TR/CSS2/visuren.html#block-boxes
But it reads like legalese wordplay to me. Is the first sentence supposed to be a *definition* of what a block-level element is, or is that somewhere else? Who knows.

Anyway, the truly fascinating thing about CSS is the artful way it sucks you in. Try this, try that, always something _else_ goes wrong, giving four new things to try, until it's tea time, and I give up.

I tried td {display: block;} but this appears to result in a disaster: the whole table disintegrates, and the <td>s appear in a single column.

I tried putting the td content inside a <div>. This sort of works, but the text inside the div inside the td doesn't align with text directly inside a td. I asked about this the other day: how can I control the spacing (padding? margin? who knows?) around bare text, and no-one seems to know.

I can kludge things back in the right direction by putting the text inside a <p> inside the <div>, where everything has zero margin and padding, and no border.

Here's one try: put the text inside a null <p> inside a clip-to-1em-height <div>... here's a sample file:

http://imaginatorium.org/private/purchrecd.html

You will see that the relevant <td> including the title, which I want to chop if it's too long, now goes

<td><div class=ht1em><p class=null>A jolly title</p>...

Here's the CSS for the <div> and <p> for reference:

CODE

.ht1em {    /* clips content to 1em height */
    margin: 0;
    border: none;
    padding: 0;
    height: 1em;
    overflow: hidden;
}

P.null {
    margin: 0;
    border: none;
    padding: 0;
    line-height: 1em;
background-color: #ffff99;
}



I manually removed this <p> from the second entry, to show the effect of bare text within the div. I would, once, have imagined that putting a <div> with zero margin, padding, and no border, would not affect the positioning of text, but it does. Why would inserting another layer, the <p> somehow move the text back to the original position?

Again, this seems a crazy amount of effort to do something trivial. Is putting bare text within a <td> somehow frowned on? Is there a "proper" way to do it?






pandy
What text should it be align with and isn't? Everything looks aligned to me except the Weight column and I guess that's by design?
Christian J
QUOTE(Brian Chandler @ Dec 28 2011, 04:32 PM) *

I found some W3C stuff which purports to describe "Block-level boxes" here:
http://www.w3.org/TR/CSS2/visuren.html#block-boxes
But it reads like legalese wordplay to me. Is the first sentence supposed to be a *definition* of what a block-level element is, or is that somewhere else? Who knows.

It says "those elements of the source document that are formatted visually as blocks (e.g., paragraphs)." A definition of "blocks" is missing, but further down it says "Inline-level elements are those elements of the source document that do not form new blocks of content; the content is distributed in lines (e.g., emphasized pieces of text within a paragraph, inline images, etc.)."

QUOTE
Anyway, the truly fascinating thing about CSS is the artful way it sucks you in. Try this, try that, always something _else_ goes wrong, giving four new things to try, until it's tea time, and I give up.

Fortunately I knew from experience that table cells don't support overflow, such as scrollbars. I guess that's because tables are meant to expand to fit their content, which is not possible with any of the "overflow" values (a table might be the wrong choice of HTML element if you don't want it to expand to fit its content). Then I just had to find confirmation of this in the spec, which was right here: http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow

BTW, older Gecko browsers used to support "overflow" for TBODY as shown here, but Firefox seems to have dropped support for that since version 4.

QUOTE
I tried td {display: block;} but this appears to result in a disaster: the whole table disintegrates, and the <td>s appear in a single column.

Sorry, try "inline-block" for multiple columns. You'll need a relatively new Firefox version, and it may mess up cell widths unless they are explicit.

QUOTE
Is putting bare text within a <td> somehow frowned on?

No.


Brian Chandler
QUOTE(pandy @ Dec 29 2011, 01:00 AM) *

What text should it be align with and isn't? Everything looks aligned to me except the Weight column and I guess that's by design?


Sample again: http://imaginatorium.org/private/purchrecd.html

I'm talking about vertical alignment... (I don't see how the weight column isn't aligned: the boxes should be in the same horizontal position, and the weight right-aligned before them)

The rows with the yellow background all have <td><div><p> </p></div></td>, and somehow the null <p> pulls the text back in line vertically. But in the second row ("White rats..."), I removed the <p>, so the text is directly inside the div, and in this case it moves down (at least in Firefox and Opera; if you need a screenshot I'll make one.)

Since the <div> and <p> both have zero padding, margin and no border, this seems odd behaviour, to say the least.
Brian Chandler
QUOTE
It says "those elements of the source document that are formatted visually as blocks (e.g., paragraphs)." A definition of "blocks" is missing, but further down it says "Inline-level elements are those elements of the source document that do not form new blocks of content; the content is distributed in lines...


Yes, this is not definition, this is circular hand-waving.

But anyway thanks for your experience. I have kludged something up for the real version which will do.

pandy
QUOTE(Brian Chandler @ Dec 29 2011, 08:51 PM) *

I'm talking about vertical alignment...

I understood that.

QUOTE
I don't see how the weight column isn't aligned:


K-Mel (whatever gecko version it is) and IE7. Those were probably what I used the other day. Looks alright in a later gecko.

K.Mel: Click to view attachment IE7: Click to view attachment

QUOTE
The rows with the yellow background all have <td><div><p> </p></div></td>, and somehow the null <p> pulls the text back in line vertically.


Don't see that in any browser I tried. But I don't think I have the latest either of Opera or FF. What's a null P?
Christian J
QUOTE(Brian Chandler @ Dec 28 2011, 04:32 PM) *

I asked about this the other day: how can I control the spacing (padding? margin? who knows?) around bare text, and no-one seems to know.

Please keep that in its own thread if you still have trouble with it...

QUOTE

For your own sanity I strongly recommend making simplified test cases without unnecessary content, class selectors etc.

Anyway, I too see a slight height difference between the first two column's text lines (the text in the DIV is a little lower). This appears to be due to DIV.ht1em's height of just 1em. Such a small value cuts off a little of letters with descenders, apparently this also affects the vertical alignment. Increasing the height to 1.2em seems to fix it in my test table, and you shouldn't need the P.

QUOTE
Why would inserting another layer, the <p> somehow move the text back to the original position?

No idea.


pandy
Maybe I don't get anything again, but wasn't the problem only with the cell that lacks yellow background ("White rats, symbol of treasure")? unsure.gif

Oh, I source peeked so you don't have to explain what null P is. wink.gif
Christian J
QUOTE(pandy @ Dec 30 2011, 03:01 AM) *

Maybe I don't get anything again, but wasn't the problem only with the cell that lacks yellow background ("White rats, symbol of treasure")? unsure.gif

That's because that cell didn't have a P element fix, like the other ones. I guess Brian wants to avoid using such P fixes if possible (or even better, avoid both DIVs and Ps).

QUOTE
source peaked

blink.gif
Christian J
Another idea using only CSS:

CODE
tr {
display: block;
height: 1.6em;
overflow: hidden;
}

td {
border: solid blue;
vertical-align: top;
}

Unfortunately it cuts off the bottom border of cells.

Edit: it also seems to ruin the grid structure if cells have unbreakable text strings longer than the cell width.
pandy
OK, I'm even more confused. You talked about the whole column, didn't you? And Brian talked about a single cell. And I don't see it at all.

QUOTE(Christian J @ Dec 30 2011, 03:42 AM) *

QUOTE
source peaked

blink.gif


Peeked! But I probably should have said peeped. I'm still awaiting my peak. laugh.gif
Christian J
QUOTE(pandy @ Dec 30 2011, 04:49 AM) *

OK, I'm even more confused. You talked about the whole column, didn't you?

If so I meant the column with the DIVs if there are no P fixes applied.

QUOTE
And Brian talked about a single cell.

Yes, that's his demo cell without the additional P fix.

QUOTE
And I don't see it at all.

Compare the first two cells in the second row (which isn't shown in your screen captures). It appears in all my browsers, but you may need a ruler to see it.
pandy
Ah, if a ruler is needed I wouldn't notice it. I looked for difference visible to the eye. I actually do see it if I make the text humongous. Seems hard to make it go way though. I tried several ways. I though moving the height to the cells and aligning the content of the cells to the top or bottom would work, but it didn't. sad.gif

The screen caps aren't of this problem. They show the misalignment of the weight column in those browsers. Not that it matters much.
Christian J
QUOTE(pandy @ Dec 30 2011, 04:30 PM) *

Seems hard to make it go way though.

You can increase the DIV height, see my post #9 above.

QUOTE
I though [...] aligning the content of the cells to the top or bottom would work

Now that I actually tried

CODE
td {vertical-align: top;}


it seems to work too (only for the white rats cell, but that's the important one anyway) --doesn't it for you?

But I think the DIV height should be increased too, otherwise the text in the cell's first line is cut off.


pandy
Neither worked for me.
Christian J
Here's a test case that shows the vertical alignment difference (you don't need a ruler to see it):

CODE
td {
background: pink;
font-size: 1em;
}
td div {
height: 1em;
overflow: hidden;
}

<table>
<tr>
<td>this text is correct</td>
<td><div>this text is too low<br>this line should be obscured</div></td>
</tr>
</table>

If you then increase the DIV height and/or give the TDs "vertical-align: top", the difference should go away:

CODE
td {
background: pink;
font-size: 1em;
vertical-align: top;
}
td div {
height: 1.2em;
overflow: hidden;
}

This works the same in all browsers I tested (possibly the DIV text gets a little too high in IE9 if you only increase the line-height).
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.