Link to home
Start Free TrialLog in
Avatar of timkamer
timkamer

asked on

Centering Nested div layers that are being floated

Greetings,

I've a container block that contains columns of nested divs that are floated left. The nested divs display images. For some reason, it appears that nested div elements that are floated can not be centered within their container block. When I remove the float:left line, bang, one long column of pictures. Happens in IE, FF, NS.

Here's the CSS.

.contentDesignPage {width: 699px;
            padding:0px 0px 0px 19px;
            margin:0px 0px 0px 0px;
            float:left;
            voice-family: "\"}\"";
             voice-family:inherit;
            width:680px;            
            }
            
            html>body #contentDesignPage {width: 680px;}
                                    
.designGroup {width: 680px;
          padding: 0px;
         margin: 19px 0px 0px 0px;
         background:#FFFFFF;
         text-align:center;
        }
                         
                                     
.designPic {margin: 0px 19px 8px 0px;
       padding: 0px;
      float: left;
      }

And here is the markup (class designPic, when floated, will not center in class designGroup):

<div class="contentDesignPage">
<cfoutput query="getHeading"><h2 style="width:660px;">#heading#</h2>
<p>#description#</p>
</cfoutput>
 <cfoutput query="getPictures" group="grID">
 <div class="designGroup"><div class="groupCaption"><h4>#groupheading#</h4></div>
  <cfoutput>
  <div class="designPic">
  <img src="../designs/#filename#">
  <p>#caption#</p>
  </div><!--end designPic
  </cfoutput>
  <hr>
 </div><!--end designGroup-->
 </cfoutput>
</div><!--end contentDesignPage-->


Perhaps some JavaScript could help? I dunno. Stumpt.

Kind Regards
Tim
Avatar of mreuring
mreuring
Flag of Netherlands image

Uhm, confused here, you want the image/caption combo to be float:left, or do you want it centered? You can't do both, that's insane, it's like telling somebody to drive on the left side of the road on top of the centerline. You've got to choose, left of the container or center of the container, you can't be on the left of the container in the center...

So, I suspect you had something in mind with this conflict of interrests, care to eleborate?

 Martin
Avatar of GrandSchtroumpf
GrandSchtroumpf

Seems like you want the behaviour of inline elements with centered text.  That can be done easily for images... but not for block-level elements such as divs.

What you would need is some way to center-float and element... and that's not supported by css.
I think that feature has been submitted to the requests list, so future versions of css might include it or include another mechanism that can be used to acheive the same thing.
I think your best option for now is to leave it left-aligned.  By the way what's wrong with left alignment?

Another solution is to use an inline elements for your image container and your caption.
And use absolute positioning to position the caption under the image.
Remember that an inline element should never contain a block element... You might need to break that rule if you use that solution.
Avatar of timkamer

ASKER

Thanks for your responses. To clear up any confusion:

I'm floating the nested divs (designPic) so that I get rows of pictures. I would like these pictures to be centered, as a whole, within the container block, but since I'm floating them, seems this isn't possible. The reason I want them centered is that it fits the design of the site. Being left justified there is too much white space on the right side where the pictures wrap to next row.

There is a complicated reason as to why I've set it up this way. There are certain arrangements the pictures must fall into in some cases, such as the first picture expanding the entire width of the containing block, and then 3 smaller falling under this, and in other cases the pictures will be all the same width - so it's a flexible template solution, allowing my cllient to upload pictures that need to be grouped in a certain fashion.

I would use a table, but I'm not sure how to dynamically generate a table that would have a row with one column and then a row with three columns, or a row with however many columns could fit in that row. floated divs is a way around this. A table doesn't seem a viable solution in this case.

oh well, I'll have to live with the left justification and that white space created by the wrapping.

A float center would be great! I was thinking of this on my way to work this morning.  

If you have any thoughts, please share.

