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]
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.
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"
etc.
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 ;-)
Ross
[1] http://www.w3.org/TR/xhtml2/mod-core.html#adef_core_class
