From kfm-devel  Fri Jan 22 18:37:16 1999
From: Lars Knoll <knoll () mpi-hd ! mpg ! de>
Date: Fri, 22 Jan 1999 18:37:16 +0000
To: kfm-devel
Subject: Re: khtmlw bug with <li></li>
X-MARC-Message: https://marc.info/?l=kfm-devel&m=91902935106151

On Fri, 22 Jan 1999, Waldo Bastian wrote:
>David Faure wrote:
>> 
>> > I have kfm and kfmw. :)
>> :)
>> 
>> > My guess is that an extra vspace_inserted=true somewhere could help..
>> Lars' commit did that.
>> and
>> @@ -3327,7 +3327,8 @@ void KHTMLWidget::parseH( HTMLClueV *_cl
>>                         }
>>                 }
>>                 // Start a new flow box
>> -               newFlow(_clue);
>> +               if(!flow)
>> +                   newFlow(_clue);
>> 
>>                 flow->setHAlign( align );
>
>Doesn't this bring you into trouble when you already have flow?
>I mean... you call flow->setHAlign( align) which will also affect
>that part of the flow which is above the header.

Short excerpt from the code:
		vspace_inserted = insertVSpace( _clue, vspace_inserted );
		HTMLClue::HAlign align = divAlign;

		.... parsing of attributes cutted

		// Start a new flow box
		if(!flow)
		    newFlow(_clue);

		flow->setHAlign( align );

I don't think it'll make any problems. vspace_inserted is usually false, if you
already started filling the flow (e.g. with text). So insertVSpace will create
a new flow anyway. The newFlow is only needed in case we have
vspace_inserted=true && flow == 0. I anyway tried it with quite some pages, and
couldn't find any problems with headers.

>
>I would think that the right solution would be not to create
>a flow explicitly during the handling of "<li>". 
I don't know. The <li> handling is quite tricky. If you don't create a flow
there, I think it'll get appended to the wrong clue (the parent of flow is not
_clue after a <li> tag...) I think we'd run into quite some problems if we try
that. We should change all that stuff in khtml...

>
>On a related note: Is it really necassery for <Hx> to make the 
>flow? Can't it just do "flow=0"? When it is actually needed, a
>flow will be created anyway. You might need to set divHAlign
>for that and restore it in the popBlock.
That might be possible. But I don't have the time to try it now. Let's see, if
the present solution works, or if anybody complains. 

Cheers,
Lars