I still don't understand the "problem" here?   The bug you mentioned was marked invalid.  As far as I can tell our current float behavior is correct.<div><br></div><div>-eric<br><br><div class="gmail_quote">On Wed, May 18, 2011 at 12:35 AM, Mustafizur Rahaman <span dir="ltr"><<a href="mailto:mustaf.here@gmail.com">mustaf.here@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex" class="gmail_quote">
You can see that the <img> overflows the paragraph in both Firefox
 and WebKit.  This seems to be caused by the align="left", which I 
believe implies the CSS style "float: left;".  I suspect that floats do 
not get counted towards the height of a block, but I'd have to check.  I
 suspect that if we cleared the float (adding something with 
style="float: clear") after the <img> we would see the p (block) 
expand so that the img did not overflow. <br></blockquote></div><div><br>Hi Eric,<br><br>You were right. If i make the example as style="float:none", now the paragraph area counts for the image area too & below is what I have debugged.<br>

<br>When image float=>Inside RenderBlock::layoutRunsAndFloats(), my BidiResolver contain the RenderObject for Img. Now when it searches for next line break, it finds that the float needs a separate line box (in RenderBlock::LineBreaker::skipLeadingWhitespace), therefore it calculates the layout for the img in positionNewFloatOnLine() & increment the resolver.<br>

<br>As a result when the calculation reaches in RenderBlock::createLineBoxesFromBidiRuns, the BidiRunList I have received from the resolver no more contain the image node, therefore the paragraph area calculation is only done based on the text it contains.<br>

<br>When Image in NOT float=>As per the above call flow, in RenderBlock::LineBreaker::skipLeadingWhitespace, it finds that it does not need a separate linebox for img render, therefore it does not increment the resolver. So, in RenderBlock::createLineBoxesFromBidiRuns() the BidiRunList contain all the children of the paragraph including the image & the text, as a result the paragraph area counts for the image area.<br>

<br>So, ther root cause of the problem is when for float image,  positionNewFloatOnLine() is called, it has to appropriately set the paragraph framerect.<br><br>Thanks.<br></div><div><div></div><div class="h5"><br><div class="gmail_quote">
On Tue, May 17, 2011 at 11:48 PM, Eric Seidel <span dir="ltr"><<a href="mailto:eric@webkit.org" target="_blank">eric@webkit.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div>On Tue, May 17, 2011 at 4:12 AM, Mustafizur Rahaman <span dir="ltr"><<a href="mailto:mustaf.here@gmail.com" target="_blank">mustaf.here@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Eric,<br><br>Thanks for your patient & detailed answer :-) So based on your explanation, I understand that a paragraph element can contain an image (inline) & text (inline) element altogether. <br>Am i correct?<br>



<br>If that is so, as per my understanding the m_framerect of Renderblock corresponding to Paragraph element will contain both the image & text element. <br>Is this understanding correct?<br></blockquote><div><br></div>


</div><div>From RenderBox.h:</div><div>







<p>private<span>:</span></p>
<p><span>    </span>// The width/height of the contents + borders + padding.  The x/y location is relative to our container (which is not always our parent).</p>
<p><span>    </span>IntRect<span> </span>m_frameRect<span>;</span></p></div><div> </div><div>So yes, I would expect that to include the rects of all kids, including the text and image.</div><div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wrote the below html to draw a border around the paragraph element, but the border is drawn around the text element only as can be seen in Safari browser too, which brings to the conclusion that the framerect calculation of paragraph element is not taking into consideration the children image element.<br>



<span style="color:rgb(0, 0, 153)"><html><br>
<head><br>
<style type="text/css"><br>
p.one<br>
{<br>
border-style:solid;<br>
border-width:5px;<br>
}<br>
</style><br>
</head><br>
<p class="one"> <img src="titan.jpg" alt="RSS" width="256" border="0" height="256" align="left">Subscribe</p><br>
</html></span></blockquote><div><br></div></div><div>A slightly modified example:</div><div><div><style></div><div>p { border: 5px solid black; }</div><div>img { border: 2px solid red }</div><div></style></div>


