W3C home > Mailing lists > Public > www-style@w3.org > June 2007

Re: Stylings only possible with Tables

From: James Elmore <James.Elmore@cox.net>
Date: Mon, 25 Jun 2007 13:45:11 -0700
Message-ID: <46802957.30303@cox.net>
To: www-style@w3.org



Spartanicus wrote:
> James Elmore <James.Elmore@cox.net> wrote:
> 
> 
>>Why not add simple layout to CSS / HTML and incrementally improve it, rather 
>>than trying to find the perfect solution of the perfect layout system which can 
>>cover all bases?
> 
> 
> We've long past the point where that would have been useful. As I said
> before we already have a simple mechanism that can be used to create a
> "layout", a HTML table can be used by those who want something that
> isn't perfect, it "works" as most people would define it.
> 
> 
>>That is what started my thoughts and suggestions for this 
>>thread. There are things which are possible only with tables, but they are VERY 
>>complicated to do. Why not allow designers to use some things which tables can 
>>do, but without the complete table requirements? Things like captions, 
>>margin-collapsing, border-overlap, constraints on the sizes of block sets, and 
>>simple extensions to current CSS display-models could help designers make better 
>>web sites and not demand too much in the way of rewriting every existing browser 
>>to contain the perfect layout system.
> 
> 
> I'm not following, you want the CSS WG to create a new simple layout
> system that needs to deal with /complicated/ issues such as the ones you
> mentioned above /and/ without having to rewrite browsers to support
> this?
> 
Sorry that I wasn't very clear. I find a trade-off exists between clear and 
wordy. Sorry, this time I seem to be wordy.

1. Philosophically, I object to combining multiple purposes in a single 
programming object. It makes the code difficult to maintain and the application 
difficult to use. Table elements are specified to contain arrays of data. They 
are also used, mostly because of their layout features (which are unavailable 
elsewhere in HTML/CSS) to position and size elements on pages, place borders 
around the objects, provide captions for the objects, and align objects so edges 
match up. Because I have had personal experience with the problems this split 
personality can cause, both to programmers and users, I would like to propose 
making the layout functionalities of tables available in CSS, without declaring 
any object which uses some of that functionality to be a table.

2. Layout features already exist (in tables) and could be used by designers to 
improve their web pages, provided that they didn't require all the complexities 
of tables to use. My list of these features includes: captions, margin-collapse 
controls, border-overlap controls, size controls for groups of blocks, and a 
simple grid-like layout.

3. These features are already coded. (Otherwise tables would not work.) Browsers 
already display captions (most of them correctly). Browsers already collapse 
margins (but do not allow designers control over that function). Browsers 
already overlap borders in tables. Browsers already enlarge/reduce blocks so 
their sizes match the rest of the row/column. Browsers already place elements in 
grids so things line up. It should be possible to separate these features from 
the <table> elements in HTML and make them available in CSS. This should not 
require rewriting every browser, just expanding the use of (and explicitly 
adding some features to) code which already exists. Separating the features into 
functions and making them available in elements other than tables should make 
the code simpler, not more complex.

4. For simplicity, designers should be able to use just some of these features, 
if they don't need all of them. Telling someone that they can declare objects to 
be "display: table" means that all the complexity of tables is still required, 
even if the designer only wants to overlap borders or align blocks on a grid.

5. Again, for simplicity, if the standard model of CSS specifies that text has 
certain properties, the users can understand those properties (or not use them). 
The fact that text in CSS has properties related to how it interacts with other 
text, like leading, indents, inline-block sizes, and so on is part of the 
standard CSS model for text. Except within tables, the same abilities (to 
specify how blocks interact with other blocks) can not be controlled in blocks. 
Margins between blocks are conceptually similar to leading between text lines, 
but the margin overlap is controlled by the browser, not the designer or the 
user. Designers should be able to understand these features more easily, if they 
are available (and explained) separately. If they are part of the 'magic' that 
happens when a table wraps around an object, they are harder to understand.



So, my proposal is to simplify the code, the use, and the understanding of the 
features which currently exist only in tables by making them available in other 
block objects. It may not be possible to allow these features in every block 
object, but limiting them only to table objects makes the code, the use, and the 
understanding harder. If it turns out to be too hard to implement some of these 
features, at least allow the rest for the sake of the developers, the designers, 
and the people who write the CSS documents.

Recognizing that design is a complex subject, I would like to simplify the 
coding of the browsers, the writing of the CSS specifications, and the jobs of 
the designers by providing a small, simple to understand and use set of features 
which already exist in tables, but make them available in most other block 
elements. These features have been overlooked in the past and are only available 
in tables, leading to extreme uses of table elements and complexity of web designs.

Pick one, or a few of my requests. Put them in the CSS specification. Have them 
implemented in actual browsers. Let people use them. If they are useful, the 
next generation of CSS specification writers will recognize their utility and 
can add more similar, simple features. If they are not useful, they can be 
deprecated, since the effort to specify, implement, and use them will be as 
small as possible.



I have tried (deliberately, but without much success) to keep this proposal 
separate from layout discussions. My recommendation is to provide some simple 
layout abilities -- a simple grid, or some 'frame' type horizontal and vertical 
blocks which could line up objects for designers. Because I recognize that 
layout is a complex and difficult subject, I would not like to see the rest of 
my proposal get lost simply because no one can decide the best type of layout to 
propose or implement.

 From my first reading (very quickly, probably not well understood) of the CSS 
Advanced Layouts specification, it seems that the proposed layouts will be 
difficult to implement. They are very different from any other layout system I 
have seen. This does not mean they are bad, only complicated. Coming to a 
consensus about layouts will be a long process, and then implementing them may 
take even longer. To get things moving, please specify some simple layout 
mechanism which will do at least some of what tables can do. Then the discussion 
will have some actual data points about difficulty of implementation, ease of 
use, practicality, etc. Perhaps actual information will make the next decisions 
simpler.



-- 
James Elmore
22162 Windward Way
Lake Forest, CA 92630
Home	(949) 830-9534
Email	James.Elmore@cox.net
Received on Monday, 25 June 2007 20:45:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:51 GMT