- From: James Elmore <James.Elmore@cox.net>
- Date: Fri, 01 Jun 2007 07:46:58 -0700
- To: www-style@w3.org
Yes! The point of my post was that tables can do (formatting) things which no other element type can. I included Daniel's subject because what he said started me thinking about the separation of formatting and data (supposedly part of the HTML / CSS specifications) and the fact that, in the case of tables, this separation is violated. Sorry if my example gave people the wrong impression. What Daniel was discussing (multiple inline blocks having the same sizes, if I remember correctly) is part of the problem / solution I am considering. Replacing tables as formatting objects with 'pure' CSS is another part. I would like to be able to align objects (as with tables), yes. But I would also like to have CSS set sizes for me on objects which are not part of tables. In general, I would like to be able to create a set of block objects anywhere on a web page and have CSS make them all the same size. Rather than my specifying an exact (unvarying) size, I would like to be able to have them change sizes based on (for example) the size of some parent's block or the window size. A practical example: Say that I want to use .jpg files inline at the start of each paragraph on my web page. The files may contain a fancy initial letter or may illustrate something else about the paragraph. The files are all more or less the same size, but not exactly. The UA can scale the display of the files automatically if I give it the sizes (width / height), and if I used a table (somehow) it could scale the images for me. I want to use CSS to make the images all the same size, but outside of a table. I'm sure there are plenty more examples, including Daniel's. (I will be glad to invent more, if needed. I'm trying to keep my post shorter than the first one. ;) Daniel Beardsmore wrote: > > James Craig wrote: > >> James Elmore wrote: >> >>> There is no other HTML / XHTML element which can automatically resize >>> contained elements (or their margins / padding) so the elements >>> appear all the same size. This ability is strictly formatting and >>> should logically be part of CSS. I would, therefore, like to propose >>> adding to CSS the ability to make sets of elements conform to a >>> common size. >> >> >> Hi James, apologies if I'm simplifying your request, but I think >> you're looking for the table display values defined in CSS 2: > > > I would like to see some clearer examples. Since he's taken my subject > line, then if he's failing to explain what I originally wrote then, no, > tables won't work at all. Nothing I wrote about could be solved by using > the table formatting model or a real table. > > Assuming the use of my subject line is a confusing decoy, then what he > originally wrote would appear to be doable with a table, and thus the > table formatting model. > > However, anyone who's used tables for mark-up will remember that they > were ungainly to use for layout and I don't seriously suggest people > using display: table to attempt to lay out a page. It would also tie you > into a left-to-right, row-by-row mapping of physical to logical layout, > whereas a good layout mechanism would allow you to distance the logical > (rendered, 2D) layout from the physical (1D HTML) layout. > > My own nested, cell-based layout allowed for pretty simple page content > division and the ability to slot multiple successive items from the page > into the layout cells. I forget whether I mentioned it on this list ... > to me, it seemed nicer than the CSS3 attempt to tackle page layout -- > more flexible, easier to specify and understand. > > None of this has got anything to do with adaptive size determination. My > very first example of this on this list was to show the creation of a > fluid grid which is something that a table can *not* be used for, and > PRECISELY why I was introducing a different concept to layout than > tables. Tables cannot handle this case. > > -- James Elmore 22162 Windward Way Lake Forest, CA 92630 Home (949) 830-9534 Email James.Elmore@cox.net
Received on Friday, 1 June 2007 14:47:23 UTC