Kind Regards
tim
There's a lot of ifs and buts to try and get this implemented, for instance this demo:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
      <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
      <title> new document </title>
      <meta name="author" content="Martin 'Windgazer' Reurings">
      <style type="text/css">
      body {
            text-align: center;
      }
      span {
            position: relative;
      }
      em {
            position: absolute;
            bottom: 0;
            left: 0;
      }
      img {
            margin-bottom: 1em;
      }
      </style>
</head>
<body>
<span><img src="alphafairya.gif" alt="a"><em>Comment A</em></span>
<span><img src="alphafairyb.gif" alt="b"><em>Comment B</em></span>
<span><img src="alphafairyc.gif" alt="c"><em>Comment C</em></span>
</body>
</html>

It does what you ask, but, the comment will not wrap so it is limited to maximum the width of the accimpanied image. There's some tricks I once tested to make it work in CSS2, but IE just didn't understand, that still being the number 1 browser...

Hope this helps,

 Martin
Hmmm, I'm being sloppy, I revoke that demo, it's a farce and only partially does what you wished for and that only in IE.
Is it possible to accomplish what I want?
Quite unlikely. I hate to say never, but I can't see a solution, sorry :(
How about this?  It does use some javascript, and another nested div just for layout, so it's not the cleanest solution, but I think it'll do what you want.  You can change the images to whatever you need, and you can have as many as you need.  Hope that helps.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
<style type="text/css">
#pseudocontainer img {
  float: left;
  width: 100px;
  height: 100px;
}

#pseudocontainer {
  margin: 0 auto;
}

.clear {
  clear: both;
}
</style>
<script type="text/javascript">
window.onload = setWidth;
window.onresize = setWidth;

function setWidth()
{
  var obj = document.getElementById("pseudocontainer");
  var imgs = obj.getElementsByTagName("img");
  var total = 0;
  for (var i = 0, n = imgs.length; i < n; i ++)
    total += imgs[i].offsetWidth;

  var x = getWidth();

  if (total > x)
    total = x * 0.95; // fudge factor to prevent scrolling

  obj.style.width = total + "px";
}

function getWidth()
{
  var x;
  if (self.innerHeight) // all except Explorer
    x = self.innerWidth;
  else if (document.documentElement && document.documentElement.clientHeight)
    x = document.documentElement.clientWidth; // Explorer 6 Strict Mode
  else if (document.body) // other Explorers
    x = document.body.clientWidth;

  return x;
}

</script>
</head>

<body>
<div id="container">
  <div id="pseudocontainer">
    <img src="minus.jpg">
    <img src="plus.jpg">
    <img src="test.jpeg">

    <img src="minus.jpg">
    <img src="plus.jpg">
    <img src="test.jpeg">

    <img src="minus.jpg">
    <img src="plus.jpg">
    <img src="test.jpeg">

    <img src="minus.jpg">
    <img src="plus.jpg">
    <img src="test.jpeg">

    <div class="clear"></div>
  </div>
</div>
</body>
</html>
dakyd -

I've gotten the pictures to center in the container block; however, I've a caption at the bottom of each picture that has gotten kicked out of the div that holds the img, causing all the pics to stagger.


/* this contains the many instances of designPic class */
.designGroup {width: 680px;
           padding: 0px;
           margin: 19px 0px 0px 0px;
           background:#F2F2F2;
           text-align:center;
           }
                         
/* this holds the image and the image's caption, which is being kicked out - the caption, that is, staggering the imgs. */      
.designPic img {margin: 0px 0px 0px 19px;
            padding: 0px;
            float: left;
            }
                        
.designPic {margin:0 auto;}
      
.clear {clear:both;}

.designCaption p {margin: 1px 0px 0px 0px;
               padding: 0px;
              color: #000000;
              text-align: left;
              font-family: Arial, Helvetica, sans-serif;
              font-size: 11px;
              border: 1px solid gray;
              }
                              
.designCaption {margin:0 auto;}



And here is the markup:

