forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@wkwyw.net>
Subject Re: XHTML2 I have read it and I like it... GO READ IT!
Date Mon, 12 Aug 2002 08:23:51 GMT
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

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

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


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

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


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


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

Ross


Mime
View raw message