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

Re: [CSS21] properties for table-column (In HTML: COL) & table-column-group (In HTML: COLGROUP) items.

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Thu, 30 Jun 2005 00:29:07 +0200
Message-ID: <42C320B3.2040309@students.cs.uu.nl>
To: Orion Adrian <orion.adrian@gmail.com>
Cc: www-style@w3.org

Orion Adrian wrote:

>>As I understand the CSS WG has likely heard solutions like this being
>>proposed many times, so in order not to have the same discussion again
>>every couple of months they just don't have it at all.
>>Anyways, if you want to propose a good solution, you must consider
>>things like how it will affect incremental rendering (a fundamental part
>>of CSS), etc... The independence of document order in this thing you
>>propose for example will make it not be incrementally renderable,
>>causing browsers performing very poorly when incrementally rendering
>>your webpage while loading because it needs to reflow all the time, or
>>just not rendering it at all until it's fully loaded. Without
>>independence of document order, it seems to be just like the table
>>display properties.
>Except it is incrementally renderable if the document was written in
>display order. It doesn't require reflow ever since it looks at the
>size of the viewport and not the size of the container. While what
>I've presented isn't laid out in the most descriptive way, the idea
>behind it was solid. It's something I've been thinking about off and
>on for months.
display: table with layout: fixed is incrementally renderable.

With regard the XML sublanguage you gave to change the document order: 
why not use XSLT? It gives you document order independance, and is 
already available right now in two major desktop browsers.

Problems: 1. browsers such as Opera refuse to implement XSLT for valid 
reasons. I also don’t see this happening on mobile browsers. 2. display: 
table is also not implemented widely yet (IE7, perhaps?). How would any 
new solution solve those problems?

>>I'm getting a bit tired of the 'the CSS WG is blind to solutions' or
>>'everything is fundamentally flawd'-like comments. That's not a
>>constructive way to work. There are technical reasons behind the limits
>>of CSS which can't just be waved away.
>I find that when people no longer want to work around the limits of a
>language, the core properties of that language may need to be
>rethought. There are multiple ways to accomplish the same task.
1. CSS is still in development. There are many things not in CSS 2.1, 
which is what you have to work with right now. There were more things in 
CSS 2.0 but browsers didn’t implement them, so they are not of any use.

2. CSS3 is still in development and far from finished. Of the CSS3 parts 
that are more or less finished, only Selectors is implemented on a 
somewhat broad scale.

Please do realise that anything that gets specified will take years 
before it is fully specified, implemented and has enough user coverage 
before you can use it. So it’s better to think things over thoroughly, 
instead of proposing quick job fixes.

>I'm not saying, nor have I ever said that everything was fundamentally
>flawed. Frankly I'm quite happy with 90% of the language, but the
>layout properties kill me. They also apparently cause other people
>some concern since the issues appear here every couple of weeks (in
>the form of calc, float, %%).
Bert Bos (CSS WG chair) wrote in a message to this list a while ago that 
they were thinking about some kind of grid layout.

See also:


(The latter link is also new to me, and looks interesting and more 
detailed :))

So your assumption that the CSS WG does not see the layout problems is 

Again, please note that any solution to this will only be available 
broadly in the long term. There isn’t anything specified yet, and as 
soon as it is it will have to receive input from various parties in the 
form of a number of WDs. Once it is mature enough to go to CR, it will 
still take years before browsers implement it, and more years before 
those new browser versions are used by enough people that you can 
actually depend on them.

Think of display: table. It has been specified (as a Recommendation) for 
seven years now, but still the major browser has not implemented it. 
Assume that IE7 will implement this, how many more years will it take 
before you can drop IE6 support? Inline-block, which would also be 
immensely useful, has a similar story.

So please realise that there is no short-term solution for this. And 
that as such quick fixes which aren’t thought out well aren’t really 
desireable, because as this is taking a long while anyway, and going to 
be around for a long time, it had better be done good.

>I find the CSS working group's lack of solutions to problems presented
>consistently to be frustrating.
They are (or were) currently focusing on completing CSS 2.1. Features 
such as that will never be introduced in that specification.

In the meantime, CSS3 is still in development, so those problems can and 
will be addressed.


Ushiko-san! Kimi wa doushite, Ushiko-san!!
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.
Received on Wednesday, 29 June 2005 22:29:15 GMT

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