[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: khtmlw bug with <li></li>
From:       Lars Knoll <knoll () mpi-hd ! mpg ! de>
Date:       1999-01-22 18:37:16
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]