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

On 6/29/05, David Woolley <david@djwhome.demon.co.uk> wrote:
> 
> >
> > <layout>
> >     <vblock>
> >         <item src="body div.header" />
> 
> What you have here is a relative of XSLT, not so much of CSS, although
> it uses CSS selectors instead of XPATH.  It is a new style sheet
> language.
> 
> Actually, it isn't really a style sheet language, as it doesn't seem
> to allow general rules to be defined, whereas a true style sheet
> encapsulates a house style policy, not the rendering of a particular
> document.
> 
> An alternative, which to me better fits the way that commercial
> web pages are designed, is the tagged PDF model, where the primary
> document is explicitly rendering oriented, and the parallel document
> that selects bits of the primary document is the structural document
> (tagged PDF inlines the structural information where the structure
> doesn't conflict with the rendering).  (However, I think that a document
> with real content should always be designed first for structure.)
> 
> One does have to ask the question as to why XSL is a low priority
> for browsers.  I suspect that answer is that the minimum useful XSLT
> "style sheet" is much bigger, and more mathematical, than the mininal
> CSS styling (especially given that you can (though shouldn't) simulate
> (deprecated) font elements with span and inline styles.
> 
> Other reasons are that XSL is not intended for incremental rendering
> or dynamic re-rendering.
> 
> > 6) Content can be presented in a different order than it is in source.
> 
> One of the main features of XSLT and why this language is a relative.
> 

XSLT, of which I am a fan is a translation language. It isn't really a
styling language despite the name. It's also not well suited for the
problem I'd like to solve and is incredibly heavy.

I've been thinking about layout in CSS for a year or so now and every
time I come back to the same thing.

Layout is separate from presentation and is about the usage of space.
Presentation is about attractiveness and readability.

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.

Working with designers and making observations in the field, I find
that most designers focus on space usage first and then play around
with margin, padding, borders, fonts and colors.

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.

Margin, borders and paddings aren't layout. They are fine being left
in the presentation portion, but display, float and clear need to be
removed from the current CSS system and be given their own system.

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.

Language is used to communicate and the model the language presents to
its user should match very closely the model the user uses themselves.
This is one of the core tenants of usability. Currently, I find that
CSS layout doesn't accomplish this.

I would love CSS to use a subset of XPath expressions, but I'm not
going to get that and it's besides the point. I used CSS selectors in
my example because I didn't want to get into the XPath debate.

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.

Another aside is the solution I proposed above doesn't break
incremental rendering. Since the layout is specified beforehand, as
you download the document you simply render the pieces you have. Some
blocks may appear before other blocks, but that's alright.

As an aside if HTML were willing to actually promote the five largest
div types to actual elements (a benefit being increased usability),
the order of those elements could be specified to match closely to the
order they appear in most documents and incremental rendering would
work even better. Those elements are header, navigation, content,
sidebar, footer.

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
layout and presenation which opens up nice possibilities like they use
in http://my.msn.com where users can customize the location of
elements.

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.

Orion Adrian

Received on Thursday, 30 June 2005 04:20:42 UTC