<cfoutput query="getPictures" group="grID">
<div class="designGroup">
  <div class="groupCaption"><h4>#groupheading#</h4></div>
  <cfoutput>
    <div class="designPic">
    <img src="../designs/#filename#">
    <div class="designCaption"><p>#caption#</p></div>
   </div>
  </cfoutput>
  <div class="clear"></div>
  <hr><!--this is hidden and cleared left so Firefox will wrap designGroup around all designPic instances.-->
 </div>
 </cfoutput>

I've fiddled and fiddled with it, can't get the captions back in the designPic div, which is where they are in the markup. I don't understand why this would happen.

Kind Regards
Tim
increased point value of question.
I guess it's possible to acheive what you want.
But, as i said before, the solution will probably not be very flexible and might need to break the standards...

It all depends on how much you are willing to pay for it.  I'm not taking about monney, but about flexibility.  There is no easy clean solution, that's for sure.

From your previous comment, it seems like on one single line, all images will have the same height.  What about the comments?  Will they also all have the same height?  Do you need to support multi-line comments?

Can you give us links to your current pages, so we can see the complete context.  We need to know what flexibility we need to keep for your layout not to break.
You can do something like the following, but like GrandSchtroumpf said, it's definitely not a clean CSS-driven solution.  Javascript does all the work, really.  However, you don't need to break the standards.  Hope that helps.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
<style type="text/css">
#pseudocontainer div {
  float: left;
  width: 100px;
}

#pseudocontainer div img {
  width: 100px;
  height: 100px;
}

#pseudocontainer {
  margin: 0 auto;
}

.clear {
  clear: both;
}
</style>
<script type="text/javascript">
window.onload = setWidth;
window.onresize = setWidth;

function setWidth()
{
  var obj = document.getElementById("pseudocontainer");
  var imgs = obj.getElementsByTagName("img");
  var total = 0;
  for (var i = 0, n = imgs.length; i < n; i ++)
    total += imgs[i].offsetWidth;

  var x = getWidth();

  if (total > x)
    total = x * 0.95; // fudge factor to prevent scrolling

  obj.style.width = total + "px";

  var widthSoFar = 0;
  var maxHeight = 0;
  var start = 0;
  for (var i = 0, n = imgs.length; i < n; i ++)
  {
    var currDiv = imgs[i].parentNode.getElementsByTagName("div")[0];
    if (widthSoFar + imgs[i].offsetWidth > total)
    {
      setHeights(start, i-1, maxHeight);
      start = i;
      widthSoFar = imgs[i].offsetWidth;
      maxHeight = currDiv.offsetHeight;
    }
    else
    {
      widthSoFar += imgs[i].offsetWidth;
      maxHeight = (maxHeight > currDiv.offsetHeight)? maxHeight: currDiv.offsetHeight;
    }
  }
  // do the one last row
  setHeights(start, imgs.length, maxHeight);
}

function getWidth()
{
  var x;
  if (self.innerHeight) // all except Explorer
    x = self.innerWidth;
  else if (document.documentElement && document.documentElement.clientHeight)
    x = document.documentElement.clientWidth; // Explorer 6 Strict Mode
  else if (document.body) // other Explorers
    x = document.body.clientWidth;

  return x;
}

function setHeights(start, end, height)
{
  var imgs = document.getElementById("pseudocontainer").getElementsByTagName("img");
  for (var i = start, n = end; i <= n; i ++)
  {
    var theDiv = imgs[i].parentNode.getElementsByTagName("div")[0];
    theDiv.style.height = height + "px";
//    theDiv.onclick = function() {alert(this.offsetHeight);};
  }
}
</script>
</head>

