forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Adding *.html matcher to xdocs
Date Sun, 13 Jul 2003 21:55:03 GMT

Jeff Turner wrote, On 12/07/2003 9.26:

> For me, separation between content and presentation is fundamental to
> Forrest.  There's no clearer violation of SoC than to embed HTML in a
> doc-v11 page.  


Then what do you call *.ehtml that *you* want to use as the default html 

> Even if it is useful, I don't think Forrest should go
> there.  

It already does. What do you call ehtml? Proper SOC?

> At least, not the CVS trunk -- you're welcome to fork a few files
> off into a branch.


> But really, if you absolutely *need* to use a HTML editor to generate
> content, I think a tool like Anakia is much more appropriate.  It lets
> you use any HTML you want, and IIRC has a PDF plugin somewhere.

Are you kidding me?!?

I think I'm having a bad dream! :-O

I'm talking about making Forrest more usable, also taking into account 
the fact that our users have a need we have to resolve, and that *you* 
had pointed out, and you are telling me now to use Anakia?!?

This is *your* mail, not mine:

You write:
Sometimes there is a HTML feature that you really need, that doc-v11
doesn't have.  Perhaps it's nested tables, or <p> inside <dt>, or a bit
of Javascript, or an applet, or a right-aligned image.. etc etc.

So I'd like to introduce behaviour where:


is treated as well-formed XML (hence in xdocs), and just has the menu and
tabs added.

Or this one:
Wait till one day when YOU want to include a <form> or applet in your
Forrest app ;)

What *I* replied was:
To be fair, I think it sucks. It's a big fat hole in our SOC.

I still stand to that. Making content pass unfiltered sucks.
*But* tagging some *partial* content so that the style can even decide 
to no render it at all, or decide how to, is IMHO a very fair and 
balanced way of managing the same need *you* talked about without the 
drawbacls of totally unfiltered tag-copy accross.

ehtml is the same thing as the solution you described in those mails. 
Funny enough, what you say about my proposal is the same thing I said 
about yours (albeit I had proposed a solution instead of offering you to 
use another system), and your current proposal is the same as the 
previous one.

Give me an alternative so that real users can use a decent editor to 
edit Forrest files, and so that we can surpass our DTD deficiencies in 
spacial cases like forms and such, or I'll have to deduce that you don't 
have a real alternative to propose and I'll keep pursuing mine.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message