Roedy Green wrote:
I think CSS column formatting is broken. I think it could be fixed
very simply by expanding the use of <colspan>.
No, this is because stuff happens at the wrong time. I've pointed you to
Hixie's post on the issue several times, but since you seem to not have
read it, I'll summarize for you.
First off, some background. CSS is based on a document format, so if it
can't be represented by the DOM (or, loosely, XML), it can't really be
done by CSS. I make this remark to hit one key point: an element cannot
have two parents.
CSS is also designed to be language-agnostic. That means that I should
be able to style an arbitrary XML file, instead of only HTML. Another
way to look at the issue is that a layout engine is an SGML parser that
has a default stylesheet with rules to specify how HTML works, at least
in terms of layout. So a <tableelement only acts that way because it
has "table { display: table; }".
The last thing to point out is this: CSS has a concept of inheritance.
For every element, every property is defined. If I don't have a (say)
color property, it's value then becomes inherited from its parent.
So we now parse the document. We get to a <td>. It has no color. So we
look at its parent, <tr>. It has no color. And we then look at its
parent, etc. Possibly we want to style from the column in this case, but
the column is not a parent of the cell. How can we possibly find it then?
I hear you muttering under your breath "you know what column it is in."
But you don't. Remember my second point? We don't know that because
we're at the end of the selector process. We need to know what the
element will look like before we start laying it out--the /computed
style/ of the element. To know the column from which to apply the
styles, we need to lay out the table, but we need to know the computed
style before then.
This "works" in IE because IE doesn't implement CSS correctly. It
doesn't do computed styles, which destroys a POWERFUL feature for one of
admittedly less use.
The four attributes that do work work because they're really special
containers. You can see them as a sort of ruling structure to put the
cells in the right place, so only things that affect the ruling work
(border puts a border along the rules, background puts a background that
could be covered up, width specifies the width of the rules, and
visibility: collapse hides the rules).
You'll see that the core problem here immediately relates back to the
fact that a cell /should/ have two parents, but the format it's
expressed in forbids this from happening.
There is one last thing to rebut: the idea of having some sort of "get
this attribute from the column" keyword value. Logically, this would
first do one thing: slow the layout dramatically, since you have to
crawl up stuff to find the column in which the cell is going to be
placed *and* its parental hierarchy. For every cell that has that
property. And, given developers, I think a lot of people will make this
true for all cells whether or not they need it. Which means this will
happen for every cell on every table on pages.
It would also break computed styles, since the style is being computed
at layout time and not parse time.
Sure, tables and CSS don't mix well. Part of that is because tables
don't work well in the DOM hierarchy. If you read the HTML spec, you'll
find that the only things that inherit there is alignment (the style
portion is overridden by CSS 2.1).
And it's <colgroup>, not <colspan:-)
<tr>...</tr>
<colspan<col class="behold"</colspan-- applies to rest body
<tr>...</tr>
Let me explain why this is bad.
First off, that implies that a <colgroupis "reset" by seeing another
one. You've just broken backwards compatibility big time there.
Second, colgroup is a group of columns. Keeping that in mind, that means
that the reset creates a new group of columns. Which means that you now
have new columns. Things like changing the width, etc., can now be
respecified, thereby making, effectively, a new table.
Complain to the W3C CSS list. Complain to the WHATWG list. I think
you'll find reception of these ideas among the spec-writers will be very
poor. Not because they're evil, but because it turns out to be
real-world impractical.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
