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:



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

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


Or you could put the cell's content in a DIV inside the cell, and let the DIV overflow instead.

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:



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?

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?

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.)."


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.


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.


No.

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.

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.

I understood that.



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: IE7:



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?

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


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.


No idea.

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")?

Oh, I source peeked so you don't have to explain what null P is.

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).

Another idea using only CSS:


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.

This post has been edited by Christian J: Dec 30 2011, 09:55 AM

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.



Peeked! But I probably should have said peeped. I'm still awaiting my peak.

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


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


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.

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.

The screen caps aren't of this problem. They show the misalignment of the weight column in those browsers. Not that it matters much.

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


Now that I actually tried



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.

Neither worked for me.

Here's a test case that shows the vertical alignment difference (you don't need a ruler to see it):


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


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 post has been edited by Christian J: Dec 30 2011, 09:22 PM