[osis-core] <p>

[Troy A. Griffitts]

Patrick,
	No problems.  Your, and Todd's, suggestion about using a milestone is good.


PS.  What ever happened to the empty element milestone approach for some 
tags?  At one time we were going to leave it to consider for a future 
version; recently, we talked about still adding it for elements like 
<q>.  No problems either way, but was just wondering if it got included 
for any tag.  I still think that <q mStart=... /> is cooler and easier 
to process than <milestone type=q... />, namely because (I think Harry 
originally pointed this out) as a renderer of OSIS, I've most likely set 
up code to already process <q> elements, and probably don't even care if 
it's a milestone or container.


	-Troy.



Patrick Durusau wrote:
> Troy,
> 
> Troy A. Griffitts wrote:
> 
>> Would you hate me if I asked for the ability to have and empty <p>?
> 
> 
> Won't hate you! Do wonder why your use case requires <p />?
> 
>>
>> use case:  I'm marking up a fragment that has a paragraph break, but I 
>> don't want to (know the) bound either above or below.  It would be 
>> useful to at least have a <p />.
>>
> Is this one of those "formatting/display" things I keep hearing about? ;-)
> 
> Where does this leave you if there is some other break? Quotation, page, 
> column, etc.?
> 
> My suggestion would be to use <milestone type="pBreak"> so you can 
> consistenly have cBreak (for columns), pbBreak (for pages), etc. Seems 
> like it would be better to have a common solution to the breaking 
> problem that you could plan on being used rather than having the empty 
> <p>. I know that is what has been used in HTML for years for 
> formatting/display, but it was bad practice then (even when I have done 
> it) and time has not improved my opinion of it.
> 
> Do you see any downsides to using the <milestone> as indicated? I was 
> thinking you would have to treat <p /> as a special case from the usual 
> <p> some text </p> anyway so I was thinking using the milestone would 
> not create any extra effort.
> 
> Patrick
>