forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: XHTML2 I have read it and I like it... GO READ IT!
Date Mon, 12 Aug 2002 08:43:39 GMT

Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
>> Ross Gardler wrote:
>>>>     h                 title
>>> This is not an equivalence. We can only have one title and it is 
>>> clear where that title should go and how it is used. A heading is a 
>>> different thing altogether, As Bruno Dumon has already pointed out, 
>>> this causes problems with numbering (or does it - I confess to not 
>>> having read the recomendation)
>> I guess it doesn't. Subsequent headers on the same level get 
>> progressive numbers. I don't see the problem.
> This will give us numbering, but not the numbering I would expect. When 
> I author documents I expect the sections to be numbered, not some 
> relatively arbitrary text I can drop in almost anywhere. However, lets 
> see how this works:
> <section>
>  <p>A para</p>
>  <h>A header/title</h>
>  <p>Another para</p>
>  <section>
>    <p>A para in the embedded section</p>
>    <h>The header/title of the embedded section</h>
>  </section>
>  <h>Another header/title</h>
>  <p>And yet another para</p>
> </section>
> Would become, something like:
> A para
> 1. A header/title
>  Another para
>  A para in the embedded section
>    1.1. The header/title of the embedded section
> 2. Another header/title
>   And yet another para
> Note how the embedded para is not clearly in the embedded section. Sure 
> we could indent it to give:
> A para
> 1. A header/title
>  Another para
>    A para in the embedded section
>    1.1. The header/title of the embedded section
> 2. Another header/title
>   And yet another para

This is what would come out, yes.

> But this still isn't what I get if I have a title available.

Hmmm, in fact this seems more like a liability than a feature...

I think that in the next they revision they would probably change it 
because of this thing, so I would be +1 if we decide that the "h" tag 
should be the first tag after the "section" tag.
We can block or issue a warning, either is fine for me.

>> Besides, having an element in a single possible position is usually 
>> bad seen by users, because they move it inside the body and don't 
>> understand where it should go.
> I can see this as an argument for having a <h> element but not for 
> removing the <title> element. The title can only be in one place becasue 
> it is only applicable in one place. Now if <section> has a title 
> attribute... (are we going round in circles now?)

In XHTML every tag has a possible title element, but it works more as an 
"alt" one IIUC.

As I said, it's fine if we make "h" behave like our "title" tag.

>>>>     kbd               * (needed, currently we misuse "code" instead)
>>>>     line              br
>>> Is this what is replacing the deprecated br element? If so what other 
>>> implications does this have?
>> Yes, it replaces it.
>> No issues I know of, just
>> a <br/> b
>> becomes
>> <line>a</line><line>b</line>
> OK. I prefer this and would propose the same for our DTD regardless of 
> the decision on XHTML2. I never did like <br/> it just doesn't behave 
> like all the other elements.