<body>
<div id="container">
  <div id="pseudocontainer">
    <div>
      <img src="minus.jpg">
      <div>Caption for image1 that is longer than the rest</div>
    </div>

    <div>
      <img src="plus.jpg">
      <div>Caption for image2 (short)</div>
    </div>

    <div>
      <img src="test.jpeg">
      <div>Caption for image3 not quite so short</div>
    </div>

    <div>
      <img src="minus.jpg">
      <div>Caption for image1</div>
    </div>

    <div>
      <img src="plus.jpg">
      <div>Caption for image2</div>
    </div>

    <div>
      <img src="test.jpeg">
      <div>Caption for image3</div>
    </div>

    <div>
      <img src="minus.jpg">
      <div>Caption for image1</div>
    </div>

    <div>
      <img src="plus.jpg">
      <div>Caption for image2</div>
    </div>

    <div>
      <img src="test.jpeg">
      <div>Caption for image3 that is really really long</div>
    </div>

    <div>
      <img src="minus.jpg">
      <div>Caption for image1</div>
    </div>

    <div>
      <img src="plus.jpg">
      <div>Caption for image2</div>
    </div>

    <div>
      <img src="test.jpeg">
      <div>Caption for image3 that is really really long, so it'll make everything kind of big</div>
    </div>

    <div class="clear"></div>
  </div>
</div>
</body>
</html>
Ok, i got a solution...
It was pretty easy actually, it's just that we try too hard to follow the recommendations and the good practice rules.
So here is the solution:  INLINE TABLES ;-)
The funny thing is that it's solid as a rock in all browsers no matter what the size of the image is and no matter what you use in the comment.
But of course it breaks all the recommendations and good practice rules.
I guess Cd& will be petrified if he ever sees this.  Personally, I think it's not worse than using javascript for layout.

Here is a link to the page:
http://www.serger.biz/ee/Q_21362857.html
Hey GrandS, glad you like tables after all !!
Seems to me, floating a CSS element, and center aligning a list are mutually contradictory strategies.
"Good practice" is what works as the person intended it, not some esoteric "latest rules to conform to"

This is way better than JS, AFA I am concerned --

<TABLE width= full screen or 800?>
  <TBODY>
      <TR>
        <TD width= left buffer> </TD>
         <TD width=max image width> images </TD>
         <TD width=right buffer> </TD>
       </TR>
     </TBODY>
</TABLE>

Sure I know this is not supposed to go in CSS, but I see situations where CSS will simply NOT do what tables can do, in specific cases, despite the "standards body" recommendations..
OK. I set up the remote server.

Here's why I need them centered, and why I need a flexible layout, as discussed above.

http://www.kamermedia.com/agd/design-ideas/designPage.cfm?dpID=2

http://www.kamermedia.com/agd/design-ideas/designPage.cfm?dpID=1

As you can see, the client will not accept this.

dakyd - I tried the revised JS you provided, and it pushed the group caption over along with the imgs. I will continue to investigate. I furthor messed things up and returned to the way I had it; however I think the JS you provided could work for me, as I had it center aligning and the captions in place. Will continue to work at it. I went back and have lost how to get to where I was, too late at night and making poor decisions...

sciwriter - not sure what you're saying exactly. If with a table, I can dynamically determine the number of columns in a row, then tables is an option.

Thanks for all you efforts and thoughts

Kind Regards
Tim

GS - the heigth and width can not be set. The coldfusion template needs to allow pictures of various sizes and heights. Check the links that I provided, and you'll see what I mean. Flexibilty is key.
Gee ...

Just use <center>  .... all the rest of your code here ....
</center>

So you've taken up all possible screen resolutions, including dynamic resizing, so what more?

Javascript, sure assign some <DIVs> to the page, and if you can't use center (flawless on tables), then go to the effort of calculating the screen size, and figuring a horiz and vert position, and go from there.  I just can't see where the problem is, trying to align a series of images down the center of the screen.... it escapes me.  Sorry.
<< coldfusion template >> = <<Flexibilty is key>>

