forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Re: [Proposal] Rules for Forrest Use of class-Attributes
Date Fri, 06 Jan 2006 19:40:54 GMT

Ross Gardler wrote:

>> Function of class-Attributes
>> ----------------------------
>> Forrest components (and users) use "class"-attributes in 4 different
>> ways:
>> 1. Forrest uses class-attributes to preserve special meanings when
>>    transforming custom grammer (such as xdocs) to html.

> My interpretation of our use of class attributes in this context is 
> different. We are not preserving "special meaning" we are conveying 
> hints about how the output should be styled. The meaning at this point
> is completely irrelevant.

Hmmm. Maybe I need to be more precise.

Let's say we get to the point where xhtml will be our common internal
format and all input must be transformed to xhtml before being transformed
into the different output formats.

- btw. this ties into our debate about the smartslides-plugin -

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

Perhaps this is not needed to created Webpages or pdfs, but what about
output plugins like slidy that need to know the meaning.

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?

> 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'm confused. Am I missing something?

>> 2. Skinning uses class-attributes to identify, format and place skin specific
>>    (often generated) components such as menus and tabs.

> If you are referring to the *rendering* of the output then this 
> statement is correct. If you are referring to the XDoc structure this is
> not true since there is not necessarily a direct correlation between 
> XDoc structure and page structure (this is especially true in the 
> Dispatcher work).

Well skinning does the job of rendering it.
To be more precise: I'm referring to the process of creating the part
of a page that contains the menu items and tabs and uses a standard
set of classes to allow all the skins to format it.

>> 3. Users add class-attributes to elements to create new meanings or
>>    add 'submeanings' to existing elements and facilitate formatting of
>>    those with the Extra-CSS-mechnism.
>>    Example: By adding a class 'instructions' to a simple bulleted list
>>             I can format these lists differently with extra-css.   

> Same comment as for 1 - the class attribute is a hint for styling not an
> indication of meaning.

I disagree. The instruction class that I added to howto's some time
ago is meaning that is deliberately carried all the way to the final
html so that different skins can interpret that meaning whichever way
they see fit.

But perhaps I'm still missing your point. Can you help?

> I accept that in both case (1 and 3) it can be misused to convey meaning
> but that is just plain wrong. Users wishing to convey *meaning* should
> use an appropriate source format.

Again: why misuse? I'm missing something here.

>> 4. Plugins (often) need to use class-attributes (just like Forrest in
>>    2) to carry meaning over to html.

> I can think of no example of this that is any different from the above
> cases, do you have something in mind?

No, it is the same issue. Plugins just make it more problematic
because each one may add they own set of new meanings.

> Remember
> 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.

>> - all transformations (including those in skinning and plugins)
>>   must preserve foreign class attributes. That is: Any class attributes
>>   attached to an element going into the transformation must be carried
>>   over into the resulting element.

> +1 - ion fact, as far as I am aware this has already been agreed, it's
> just that nobody has sat down and fixed each transformation by hand. 
> Instead we have been adding them as we find they are a problem.

Sure. I was just trying to summarize all the rules in one document.

>> - 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.


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.

>> - To avoid conflicts between class names created by different modules,
>>   a module-specific prefix is added to the class name. For Forrest core
>>   modules and extra-css-classes this prefix can be static while each new
>>   plugin should be automatically assigned a unique prefix to use with
>>   all their class names.

> Yes. Many moons ago we agreed to make all Forrest defined class 
> attributes conform to a naming convention, i.e. have a "forrest-" 
> prefix. We should actually do this, and Ferdinand is right, this is the
> time to do it.

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.

> 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 think the naming thing needs exploring with some example snippets of
> output. That way we should be able to see if there is a benefit or not.

Sure. It was really just an example to illustrate that I'd like to
have short prefixes to keep overhead small and keep things separate
with prefixes to avoid conflicts.

> 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 have no idea how all this will be effected by structurer. Can one of
>> the insiders please comment.

> I don't think it is affected. The problem is greatly reduced in the 
> Dispatcher, and it will also be easier to implement your guidelines, but
> the overall observations still stand since most of the contracts have 
> been extracted from existing skins.

That's what I was hoping for.

> I think w should focus on sorting this out in the Dispatcher. There's 
> little point in doing it in skins, unless someone has a pressing 
> *urgent* need for it in skins.

This will also give us enough time to discuss this.
Thanks for your comments.

Ferdinand Soethe

View raw message