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 Mon, 14 Jul 2003 07:27:24 GMT

Jeff Turner wrote, On 14/07/2003 1.14:

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

Not necessarily. If I embed a new but unknown content tag in my source, 
I'm not embedding presentation. The fact is that computers cannot see 
the difference between content and presentation, so this ability *could* 
make presentation pass. It all depends on the style, that can decide to 
be "pure" and reject all "dubious" content.

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

Well, neither ihtml does. If it did, it would validate and not even 
discard unknown tags, that are evidently not 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_.

So, it's a bigger SoC but it's 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.

So I don't see the difference between this sentence and using "asis"...

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

ok :-)

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

Content that is not in the DTD.

> Presentation. Ha!

Could be. The computer cannot see the difference. If the user wants to 
shoot himself in the foot and make those parts unrenderable in PDF it's 
his issue.

> 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 does not pass at all into the Document format, hence cannot be 
transformed into PDF or any other mean. ehtml is exactly like a 
hardwired <asis> just beloy <body>.

Basically I'm proposing a more fine-grained ehtml.

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

Well, ihtml itself has shortcomings, so I'd really like to see a unified 
html processing module.

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

Naaa, getting evangelical? ;-)

> Just 
> please don't modify the DTD.  It wouldn't help anyway, since the 
> embedded HTML would never validate.

Sure, I agree.

Let's strike a deal then: I modify ihtml to make it as I would like to 
see the unified html, then we see how it works and if it can be ok.


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

View raw message