No, I don't think so, CF is one of the most inflexible page developers there is.  You can do better hand coding.  CF has some value in making quick input forms, admitted (although that is still debatable), but for designing layouts of images in a dynamically resizable environment -- nope.  Sorry, but CF layouts give endless errors with most modern browsers.  Whenever I see a CF site (now, in the last 6 months), I say ooops, page load errors are coming, and sure enough, before I leave the site,  there is almost invariably 1 or more page load errors.  Fact...
ASKER CERTIFIED SOLUTION
Avatar of GrandSchtroumpf
GrandSchtroumpf

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
GS - I congatulate you on finding this hack! I had completely discarded anything along those lines as a display: block inside a display: inline element is just, uhm, not possible :) Well, it is, as you've proven, but then, as you mentioned recomendations and such, it's just not possible ;)
sciwriter - "I just can't see where the problem is, trying to align a series of images down the center of the screen.... it escapes me."  In this part of the web site, the client, using a custom cms, will add pages, add groups to those pages, and then assign/upload images to the groups. Due to the nature of the client's content, as you can see with the glass designs for entranceways, the imgs need to fall into place based on their width, so I choose to use nested divs, floating them left, this way the imgs will wrap appropriately. The only thing the client will need to be aware of is uploading the imgs in proper order, and make sure that, like in the case of entranceways, when there is one wide img at top of a group of pics that it is wide enough to make the next img wrap. The problem is that I can't get the divs to center in their container block because they are floated left. Regarding ColdFusion, I haven't seen the problems you mention. Else where in the site are database driven swfs - it's just quicker to develop with CFCs and Flash Remoting than to use ASP/PHP, but this is off topic.

GrandSchtroumpf - I will try the Inline Tables when I get home - currently at my day job, lol. This seems like the way to go, aslong as the tables wrap in the containing div, which I'm sure they will. Thanks. This is a great, simple approach.

I will let you all know how it works out.

Again, Thanks everyone.
tim

