Need for CSS to overcome Table-based formatting, Need for CSS to simulate all HTML format-based elements,, My proposal for CSS frames, My proposals for new :empty pseudo-class, My new display: types, New replace: property, New :empty-column pseudo-element, New children variable(!)

CSS should do the following: 
1. be able to simulate any format-based HTML element
(i.e., FRAME, IMG, etc.), 
2. be able to collapse HTML hacks such as TABLE into
css-based formatting.

1. 

A. There is a need for a replace property. For
example, DIV#banner {replace: url(banner.gif);}. This
would allow replacement of the contents of any
element, allowing simulation of OBJECT elements, etc.

B. There is a need for a CSS frame syntax.
Consider:

<div class="z">
<div class="frm1">
<div class="frm2">
</div>

DIV.z {display: frameset;
frame-type: columns;
frame-boundary: noresize}

DIV.frm1 {display: frame;
width: 50%;
replace: url(menu.htm);
background-color: red;
border-top-style: inset;
overflow: scroll
}

3 new display types are needed: frameset, frame and
iframe. Plus a frame-type property, taking the values
columns and rows. The frame-boundary takes the values
resize (initial) and noresize.

I like the idea of being able to apply style directly
to frames. The only problem is people putting other
pages in their frames and giving them their own
styles.

Therefore, I propose a frame-styles-allow property.
This could take the values yes and no. Clearly yes
would have to be the initial value, otherwise you
would have to give all the frame document's a style
sheet, obviating the advantages of having this
flexible method.

A modification to the cascade would also be
necessitated, giving replaced content style sheets
greater weight than the replacer, even for inherited
values.

2. CSS needs to be able to collapse old TABLE
formatting techniques. These are mainly used for
columns and for margins. This flexibility would allows
old HTML formatting to coexist with flexible CSS box
model properties.

To remove HTML margins you could have:

TABLE[border="0"] {display: block}
TABLE[border="0"] TD:first-child:empty {display: none}
TABLE[border="0"] TD:last-child:empty {display: none}

Note the need for an :empty pseudo-class. The problem
with this example, is that there are situations when
the :empty TD that is a first or last child is in a
borderless TABLE. These rules could cause problems
with column alignment on genuine TABLEs.

Therefore, what we really need is an empty column
pseudo-element. Thus :empty-column {display: none}.

This seems to remove all problems. The only difficulty
is that the UA has to wait for the whole table to load
before it can see whether a column is empty, but this
is really an issue for the designer, not for the W3C.

The issue of reducing TABLE column formatting to CSS
is rather more vexed.

Consider:

<table border="0">
<tr>
<td valign="top">
This is a column
</td>
<td valign="top">
This is another column.
</td>
</tr>
</table>

If we have TABLE {display: block} TR {columns: ?},
then there is no way of knowing the number TDs in the
row.

We couldn't use a counter function on the TDs for the
following reasons: 
1. CSS doesn't allow the value of counter functions to
be referred to;  
2. Even if it did, the performance problems would be
prohibitive - the row couldn't be rendered because
there would be no way for the UA to know whether the
counter was incremented later on.

The only possible thing we could do is introduce a
children variable.

E.g, TR {columns: children}

I think this would solve a lot of the problems caused
by the fact that columns, surely a core function, were
not even introduced in CSS-2, never mind CSS-1,
meaning that columns MUST be done by TABLEs, which
don't work properly - different resolutions, fonts,
even browsers, cause massive gaps at the bottom of
columns, meaning that the need for a way to collapse
TABLE formatting techniques without a rewrite of
millions of pages is overwhelming.




=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Received on Monday, 18 October 1999 12:30:46 UTC