forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [Proposal] Rules for Forrest Use of class-Attributes
Date Mon, 09 Jan 2006 12:32:19 GMT
Ferdinand Soethe wrote:
> Ross Gardler wrote:


> How will I be able to supply meaning like "this is a chapter of
> slides" other then using class?

There is no need to describe the *meaning* you are only describing 
rendering hints. Forrest is an XML publishing engine, nothing more, all 
it does is render stuff, it does not manipulate it any further than 
adding decoration and stripping unwanted information, therefore there is 
no need for context in the intermediate format, only for 
rendering/publishing hints.

The confusion lies in the fact that we, as humans, think of it as 
meaning because it has meaning to us, and we naturally pick class names 
that are meaningful to a human. However, they could just as easily be 
"A1", "A2", "A3" etc. Forrest would still do its job correctly.


> Or - looking from a different angle - how can that one and only class
> serve as a hint for so different outputs as pdf, html, voice?

(see below next section for a reply - trying to keep the thread focused)

>>If a user needs to maintain the contextual information then they should
>>use the original source XML.
> Which was exactly what I had intended to do with Smartlides when you
> argued that all data had to go through the common format.

I still argue that common data should go through the intermediate format 
whenever they need to be *rendered*. It is not necessary to maintain 
context when rendering since there is no *explicit* context in the final 
output document. There is plenty of implicit context, for example, 
headings are larger than paragraphs,  but there is no explicit context 
(at least not explicit to a machine).

Of course, Forrest is built on Cocoon and has a plugin framework. It is 
easy to extend Forrest so that you can do additional processing of the 
original source, but in this instance you are building a webapp and 
Forrest is only the publishing part of that webapp.

[now back to the CSS stuff from above the previous section]

>>XDoc is our intermediate format, it is not intended for human consumption.
> I understand that. But I think that software like out-plugins might
> have even more need to know meaning than humans.
> For example: The slidy transformations need to know where the chapters
> of a presentation are in order to process them correctly. A formatting
> hint like ("make this a big heading") would be useless.

Formatting hints do not have a meaning attached to them. It is up to the 
renderer to decide what that hint means. So your example of "make this a 
big heading" is not a hint, that is an instruction. A "big_heading" hint 
could be interpreted as:

"make this 120% the size of other headings"
"make this bold"
"say this at 120% volume of other text"
"create a new page and centre this text"


The slidy plugin only needs to know what is a chapter in order to render 
it in a particulatr way, so class="chapter" is sufficient, XSL can be 
used to add further rules. If this really does not work for your use 
case (and every 6 months or so someone claims it doesn't) please provide 
a concrete use case with an input XML snippet and a desired output XHTML 
(or whatever) snippet and I'll show you the intermediate representation. 
If I fail to do so then I'll concede the point ;-)

>>>- When adding classes to elements that already have a class attribute,
>>>  each new class it added to a space separated list. All
>>>  transformations and css-formatting must be written to properly handle such
>>>  class-lists.
> +1
> This is one important part. I might have missed the outcome of the
> debate on having more that one class-name in a class-attribute.

It is safe to go ahead. The final rendering engine can choose to ignore 
hints it does not understand.

> One reason to come up with the prefix-scheme was to avoid long
> prefixed like "forrest-" in the future. While I'm usually much in
> favour of speaking names, here I would strongly object because we
> would really increase the overhead of each page when we carry long
> class-names in every generated element.

So use "for-" instead ;-)

>>I'm not at all sure of the benefits of using the expanded name prefixes
>>you define below. It just seems complex. Particularly when we remember
>>that classes in, for example, the tabs may be reused in the body.
> Seems to me like one more reason to have prefixes. Why would you have
> the same class name for two very differnt parts of a page?

I meant that "for-highlight" might appear in the tabs and in the body 
but is still the same hint in both locations. In your example names you 
had things like "for-tabs-*" and "for-body-*", I interpreted this to 
mean my hightligh class would become two hints with identical CSS meanings.

However, you are saying that it may have a different meaning in the tabs 
as to the body. I don't think this is not a problem though, CSS allows 
you do define different definitions depending on where the class is found.

Thorsten has already done some work on CSS naming conventions (long time 
ago now). I'd suggest scouring the archives and seeing what he 
suggested. My vague recollections are that it was quite similar to your 
proposal here. Things will have changed a bit because we now have the 
dispatcher (which incorporates many of those original ideas).

>>Actually *all* elements in XDoc allow a class, so we this is already
>>covered by your desire to carry over all classes.
> Well, not really. Because in these indirect translations there are a
> number of different ways to make a class go into the body class in the
> end. And to keep things kompatible (especially with plugins) it would
> really help to document the way we want it to be.
> For example: If our transformations support a direct translation form
> xdoc-body to html-body, we should make that clear because the
> transformations inbetween will be rather hard to follow.

I'm not following you here. I agree to documentation being needed 
though, perhaps I will follow then ;-)



View raw message