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 Tue, 08 Jul 2003 14:58:37 GMT

Jeff Turner wrote, On 08/07/2003 14.46:

> On Tue, Jul 08, 2003 at 02:10:02PM +0200, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote, On 08/07/2003 12.41:
>>>If anything, I propose we get rid of *.ihtml and rename *.ehtml to
>>>*.html, since:
>>>- ihtml has been broken for most of 0.5's development
>>>- I don't think many (any?) people use it
>>>- masquerading our nice semantic doc-v12 as HTML seems like a bad idea
>>>  to begin with, because users have no idea what they *can't* put in
>>>  ihtml.
>>This last point is interesting... it declares the problems of using an
>>othogonal format (more in some areas, less in other) as a base format.
> I'd say it implies that our source formats should never be more general
> than our intermediate format.

Yup. Which brings me to this: what about adding a <div/> -like tag to 
all tags that our intermediary format now doesn't recognize?

It would mean: "I don't know the *meaning* of it, but here is what they 
are saying".

>>We can decide to fail if there is not correct content BTW.
> Write a DTD for our HTML subset?  That would work, although...

No need for a DTD. It's html, not XHTML...

>>Why do I need to have html files?
>>First of all, I want to use a decent editor for the docs. Html has 
>>gazillions of editors, and also the docs would be automatically 
>>human-readable as-is, from source format, with a browser.
> All those gazillions of editors don't know that they should be using the
> tiny subset of HTML that Forrest accepts, making them worse than useless.

Why worse? As long as the user knows what it will get... the upside is 
that whatever style stuff the editor inserts, it comes out all with the 
same appearance. :-)

> That's a good argument for allowing ehtml, though.

Hmmm, I don't think so. We can simply decide that we *recognize* some 
tag semantics, and don't recognize others. The unrecognized ones would 
still be given to the skin that can decide what to do. @see the above 
proposal for it.

>>The second reason is because of getting ready to xhtml2. But that's xml, 
>>so we can easily validate that.
>>After other thinking, the "ehtml" feature is not only for html. What's 
>>this "feature"? Content pass-through. Yes, I know I was against it 
>>(IIRC?) and that IIRC I said it was a big fat hole in the content 
>>separation, but it's damn useful if used right, and it's not a hole. 
>>Skins can still decide to bypass it! It's not something that Cocoon 
>>de-facto pushes through, it's something that skins can decide to work 
>>with. We can make mistakes, can we? ;-)
> Like, adding rowspan attributes to HTML tables?  

Errr, nope, not what I thought about. It's more like adding javascript 
code or templates that use non-html tags (@see Ken's initial rants about 
making tags pass for server post-processing), or simply adding form tags 
that are not in our DTD.

Basically the html file would be treated as an *.ihtml file *except* for 
the places that we would mark with <asis/>, that will be treated as *.ehtml.

> Yes it's useful, but I
> don't think we should make a virtue out of it.  It points to a deficiency
> elsewhere in Forrest that we'll eventually fix (by allowing XHTML2
> content).

This is meant as a partial step to XHTML2 in fact. And XHTML2 will not 
fix these things. We will still need semantical class attributes for 
things like "warning" or "note".

>>Imagine a <asis></asis> tag that makes everything pass through. It could

>>be used for all formats, and in html it could be a <div class=asis/> tag.
> <off-topic>
> Class tags would be _really_ handy.  We'd get all the benefits of CSS
> with regular doc-v11, without sacrificing SoC.

I agree. @see my mails about switching to XHTML2 as a base format.

> Though, in the long term it would be nice if doc-v11 didn't go the way of
> HTML, where practically everything becomes <div> or <span> with a custom
> class.  Why have <p class="foo"> when you could just have <foo>?
> </off-topic>

IMHO it's not OT, as the decision on this side will make it evident how 
we would tackle the ihtml-ehtml issue.

Rethinking about what has been said, I see that there is a need for 
making it possible for generic tag and non-validating info to pass. How 
is done is to be decided.

And this comes back to what I have written above about making all 
unrecognized tags into div-class ones (or something like that.).

  <myspecialtag/>  ->   <tag name="myspecialtag"/>

What you instead propose is:

  <myspecialtag/>  ->   <myspecialtag/>

Cocoon becomes a sitemesh-like decorator-pattern system in this case.

Hmmm... so Cocoon *could* let unrecognized tags pass or block them, but 
it's not compulsory to do one or the other. I mean, IIUC, if we let 
Cocoon be able to include any xml content, the decision of what to let 
pass and how to show it would be only of the stylesheets.
"Give it stuff and the skins will let you do what you want"

But what about validation? Relax?
What about content-type-aware pipelines? Namespace-aware pipelines?
What about keeping skins compatible?

Why would you not like having a tag that describes unrecognized tags or 
as-is content? Validation would be trivial, and we are still 
content-type aware. On the downside it's less nice and simple than 
letting tags pass. As you say:

 > Why have <p class="foo"> when you could just have <foo>?

Still thinking, but I smell FS...

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

View raw message