<div><p><img src="invalid.jpg" alt="alt" width="256" height="256" align="left">text</p></div></div><div><br></div><div><br></div><div>You can see that the <img> overflows the paragraph in both Firefox and WebKit.  This seems to be caused by the align="left", which I believe implies the CSS style "float: left;".  I suspect that floats do not get counted towards the height of a block, but I'd have to check.  I suspect that if we cleared the float (adding something with style="float: clear") after the <img> we would see the p (block) expand so that the img did not overflow. </div>

<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>I have also debugged the WebKit code & found that while doing layout calculation for Paragraph element, it goes inside<br>


RenderBlock::layoutInlineChildren==> Inside this we are doing the layout for each of the children. As per my understanding, the size of paragraph element would be the largest of its children & I dont see any such calculation. Could you please suggest where I should look to fix this issue appropriately?<br>


</blockquote><div><br></div></div><div>As far as I can tell, there is no issue to fix. :)  I suggest that you read the CSS 2.1 spec and this will all become much clearer.</div><div><br></div><div>As to where the height of a block is calculated? I would have to dig around, but I would start with methods like <span style="color:rgb(183, 16, 162);font-family:Menlo;font-size:11px">computeContentBoxLogicalHeight</span> The height is going to be calculated as part of layout() through a series of setLogicalHeight(foo) calls I would imagine.</div>

<div>








<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks,<br><font color="#888888">Rahaman</font><div><div></div><div><br><div class="gmail_quote">
On Fri, May 13, 2011 at 11:25 PM, Eric Seidel <span dir="ltr"><<a href="mailto:eric@webkit.org" target="_blank">eric@webkit.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div>On Thu, May 12, 2011 at 10:52 PM, Mustafizur Rahaman <span dir="ltr"><<a href="mailto:mustaf.here@gmail.com" target="_blank">mustaf.here@gmail.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">So my question is<br><ul><li>Can a paragraph element contain an image element=> the html spec does not say NO.</li></ul></div></blockquote></div><div>Yes.  There are two specs at play here.  HTML and CSS. Ignore anything prior to HTML5 as it was proscriptive rather than descriptive and does not match what browsers and web authors actually use!   <image> (aka <img>) is just an inline element.  (Like span or b or i, etc.) and flows with inline children per the CSS spec.  (See CSS 2.1).  So Paragraph, which is a block, can contain as many inline children as its little heart desires.  <img> happens to be a "replaced" element, so it has intrinsic size (again see CSS 2.1).  Inline children (with the exception of inline blocks, which are blocks which flow as inlines) CANNOT contain box children (blocks are boxes), so for example <span><p></p></span> would be invalid and cause a special type of craziness called a "continuation", where the spans inline contents are split in two, wrapped in anonymous blocks, and the two anonymous wrappers and the P are all children off the parent instead of the P being a child of the span.</div>



<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><ul><li>If we make the image element neither float/nor positioned, it creates an anomynous block & everything is rendered properly. But I am not sure whether that is the right approach.</li>




</ul></div></blockquote></div><div>Images will only end up getting wrapped in anonymous blocks when they're in a block with other box children.  For example:</div><div><br></div><div><div><img><div></div></div> will cause the <img> to get wrapped in an anonymous block.</div>




<div><br></div><div>This is due to he CSS rule that blocks may contain either all inline children OR all box/block children.  Thus since it has one block child (the <div>) the img has to get wrapped in an anymous block to keep with the rule.</div>




<div><a href="http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level" target="_blank">http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div class="gmail_quote"><ul>

</ul>Can any one please throw some light here & help us out.<br><br>Thanks.<br><br><br>

</div><br>
<br></div>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div><br>
</blockquote></div><br>
</div></div></blockquote></div></div><br>
</blockquote></div><br>
</div></div></blockquote></div><br></div>