Martin, tables are NOT block-level elements.
And inline tables are part of the CSS2 table model "display: inline-table" (http://www.w3.org/TR/REC-CSS2/tables.html).
This means that there is no problem using a table as an inline element.
"display: inline-table" is the combination of "display: table" and "display: inline", and can be applied to any element.
But "display: inline-table" is not yet supported by neither IE nor mozilla, so, for now, we need to use a real table with "display: inline".
Since tables can contain block level elements, inline tables might be one exception to the holy rule that inline elements should not contain block elements...

In this particular case, the table cells don't need to contain block elements, but just an image and some plain text (I updated the code to remove the unnecessary div inside the inline table).  And the tables are not inside a, inline element.  So, i guess your arguments dont stand up.

Looking back at the code, I don't think my solution is a hack.
It's can be considered as a misuse of tables because the tables only contains one column...
If all the images were in one single row and all the comments in another row, that would definitely be tabular data.
Anyway, using tables like this will not influence the rest of the css layout.

I was looking for something like this to use on a site of mine.  I think it's nice to be able to add comments to the images.  But I did not want to use buggy hacky code to do that.
Since I don't see anything wrong with this solution,  I think I will use it myself.  <:°))

Any comment on whether or not this solution breaks the "good practice rules" is welcome.
A table as generated by an html table-tag is a block-level element 'display: table':
"table (In HTML: TABLE)
    Specifies that an element defines a block-level table: it is a rectangular block that participates in a block formatting context."
quoted from: http://www.w3.org/TR/CSS2/tables.html#q2
I know this quote does not describe that this particular rendering mode for table is not chosen, but I think we all know that, in normal circumstances, a table generates a block and does not allow another element besides it.

And altough I realise that the recommendation includes setting a tabel as inline-table to generate a replaced inline block, I'm also quite aware that Gecko and the MS rendering engines do not yet support these properties. You're suggested comment that 'there is no problem using a table as an inline element' is a trial-and-error conclusion that cannot, and should not, be derived from the specifications.

Setting a table to inline, even though it works, would still not make sense and break the rules, inline elements cannot, should not, are not allowed to contain block level elements. In case you wonder about your own comment that display: table and display: inline would combine into display: inline-table, my question is, what type of rendering do you get when you set a div to display: block and display: inline?

Setting it to inline-table or inline-block would allow for what your doing, inline-block being part of a working draft and inline-table still not in the rendering engines leaves both those avenues invalid, and theoretically what you came up with, should not work. However, it does, by only slightly breaking 'the rules' and would as such signify as a hack, which is not by definition a negative term and was not intended as such.

I don't want to discuss the rules of practice, as in the end the most clean solution to the answer, to me, allows breaking any bloody rule you can, as long as the question was reasonable.

 Martin
Great comment Martin.
It's this type of discussion that justifies the name of this site.

I'm just exposing my thoughts, and as the discussion evolves, i might contradict myself more than once.

The only thing i disagree with is the statement that tables are block-level elements.
From the specifications, i understand that tables can either be inline-level or block-level.
quote <<
  table (In HTML: TABLE) ... block-level table ...
  inline-table (In HTML: TABLE) ... inline-level table ...
>>
This shows that the html TABLE can either be mapped to "display: table" or to "display: inline-table".
The default being "display: table" for current browsers.

If a table can be inline-level, and still contain table rows and cells, this means that table rows and cells can be placed inside inline-level elements (at least in some cases).
And from the specification, table-row and table-cell seem to have no specified level at all.

In the beginning, i was quite sure the code was using invalid inline/block level nesting, but the more i think about it the more i beleive it does not...

Now, i must agree that we cannot expect that using an html table with "display: inline" will give the same result as using the table with "display: inline-table"...  In fact I would expect it more to display like a standard <span> and ignoring the <tr> and <td>.
And, for sure, the fact that current browsers supports it the way it does is only based on trial-and-error.
But isn't that the case for all code?

IMHO, the only hack is using "display: inline" instead of using "display: inline-table".
I usually consider that all changes to the display attributes are hacks, but in the case of a table, changing the display to "inline-table" does not lead to a wrong mapping (since both "table" and "inline-table" mappings are defined in the specs).
What do you all make of this? I implemented the Inline tables. Gave them a gray background so to see what's going on. They display fine in IE, but in Firefox, the imgs are where they should be, but looks like they are not even inside the table. Also in firefox, you have to refresh to get the page to display "correctly". Broken when first loads in FF. In some way I know this has to do with your discussion. Any ideas how to correct for Firefox?

http://www.kamermedia.com/agd/design-ideas/designPage.cfm?dpID=1

http://www.kamermedia.com/agd/design-ideas/designPage.cfm?dpID=2

Tim
The inline tables work fine on my side in FF.
Howerver what does not work at all is the footer that displays in the middle of the page.
Also, as I already said before, you should force your background color to white.

For the background color in Firefox, you need to set it on the <td> and not on the <table>.
Hmmm.... I take a day off the site and I almost miss a most interesting exploration of an interesting work around.

>>>But of course it breaks all the recommendations and good practice rules.
>>>I guess Cd& will be petrified if he ever sees this.

i'm not sure it does break from teh recommendations.  The tables are not be ing used for layout management; they have been constructed as standalone components, to use there default behaviour in a way that meets a deifficult requirement.  I keep recommending coponent based developemnt.  The issue with tables is that using then for layout management in against The W3C recommendations and best practice.

Now as to whether or not it is a hack.  It is no more of a hack I would say then using:
tag[atttribute] as a selector to hid things from IE,  Because inline-table is include in the standard, I'm not sure it is a hack to implement the behaviourin the absence of browse support.  The only thing I see as questionable is the block elements inside the inline-table.  

The standard should only allow inline and replaced elements within an inline table, and I think the expectation is that text inside of inline-tables would be a direct child text node; or that local behaviour control would be applied using spans.  However it creates an issue for form inputs which are relplaced elements because they are best managed with fieldsets (an important consieration for accessibility) which are block elements. As is stands tables whether they are inline or not must be able to contain block elements, else they become very limited as carriers for form data, and common form of the tabular data that tables are supposed to support.

On the whole I don't think there is a major deviations from standards because the tables are integrated as components; rather than doing the layout management.  If they were nested inside a primary table I would have an issue with them, but inside a content wrapper I don't see a problem.  I keep saying don't do eveything with divs.  Thre are a whole range of HTML elements with unique behaviours that are suitable for component building.  Why should tables be any different.  You can hold out for purity by insisting that table be used ONLY for tablular data; but then when we look at this page, are the image/text combinations not data?

Tables are complex and the wa they get used in component based development, is really a work in progress.  I think the solution we have here adds to the toolbox.


>>>but I see situations where CSS will simply NOT do what tables can do, in specific cases, despite the "standards body" recommendations..

It has nothing to do with what CSS can or cannot do.  It has nothing to do with what tables can or cannot do.  It is about taking a professional approach that supports user needs, accessibility, and forward as well as backward compatibility.  It does not matter what is convenient for the developer unless the pages are quick and dirty one offs. For sites with a future, you take the time to get it right and find solutions at the first opportunity, instead of have ing to patch, hack, and fix it everytime it needs a change.

CSS is definitely not about do it quick and push it out.  It is about do it right for the long term. That philosophy is becoming more common among developers and is one of the reasons that the the places where we deal with these issues (CSS, HTML, ane Web Dev, and growing faster than the average for TAs and all thre have move up several notches in the TA rankings based on total PAQ.

Cd&
Thanks for your comment Cd&.  Hope you had a good day of expert vacation.
This thread was very interesting.

<:°)
I do enjoy reading your well-versed opinions but I did feel the need to clarify my point of view in relation to some of the new posts:

@Grandschtroumpf
> This shows that the html TABLE can either be mapped to "display: table" or to "display: inline-table".
> The default being "display: table" for current browsers.

As you seem to agree with me that display: table is the default, then you must see that, by default, tables are block-level elements. IE's rendering engine could not change this for the world, but then IE luckily centers and align any block as if it were replaced inline anyways, no problems from that department.

> If a table can be inline-level, and still contain table rows and cells, this means that table rows and cells can be placed inside inline-level elements (at least in some cases).

This'd be true if a table could be inline, but the display: inline-table will make a table replaced inline. That's a whole different ballgame. An inline element can only contain other inline elements, a replaced inline element however renders like a block-level element and would allow other block-level elements in it's content block. The whole of that sum is then taken as if it were a single character, so to say, and placed as an inline entity. Officially gecko and IE do not support this yet, from what I've seen anyway. Unofficially you have proven that they do :)

