Presently, it displays a 2px “border” around the cells. It does that because {border-collapse:collapse} was causing a problem in Chrome. Apparently, the combination of absolute positioning in the target cells and {border:collapse:collapse} on the table created the conflict. Now, if you prefer your original 1px border, just change {border:collapse:separate} to {border:collapse:collapse}.
table {
border-collapse:collapse; /* changed from {border-collapse:separate} */
border-spacing:0 0; /* harmless as is, but can be deleted */
margin:0 auto;
}
You will also need to change .ll,.rr {bottom:-2px} to .ll, .rr {bottom:-1px}, and change {padding:2px 2px 7px} to {padding:2px 2px 6px} to match the baseline in surrounding boxes.
.ll,.rr {
background-color:#84d0ef;
position:relative;
bottom:-1px; /* changed from -2px */
padding:2px 2px 6px; /* padding-bottom changed from 7px to 6px */
}
I was trying to emphasize in the graphic the option to display the left and right sides of 4/4’s border . . . after the two color blocks have been extended vertically — by 1px — to occupy that space. See rp’s post #36 for an example.
I believe that assignment was a mistake made before posting here… a faulty attempt to keep the two boxes flush side-by-side. Because I can fathom no useful reason for the property, I have removed it from my code. If I am wrong, it’s easy enough to add it back.
I tried that method of coloring r4c4 early on. It’s content dependent. Remove the “Lorem Ipsum” from the yellow div, restore the short word. Also note that column 1 is supposed to have a max width of 60px per semicolon.
Post 68 works using 6 columns (semicolon didn’t specify that the two cells were supposed to have equal widths… of course, that may change… )
Semi’s request is almost as challenging as one of @PaulOB’s CSS challenges (regardless of semi’s undecided goalposts).
Useful point. He may only want the top left cell to have a defined width. I had assumed that it applied to the full column (as you stated) except row4 where he applied colspan=“3” to the first cell therefore it properly ignored the width property. But maybe he plans to add colspans to other first cells also (as you just demonstrated).
To round out your explanation, he would need to apply colspan=“value gt 1” to the first cell to account for 5 cells per row. The width will depend on the sum of the widths of the columns spanned
Using the default table-layout:auto algorithm, table-cell widths are “starting points” at best. They will auto-adjust as needed to allow content to fit in the matrix of the table. Used sparingly, cells do seem to honor “max-width” if they can. The layout may “break” if they can’t.
The problem with the nested table-cell approach is simply that the anonymous table around the cells has no definable width and height with which the cells associate. I could not think of a way to give it 100% w and h dimensions. If there is some new magic in the wings that allows that to be done, then the nested cells will adapt to its dimensions. The same problem would exist if an element with display:table surrounded the cells, so it’s not just the anonymous table.
Looks like there’s been activity! So give me an hour and we’ll see what kind of trouble we can get into.
Edit:
Okay, it’s coming back to me! Look at my post #58 . . . I was comparing the two versions re: that bottom border, and (not to be greedy) I wanted to achieve both styles to compare them. I’m sorry Ron, Coot, please believe me I don’t intend to keep “moving the goalpost!” What’s really helpful is your >>naming the code bits (eg. coot99, coot98, rp93, rp94 etc.).
Now that you have returned to this thread, I will now
draw your attention to my actual views about it.
You have not indicated any genuine tabular data for this project.
This, to my mind, is akin to “putting the cart before the horse”.
I don’t really believe in messing about with tabular data; it should
just be presented in as simple and logical way as possible and
definitely without any of that “arty farty” messing about.
Here I am . . .
