Re: [webkit-dev] Question on Inline element
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 e...@webkit.org 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.
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=leftSubscribe/p
/html
A slightly modified example:
style
p { border: 5px solid black; }
img { border: 2px solid red }
/style
pimg src=invalid.jpg alt=alt width=256 height=256
align=lefttext/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 e...@webkit.org 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
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
mustaf.h...@gmail.comwrote:
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 e...@webkit.org 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.
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=leftSubscribe/p
/html
A slightly modified example:
style
p { border: 5px solid black; }
img { border: 2px solid red }
/style
pimg src=invalid.jpg alt=alt width=256 height=256
align=lefttext/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 e...@webkit.org wrote:
On Thu, May 12, 2011 at 10:52 PM,
[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] 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
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 simon.fra...@apple.comwrote: 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?
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 simon.fra...@apple.com 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
[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] 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
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham bfulg...@webkit.org 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] Large Source Reorganizations By External WebKit Ports
Hi Peter, On Wed, May 18, 2011 at 2:09 PM, Peter Kasting pkast...@google.com 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 2:25 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi Peter, On Wed, May 18, 2011 at 2:09 PM, Peter Kasting pkast...@google.com 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
On Wed, May 18, 2011 at 2:35 PM, Ojan Vafai o...@chromium.org wrote: On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi Peter, On Wed, May 18, 2011 at 2:09 PM, Peter Kasting pkast...@google.com 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] 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 simon.fra...@apple.comwrote: 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 simon.fra...@apple.comwrote: 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] 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
[webkit-dev] Fwd: [whatwg] More HTML Editing Commands questions
Is this a bug? -- Forwarded message -- From: Boris Zbarsky bzbar...@mit.edu 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 Gregorsimetrical+...@gmail.com 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: !DOCTYPE html span style=border: 1px solid green; padding: 5px; background: yellow /span 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
