[webkit-dev] Question on Inline element

Wed May 18 00:35:55 PDT 2011

>
> 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 <eric at webkit.org> wrote:

>
>
> On Tue, May 17, 2011 at 4:12 AM, Mustafizur Rahaman <mustaf.here at gmail.com
> > 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 <eric at webkit.org> wrote:
>>
>>>
>>>
>>> On Thu, May 12, 2011 at 10:52 PM, Mustafizur Rahaman <
>>> mustaf.here at gmail.com> 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
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110518/bba5bd8b/attachment.html>