forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: Adding *.html matcher to xdocs
Date Sun, 13 Jul 2003 23:14:07 GMT
Nicola Ken Barozzi wrote:
> 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.  
> What?!?

So hold on; do you think that embedding HTML in doc-v11 is _not_ a 
violation of SoC?

> Then what do you call *.ehtml that *you* want to use as the default html 
> "rendering"?!?

The difference between ehtml and ihtml is that ehtml doesn't _pretend_ 
to be pure content.  There is no difference between ehtml and 
src/documentation/content/*.html, except that ehtml has menus added. 
Unlike ihtml, there is no illusion that you're editing anything other 
than HTML.  Forrest isn't going to quietly throw away half your page 
when it renders it, just because (unknown to you) it doesn't conform to 
some internal content model. ehtml can be validated.  ehtml is _honest_.

>> Even if it is useful, I don't think Forrest should go
>> there.  
> It already does. What do you call ehtml? Proper SOC?

Does allowing passed-through data break SoC?  I don't think so.  There 
is no confusion between what the user needs to do and what Forrest will do.

>> At least, not the CVS trunk -- you're welcome to fork a few files
>> off into a branch.
> eh?
>> 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

:) Okay, sorry, the Anakia comment was uncalled-for..

> 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:
> content/xdocs/*.html
> is treated as well-formed XML (hence in xdocs), and just has the menu and
> tabs added.
> "

Yep, that's *.ehtml.

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

So now it's "partial content"?  And what's the bit that's not content? 
Presentation. Ha!

If you no longer wish to argue that ihtml doesn't break SoC, I'd like to 
see your argument of how ehtml does.

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

I wasn't proposing to get rid of ihtml, merely countering your 
suggestion to get rid of ehtml and have just *.html.

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

Okay then, if you can further hack ihtml without touching other parts of 
Forrest (document2html.xsl), go ahead, I'll wash my hands of it.  Just 
please don't modify the DTD.  It wouldn't help anyway, since the 
embedded HTML would never validate.


View raw message