[webkit-dev] Question on Inline element

Wed May 18 00:40:11 PDT 2011

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
<mustaf.here at gmail.com>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 <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/68890dce/attachment.html>