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.
-eric On Wed, May 18, 2011 at 12:35 AM, Mustafizur Rahaman <[email protected]>wrote: > 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. >> > > Hi Eric, > > 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. > > 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. > > 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. > > 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. > > So, ther root cause of the problem is when for float image, > positionNewFloatOnLine() is called, it has to appropriately set the > paragraph framerect. > > Thanks. > > On Tue, May 17, 2011 at 11:48 PM, Eric Seidel <[email protected]> wrote: > >> >> >> On Tue, May 17, 2011 at 4:12 AM, Mustafizur Rahaman < >> [email protected]> wrote: >> >>> Hi Eric, >>> >>> 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. >>> Am i correct? >>> >>> If that is so, as per my understanding the m_framerect of Renderblock >>> corresponding to Paragraph element will contain both the image & text >>> element. >>> Is this understanding correct? >>> >> >> From RenderBox.h: >> >> private: >> >> // The width/height of the contents + borders + padding. The x/y >> location is relative to our container (which is not always our parent). >> >> IntRect m_frameRect; >> >> So yes, I would expect that to include the rects of all kids, including >> the text and image. >> >> 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. >>> <html> >>> <head> >>> <style type="text/css"> >>> p.one >>> { >>> border-style:solid; >>> border-width:5px; >>> } >>> </style> >>> </head> >>> <p class="one"> <img src="titan.jpg" alt="RSS" width="256" border="0" >>> height="256" align="left">Subscribe</p> >>> </html> >> >> >> A slightly modified example: >> <style> >> p { border: 5px solid black; } >> img { border: 2px solid red } >> </style> >> <p><img src="invalid.jpg" alt="alt" width="256" height="256" >> align="left">text</p> >> >> >> 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. >> >> >>> >>> I have also debugged the WebKit code & found that while doing layout >>> calculation for Paragraph element, it goes inside >>> 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? >>> >> >> 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. >> >> As to where the height of a block is calculated? I would have to dig >> around, but I would start with methods like >> computeContentBoxLogicalHeight The height is going to be calculated as >> part of layout() through a series of setLogicalHeight(foo) calls I would >> imagine. >> >> >>> Thanks, >>> Rahaman >>> >>> On Fri, May 13, 2011 at 11:25 PM, Eric Seidel <[email protected]> wrote: >>> >>>> >>>> >>>> On Thu, May 12, 2011 at 10:52 PM, Mustafizur Rahaman < >>>> [email protected]> wrote: >>>> >>>>> So my question is >>>>> >>>>> - Can a paragraph element contain an image element=> the html spec >>>>> does not say NO. >>>>> >>>>> 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. >>>> >>>> >>>>> >>>>> - 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. >>>>> >>>>> Images will only end up getting wrapped in anonymous blocks when >>>> they're in a block with other box children. For example: >>>> >>>> <div><img><div></div></div> will cause the <img> to get wrapped in an >>>> anonymous block. >>>> >>>> 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. >>>> http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level >>>> >>>> >>>>> >>>>> >>>>> Can any one please throw some light here & help us out. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> [email protected] >>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>>> >>>>> >>>> >>> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