> IMHO, the only hack is using "display: inline" instead of using "display: inline-table".

That, we completely, without question, agree on :)

As towards trial-and-error, I usually use it to prove a theoretical and complex possibilty to work in practice. You've applied it to show a theoretical impossibility to work in practice.

@Cd&
> i'm not sure it does break from teh recommendations.
Taking into account that adhering to the specification of html and css is part of the recommendations, and my case in trying to point out that setting a table to display: inline for this specific condition should, by those specifications, not work, I'd say that it does break from the recommendations.
But I repeat my earlier statement, any clean and simple solution justifies breaking any bloody rule ;)

@Cd& and @Grandschtroupf
I named it a hack, but I think I should also explain what my definition of a hack is :)
A hack, as I use the term and know it, is an unexpected solution to a complex or difficult dilemma.
Notice how this definition does not pass judgement on wether this is a discusting dirty piece of code, or rather a brilliantly simple solution. And as I've mentioned before, I did not intend it as a negative comment, I rather think that this is a rather elegant solution, I do however stop and wonder if it is prone to break in future rendering engines that listen more closely to the specified behaviour of the display property, as it stands, the code should not work, after all.

 Martin out, enjoying the rest of my weekend in stupified brainfunctionality ;)
Martin I use hack in much the same way you do, but it also carries a negative connotation, because the term is also commonly used to describe workarounds for security, and those are dirty, and illegal hacks that are not even permitted on the site.  I think at the level experts work at on this site that there is an understanding that that hack is not always bad.

As far as the speicifications; one of the problems is that a lot of web specs end up reverse defined.  W3C seems to spend half it s time trying to ammend specs so they match what the manufactures have decided to implement.  I am also am not an absolutist.  You do what you have to to solve a problem. When you can you do it withing standards even if it is extra work, but in the end you do what you have to do to solve the problem; and I don't think there is any professional in Web dev who would disagree with us on that.  Howeve some are too quick to abandon standards when it gets a little tough.

Cd&