Re: The style agenda

Bert Bos writes:

 > I expect that eventually the style language will be specified in an
 > RFC. I'm willing to help write it and I hope Hakon is. It will not be
 > the same as any of the current proposals, but my expectation is that
 > it will be recognizably a descendant of Hakon's ideas. I also think
 > that we should wait and watch this mailing list for a few weeks,
 > before commiting any resources to this effort.

Agree. People with diverging ideas whould speak up.

 > One example of such an (unwanted, IMHO) dependency is the fact that
 > Hakon's style language currently presupposes the existence of an
 > attribute CLASS, because that's what the notation `H1.punk' means. To
 > fix this, I proposed a global declaration `@archform CLASS', to be
 > inserted at the start of the style sheet, so that applications would
 > now what the dot stands for.

This is where it starts to get hairy and perl-like. Myself, I enjoy
writing perl, but I would prefer the style sheet language to be a bit
more intuitive. "@archform" isn't.

 >  |       available only up to a certain fixed depth, so that a fixed amount of
 >  |       space can be reserved for this information in the stack frame.
 >  |
 >  |is a concept that will come back and bite you.  I might need to know 
 >  |any arbitrary parent element to format an element in context correctly.
 > I wanted to restrict the amount of memory needed and also to simplify
 > the implementation. The idea is that you do not need the whole SGML
 > *tree*, but only a *stack* of currently open elements, plus for each
 > open element the GI (and only the GI) of its elder sister. The depth
 > of the stack is not limited.

Sounds reasonable, but you may need more that a fixed amount, no? This
is also why I dropped the idea of being able to combine hierarchical
and sequential search patterns.

 >  |You admit that your model is insufficient for tables; why shouldn't
 >  |we discard it, and what is Hakon's formatting model (it isn't obvious
 >  |from his TOC)?  what mods to DSSSL's model have the DSSSL-Light folks
 >  |determined necessary?  your model has among its five areas header and
 >  |footer; is this enough special-purpose-online-presentational areas?
 >  |won't somebody be asking for "left-margin-banner" and "wrap-around-
 >  |the-whole-frame-banner" soon?
 > Excellent idea. Let's talk about this for a while. I'm not happy with
 > that model either. Maybe the page model should be parametrized, maybe
 > we need something different altogether.

Grids! Let the style sheet carve up the canvas into golden rectangles,
and use an expert system to lay out the elements!! Ok, drop the expert
system and define a set of simple rules that we hardcode.. whoops! But
grids do look nice!


Hakon W Lie, WWW project CERN, CH-1211 Geneva 23