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

> They are in my mind two different beasts and should be treated as
> such. I find immense pain anytime I want to come up with a layout for
> CSS. I find it's just not very good at layout. But I attribute that to
> the mechanism for choosing properties and the box model.

There may be a market for this split, but it is such a radical leap
from CSS that it really is a new language.

> They do not think of them the same way. And the processes usually end
> up being separated. Layout can be done on a napkin - created in rough
> fashion and shown to a colleague. Presentation cannot.

Where there is a strong layout, they will probably decide on the content
last, and fit the content to the layout.  As well as conflicting with
the idea of HTML as a semantic structure language, it only really works
for a known rendering environment.  It's a continuance of old technology
in which the final rendering is fixed on paper before the user sees it.
It doesn't work well were the user can control media size, font size,
etc., etc.

> One of the key benefits of this separation beyond the tuning of the
> language towards the mental models of the users of that language is
> that the organization of space can be seen simply looking at the file.

Yes for a desktop publishing system producing final form output, but
not so obviously the case for extremely reflowable content.

> Language is used to communicate and the model the language presents to
> its user should match very closely the model the user uses themselves.

User in CSS normally represents the viewer.  Here you mean the graphic
designer.

> This is one of the core tenants of usability. Currently, I find that
> CSS layout doesn't accomplish this.

Usability issues for the designer can be handled by their authoring tools.
Usability in web terms normally refers to the consumer, not the producer.

> Tagged PDF isn't a solution to any problem in the web for so many
> other reasons. PDF is a source of frustration to a large number of
> people on the web. Fortunately it's primary problem - slow load times
> - seems to have been fixed in 7.

One of the reasons that PDF files are slow to download is that authoring
tools try to take too much control over the layout, i.e. they try
and produce too much pixel perfection.  If you compare the PDF from
PostScript generated by MS Word (or most other Windows programs) with
that generated by groff, you will see that the former is much bigger.
That's essentially because instead of output whole lines of text,
with possible spacing adjustment arrays, each character is output as
separately positioned graphic element.

> Another aside is the solution I proposed above doesn't break
> incremental rendering. Since the layout is specified beforehand, as

As I pointed out, you will get overflows or big gaps if you fix the
layout in sufficient detail for that before actually seeing the
content.

> As an aside if HTML were willing to actually promote the five largest
> div types to actual elements (a benefit being increased usability),

XHTML2 does add some of these and provides a role attribute for encoding
the others.  However, my take on this is that most of these components
are logically separate documents and should be linked to with 
link elements.  Unfortunately that won't happen, as it will remove the
ability to apply branding to the layout of such features if the browser
took responsibility.  It would be much more usable, though, as the 
browser would enforce consistency.

> As far as your coment about a specific page, the example presented
> before you would apply to all documents that use a particular layout
> and not just one. It would also allow for the easy separation of

The problem is that it only seems to allow the top level structure
to be defined as a pattern.  You can't, for example, define generic
rules for the structure of a document section or for a real (data)
table.

> To me it's just a simpler model that's easier to work with. The layout
> algorithm is easier to work with and it makes reading and writing
> layout code easier. If you noticed the excessive use the of the word
> easier, then maybe you'll get what I'm after.

Doing global layout is OK for desktop publishing, where the author sees
the result and fixes it into final form before distribution.  It is
a much more difficult problem when the layout needs to remain fluid
at the destination.

Received on Thursday, 30 June 2005 06:34:37 UTC