[webkit-dev] Fwd: [whatwg] More HTML Editing Commands questions
Is this a bug? -- Forwarded message -- From: Boris Zbarsky Date: Wed, May 18, 2011 at 7:32 PM Subject: Re: [whatwg] More HTML Editing Commands questions To: wha...@lists.whatwg.org On 5/18/11 6:57 PM, Tim Down wrote: > On 18 May 2011 19:32, Aryeh Gregor wrote: > >> Another argument against wrapping whitespace is that it can have an >>> >>> unwelcome visual effect if, for example, the wrapping elements have a >>> CSS border applied. >>> >> >> Borders only apply to boxes, and collapsed whitespace generates no >> boxes, so it will generate no border. Nor backgrounds, margins, >> padding, etc. >> > > That may be what the CSS spec says > The collapsed whitespace generates no box, but the inline element sure generates a box per spec. And that box can have padding, borders, margins, the works. Aryeh, I suggest actually trying this in your favorite browser. Just make sure to not use a WebKit-based one, since WebKit is buggy here. Any Presto, Trident, or Gecko-based browser should do the trick, on the other hand. Minimal testcase: That should give you a nice yellow box about 10px wide and 10px + (default font size) high with a green border around it. Note that the presence or absence of whitespace is completely irrelevant here; the rendering is the same if the whitespace is deleted except in WebKit, which suddenly renders like every other browser if you delete the whitespace. Buggy, like I said. I'm not sure why. DOM mutation events in their current form (i.e., >> synchronous) should work, no? And if the selection change event is >> not synchronous, you might not be able to use it anyway, because maybe >> by the time the handler runs all sorts of changes happened >> > That can happen even if it's synchronous. -Boris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EFL builder is sick
Hello Geoff, Thank you for your bug filing. I fixed it yesterday. Thanks, gyuyoung > Hi folks. > > The EFL builder is sick. > > I've filed https://bugs.webkit.org/show_bug.cgi?id=61018 explaining how to > fix it, but I'm just not familiar enough with the EFL build system to do > so myself. > > If there are any EFL experts out there, could you please have a look? > > Thanks, > Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
Done: https://bugs.webkit.org/show_bug.cgi?id=61096 On Wed, May 18, 2011 at 9:36 AM, Simon Fraser wrote: > The best way to move forward would be to file a bug requesting that the > prefixes be removed. > > Simon > > > On May 18, 2011, at 9:31 AM, Brady Duga wrote: > > Though, in this case, the spec is at CR and has been since 2009. Is there > an additional process to removing the vendor prefixes for WebKit? So, are > they still there because no one bothered to remove them, or because the > consensus is they should remain for some reason? > > --Brady > > On Wed, May 18, 2011 at 7:36 AM, Simon Fraser wrote: > >> On May 18, 2011, at 6:36 AM, Sabri Aurrelia wrote: >> >> > Why does webkit not provide support for native CSS3 attributes in its >> parsing engine where those attributes clearly coincide with most other >> browsers' attributes -and- the Candidate Recommendations set forth by W3? >> > >> > Let me put it this way: What is the purpose of every browser having >> their own nearly-identically named attributes that take the same arguments, >> which are also the same as the attributes set forth in the Candidate >> Recommendation? >> > >> > What makes -webkit-column-gap and -moz-column-gap and column-gap >> different from each other aside from the name, and if that's true, why is >> there even a name difference? >> > >> > Is it a waiting game? Or is it possible to take the initiative and >> adopt early the attributes recommended? Is there too much risk involved in >> early adoption even where there's already nearly complete consensus among >> vendors? >> >> Vendor prefixes remain on new properties until the draft spec that >> describes them reaches Candidate Recommendation status. >> >> A Google search for "CSS3 vendor prefix" will turn up lots of discussion >> on the www-style mailing list about this. >> >> Simon >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On Wed, May 18, 2011 at 2:35 PM, Ojan Vafai wrote: > On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham wrote: > >> Hi Peter, >> >> On Wed, May 18, 2011 at 2:09 PM, Peter Kasting >> wrote: >> >> Google used this same approach with their Chromium port, the side >> effects of >> >> which find us in year two (or three?) of the effort to merge those >> >> changes back into the core WebKit archive. >> > >> > Um, what? The Chromium port is fully upstreamed and has been for some >> time. >> > I'm not sure what you're saying here. We are not forked and in fact >> have >> > no support for building Chromium with anything other than upstream >> WebKit. >> >> I admit that statement was a bit hyperbolic; however the Chromium >> source base was significantly reorganized when it was a 'secret' >> project, and took a lot of time to get in sync. I'm wondering why >> Google, EA, and others have felt the need to do so. >> >> Note that there are still things that are not fully merged: e.g., >> FontPlatformData is still largely forked from the mainline >> implementation (e.g., arbitrarily different names for members). > > > AFAIK, Chromium didn't actively reorganize the source tree. The source tree > changed out from under us while we were still a private project. This is > just a natural side effect of not being part of the mainline source tree. > Stuff moves around (and it should!) as it makes sense to structure the files > differently. > > Chromium's tree not tracking the move is just oversight in some cases. > > Ojan > we also learned some lessons the hard way. i wish we had created a webkit API from day one, to help insulate webcore better from chrome. we did create a layer of insulation (called webkit/glue), but it was way too squishy and not kept clean. it was a bit painful to untangle that into a proper API. we also didn't go with a vendor branch approach in the beginning. instead, we maintained forked files in a mirror tree, which just did not scale as the number of forked files grew (due to V8 integration mainly). but yeah, things like the creation of FrameLoader really caused us to spin our wheels! ;-) -darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham wrote: > Hi Peter, > > On Wed, May 18, 2011 at 2:09 PM, Peter Kasting > wrote: > >> Google used this same approach with their Chromium port, the side > effects of > >> which find us in year two (or three?) of the effort to merge those > >> changes back into the core WebKit archive. > > > > Um, what? The Chromium port is fully upstreamed and has been for some > time. > > I'm not sure what you're saying here. We are not forked and in fact > have > > no support for building Chromium with anything other than upstream > WebKit. > > I admit that statement was a bit hyperbolic; however the Chromium > source base was significantly reorganized when it was a 'secret' > project, and took a lot of time to get in sync. I'm wondering why > Google, EA, and others have felt the need to do so. > > Note that there are still things that are not fully merged: e.g., > FontPlatformData is still largely forked from the mainline > implementation (e.g., arbitrarily different names for members). AFAIK, Chromium didn't actively reorganize the source tree. The source tree changed out from under us while we were still a private project. This is just a natural side effect of not being part of the mainline source tree. Stuff moves around (and it should!) as it makes sense to structure the files differently. Chromium's tree not tracking the move is just oversight in some cases. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
Hi Peter, On Wed, May 18, 2011 at 2:09 PM, Peter Kasting wrote: >> Google used this same approach with their Chromium port, the side effects of >> which find us in year two (or three?) of the effort to merge those >> changes back into the core WebKit archive. > > Um, what? The Chromium port is fully upstreamed and has been for some time. > I'm not sure what you're saying here. We are not forked and in fact have > no support for building Chromium with anything other than upstream WebKit. I admit that statement was a bit hyperbolic; however the Chromium source base was significantly reorganized when it was a 'secret' project, and took a lot of time to get in sync. I'm wondering why Google, EA, and others have felt the need to do so. Note that there are still things that are not fully merged: e.g., FontPlatformData is still largely forked from the mainline implementation (e.g., arbitrarily different names for members). -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham wrote: > Google > used this same approach with their Chromium port, the side effects of > which find us in year two (or three?) of the effort to merge those > changes back into the core WebKit archive. > Um, what? The Chromium port is fully upstreamed and has been for some time. I'm not sure what you're saying here. We are not forked and in fact have no support for building Chromium with anything other than upstream WebKit. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavascriptCore and Multiple Threads
Hi Martijn. > i selected JavascriptCore over the competition because i read that > it's thread safe. Yes, with certain restrictions, JavaScriptCore can be used concurrently on multiple threads. > but, i can't get it to work from within threads with crashing. It's hard to diagnose exactly what's going on without looking at your code, but I can give you these general guidelines: (1) A JSGlobalContextGroup roughly corresponds to a virtual machine or a process. Multiple JSGlobalContextGroups can run concurrently on separate OS threads. Data cannot be shared between JSGlobalContextGroups. (2) A JSGlobalContext belongs to a JSGlobalContextGroup, and roughly corresponds to a thread or module. Multiple JSGlobalContexts in the same JSGlobalContextGroup can shared data. Multiple JSGlobalContexts in the same JSGlobalContextGroup cannot run concurrently on separate OS threads, but can run with explicit locking on separate OS threads. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JavascriptCore and Multiple Threads
I hope i'm sending this mail to the right address, forgive me if i'm wrong..
i selected JavascriptCore over the competition because i read that
it's thread safe.
but, i can't get it to work from within threads with crashing.
the first version of my test was using one context, created with
JSGlobalContextCreateInGroup , and two threads calling
JSEvaluateScript
the first thread was evaluating this->
for(a = 0; a< 1; a++) {
print(a)
}
print is simply a function that calls printf.
the second thread was evaluating
for(b = 0; b< 1; b++) {
print(b)
}
i'm not even accessing the same variable, but it still crashes.
the second version of my test was using one context per thread, part
of the same group, and i got the same result, some ASSERT function
creating a BAD_ACCESS error.
i was really hoping that i could actually have multiple concurrent
scripts accessing the same objects, at the same time (you can never
predict what the developer of the scripts wants to do)
i tried both versions of my tests with boost threads, and with the
threading library built in JavascriptCore
so i can say i'm a bit disappointed !, what am i doing wrong ? or is
this just impossible ?
in that case, what's all that threading/ locking/ mutex etc code for ?
Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Large Source Reorganizations By External WebKit Ports
I've recently been spending some time reviewing some of the WebKit port that are not part of the core WebKit archive. Electronic Arts, for example, has been very good about making source dumps of their build of WebKit available (wow -- WebKit on the PS3! :), Playo has released their sources, and Valve was kind enough to point me at the version of Chromium they use for their own work. While this transparency is fantastic, I find it depressing that in most cases these porters chose to significantly rearrange the source archive. This makes it difficult to evaluate the changes made to support various custom features, as well as drastically increasing the effort required to integrate these ports into WebKit proper. Google used this same approach with their Chromium port, the side effects of which find us in year two (or three?) of the effort to merge those changes back into the core WebKit archive. This phenomenon makes me wonder if we have some sort of deficiency in the layout of the WebKit sources, or the way we specify and link with various external dependencies, that lead new porters to embark on these large reorganizations? I did not find it difficult to work with the existing WebKit layout -- in fact, I find it logical and easy to understand. And certainly several other ports (such as the Windows CE, wxWidgets, Haiku, BEOS, etc.) were able to easily integrate with the existing layout. However, the existence of these several source variations is a clear indication that not everyone finds the source base so easy to work with. Perhaps if we understood the reasoning behind that led to these external source reorganizations we could do a better job presenting suitable API's for porters so that they would not feel the need to take these drastic steps. Can any of you external users share the reasons behind your reorganization efforts? Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
The best way to move forward would be to file a bug requesting that the prefixes be removed. Simon On May 18, 2011, at 9:31 AM, Brady Duga wrote: > Though, in this case, the spec is at CR and has been since 2009. Is there an > additional process to removing the vendor prefixes for WebKit? So, are they > still there because no one bothered to remove them, or because the consensus > is they should remain for some reason? > > --Brady > > On Wed, May 18, 2011 at 7:36 AM, Simon Fraser wrote: > On May 18, 2011, at 6:36 AM, Sabri Aurrelia wrote: > > > Why does webkit not provide support for native CSS3 attributes in its > > parsing engine where those attributes clearly coincide with most other > > browsers' attributes -and- the Candidate Recommendations set forth by W3? > > > > Let me put it this way: What is the purpose of every browser having their > > own nearly-identically named attributes that take the same arguments, which > > are also the same as the attributes set forth in the Candidate > > Recommendation? > > > > What makes -webkit-column-gap and -moz-column-gap and column-gap different > > from each other aside from the name, and if that's true, why is there even > > a name difference? > > > > Is it a waiting game? Or is it possible to take the initiative and adopt > > early the attributes recommended? Is there too much risk involved in early > > adoption even where there's already nearly complete consensus among vendors? > > Vendor prefixes remain on new properties until the draft spec that describes > them reaches Candidate Recommendation status. > > A Google search for "CSS3 vendor prefix" will turn up lots of discussion on > the www-style mailing list about this. > > Simon > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
Though, in this case, the spec is at CR and has been since 2009. Is there an additional process to removing the vendor prefixes for WebKit? So, are they still there because no one bothered to remove them, or because the consensus is they should remain for some reason? --Brady On Wed, May 18, 2011 at 7:36 AM, Simon Fraser wrote: > On May 18, 2011, at 6:36 AM, Sabri Aurrelia wrote: > > > Why does webkit not provide support for native CSS3 attributes in its > parsing engine where those attributes clearly coincide with most other > browsers' attributes -and- the Candidate Recommendations set forth by W3? > > > > Let me put it this way: What is the purpose of every browser having > their own nearly-identically named attributes that take the same arguments, > which are also the same as the attributes set forth in the Candidate > Recommendation? > > > > What makes -webkit-column-gap and -moz-column-gap and column-gap > different from each other aside from the name, and if that's true, why is > there even a name difference? > > > > Is it a waiting game? Or is it possible to take the initiative and adopt > early the attributes recommended? Is there too much risk involved in early > adoption even where there's already nearly complete consensus among vendors? > > Vendor prefixes remain on new properties until the draft spec that > describes them reaches Candidate Recommendation status. > > A Google search for "CSS3 vendor prefix" will turn up lots of discussion on > the www-style mailing list about this. > > Simon > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
On May 18, 2011, at 6:36 AM, Sabri Aurrelia wrote: > Why does webkit not provide support for native CSS3 attributes in its parsing > engine where those attributes clearly coincide with most other browsers' > attributes -and- the Candidate Recommendations set forth by W3? > > Let me put it this way: What is the purpose of every browser having their > own nearly-identically named attributes that take the same arguments, which > are also the same as the attributes set forth in the Candidate Recommendation? > > What makes -webkit-column-gap and -moz-column-gap and column-gap different > from each other aside from the name, and if that's true, why is there even a > name difference? > > Is it a waiting game? Or is it possible to take the initiative and adopt > early the attributes recommended? Is there too much risk involved in early > adoption even where there's already nearly complete consensus among vendors? Vendor prefixes remain on new properties until the draft spec that describes them reaches Candidate Recommendation status. A Google search for "CSS3 vendor prefix" will turn up lots of discussion on the www-style mailing list about this. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
Why does webkit not provide support for native CSS3 attributes in its parsing engine where those attributes clearly coincide with most other browsers' attributes -and- the Candidate Recommendations set forth by W3? Let me put it this way: What is the purpose of every browser having their own nearly-identically named attributes that take the same arguments, which are also the same as the attributes set forth in the Candidate Recommendation? What makes -webkit-column-gap and -moz-column-gap and column-gap different from each other aside from the name, and if that's true, why is there even a name difference? Is it a waiting game? Or is it possible to take the initiative and adopt early the attributes recommended? Is there too much risk involved in early adoption even where there's already nearly complete consensus among vendors? --M.Pemrich Matthew A. Pemrich ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question on Inline element
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
wrote:
> You can see that the 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 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 wrote:
>
>>
>>
>> On Tue, May 17, 2011 at 4:12 AM, Mustafizur Rahaman <
>> mustaf.h...@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.
>>>
>>>
>>>
>>> p.one
>>> {
>>> border-style:solid;
>>> border-width:5px;
>>> }
>>>
>>>
>>> >> height="256" align="left">Subscribe
>>>
>>
>>
>> A slightly modified example:
>>
>> p { border: 5px solid black; }
>> img { border: 2px solid red }
>>
>> > align="left">text
>>
>>
>> You can see that the 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 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, 20
Re: [webkit-dev] Question on Inline element
>
> You can see that the 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 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 wrote:
>
>
> On Tue, May 17, 2011 at 4:12 AM, Mustafizur Rahaman > 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.
>>
>>
>>
>> p.one
>> {
>> border-style:solid;
>> border-width:5px;
>> }
>>
>>
>> > height="256" align="left">Subscribe
>>
>
>
> A slightly modified example:
>
> p { border: 5px solid black; }
> img { border: 2px solid red }
>
> align="left">text
>
>
> You can see that the 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 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 wrote:
>>
>>>
>>>
>>> On Thu, May 12, 2011 at 10:52 PM, Mustafizur Rahaman <
>>> mustaf.h...@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 rath