>>>>     p                 p
>>>>     |                 fixme   (with class attribute)
>>>>     |                 note    (with class attribute)
>>>>     |                 warning (with class attribute)
>>> So how do I do this:
>>> <fixme author="rdg">Stop reading email so late on a Sunday night</fixme>
>>> I would be tempted to add an optinal author attribute to all elements 
>>> as, for my purposes this would be useful, but now I am talking about 
>>> changing the XHTML DTD and I can;t do that. At least with Document 
>>> V1.1 I have a voice if I ever feel the need toargue the case.
>>>>   XHTML Linking Module
>>>>     link element      book.xml
>>> How does this affect the libre effort?
>> It redefines it a bit.
>> Here each page has its own navigation links potentially, so IMHO we 
>> could decide that a certain page of a directory has its links always 
>> present on the left, and the other ones of the pages get added.
>> We gotta discuss this thing, and could maybe decide to not use them 
>> (it's a separate module), but anyway they are there if we an them.
> OK, well I'll leave that for those who know about Libre then.
>>>>     Metainformation Module
>>>>      meta             abstract (never used)
>>>>      |                authors
>>>>      |                person
>>>>      |                subtitle (never used)
>>>>      |                type     (never used)
>>>>      |                version
>>>>      |                notice   (never used)
>>>>    XHTML Object Module
>>>>      object           img
>>>>      |                icon   (never used)
>>>>      |                figure (never used)
>>> Most of the items you say are never used are used here. I am not 
>>> precious about how the info gets in there though, as long as I don't 
>>> lose any expressiveness. For example, can I still but inline markup 
>>> in an abstract if it is in the XHTML meta format?
>> I dunno, but it depends on what you define as an abstract.
>> Usually it's a brief summary of the book, and IMHO doesn't/shouldn't 
>> need markup.
> I define an abstract in the same way but don;t agree that it doesn't 
> need markup. I need to put references, emphasis, bold etc in my abstracts.

References are separate meta entities.
As for emphasis, it's usually not needed, and when I read abstract, from 
for example medical veterinary stuff (my soon-to-be wife :-) I see only 
plain text.

>> Anyway I've never seen it used, so I guess that simple text for it 
>> would really be enough.
> Yes, that is a good point I use it becasue it is there but there is 
> nothing to stop me using a <div class="abstract">

Yes, although the meta abstract is more for machine indexing 
consumption, while your <div class="abstract"> is part of the page.

Since current abstract tag is in the header, I would assume the first case.

>>>>  XHTML Presentation Module
>>>>      hr               *
>>>>      sub              sub
>>>>      sup              sup
>>> I don't agree this should be in the DTD. This is presentation stuff 
>>> and should be in the CSS.
>> hr has a semantical meaning, but we can as well disregerd it in the 
>> skins.
> It does, but it is superceded (in my view) by setions.

>> As or sup and sub, we already have them, and in some languages they 
>> are part of the words (content), not presentation.
>>>>> Presentation markup was already deprecated in HTML 4 (= 1998), so 
>>>>> that's
>>>>> not that new.
>>>> But now it's removed, it's *very* different.
>>> Still some bits slipped through. I've not read the whole spec but in 
>>> your list of tags above there is a section that you have titled 
>>> "XHTML Presentation Module", surely that is presentation!
>> Three tags, two of which we already have?!?
>> :-P
>>>>> I think it would be best for forrest to become 
>>>>> documenttype-independent.
>>>>> Thus it should be possible to define documenttype-specific pipelines.
>>>>> (which of course raises the question of how to identify the type of a
>>>>> document, but that's another matter).
>>>> Sorry, but I strongly dissent.
>>>> That's *Cocoon*, not Forrest.
>>> I agree, and if you really want to you can use Forrest with different 
>>> DTD's anyway, of course this means a maintenance overhead but that's 
>>> the choice you take.
>> Yes, and let me precise a thing.
>> Forrest DTD has always been a very light semantical markup.
>> It's more a meta-markup than a very strict one.
>> The idea is that Forrest can be enhanced with other pipelines and DTDs 
>> that are then transformed to Document-dtd for reading or skinning.
> And thereby allowing other DTD's to be used. For example, for those who 
> don;t know Centipede, it takes the output from a number of other apps 
> (such as JUnit), converts this output to the forrest DTD and then 
> processes as normal. No problems with using an alien DTD there.

Exactly :-)
You know what I mean, since I just broke what you did on Centipede for 
this ;-)
Anyway this is the goal :-)

>>>> Think that we will have XHTML2 editors!
>>>> *This* is a major help for our users.
>>> Now if these editors are configurable so that they only allow the 
>>> tags we allow then this is a *big* argument for adopting XHTML2, at 
>>> least in my mind.
>> I don't know it the editors will be as configurable as the DTD, and in 
>> the start maybe they will not be, but if the user just uses these tags 
>> (which are 98% of what usually is used) it would be no problem.
>>> So how does this "adopting modules" work? Do we have to adopt every 
>>> tag in a module, or can we select on an element by element basis?
>> IIUC we should take all tags, but it doesn't seem like a problem to 
>> me, seen the above comparison table.
> So did the above table include all the elements in each of the modules 
> you listed? 

Yes. Some XHTML2 modules are missing, but for the listed ones they are 
all the tags.
Oh, I forgot the Edit Module, which defines

  del - deleted content, ie deprecated
  ins - newly inserted content, to be approved

These would play very nicely with a CMS.

Here is the list of all the modules, with * on the ones we would use:

N/A  1. Introduction
N/A  2. Terms and Definitions
N/A  3. Conformance Definition
N/A  4. The XHTML 2.0 Document Type
N/A  5. Module Definition Conventions
   *  6. XHTML Attribute Collections
   *  6. XHTML Attribute Collections
   *  7. XHTML Structure Module
   *  8. XHTML Text Module
   *  9. XHTML Hypertext Module
   * 10. XHTML List Module
     11. XHTML Bi-directional Text Module
     12. XHTML Client-Side Image Map Module
   * 13. XHTML Edit Module
   * 14. XHTML Linking Module
   * 15. XHTML Metainformation Module
   * 16. XHTML Object Module
   * 17. XHTML Presentation Module
     18. XHTML Scripting Module
     19. XHTML Server-Side Image Map Module
N/A 20. XHTML Style Sheet Module
   * 21. XHTML Tables Module
   * 22. XHTML Target Module

As you see, it's pretty all there, and 11, 12, 19 could get inside later 
maybe, if we will find a need.

> Sorry I know I should read the recomendation but I'm lazy 
> and I'm sure I'm not the only one on this list ;-)

Hey, it's really easy to read, honest ;-)

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

View raw message