contentWidth of a table row & rendering data
Hello, This is a plea for help. I have a project for which I need to get the rendered outline of a DOM element. For my purposes, using the DOM offsetWidth and offsetHeight, combined with the offsetLeft and offsetTop (with the offsetParent's coords) gives me what I need in most cases. However, when dealing with <tr> elements, it appears as though WebKit is returning a value of zero in all cases. I have two questions: 1. How difficult would it be to calculate the offsetWidth and offsetHeight for the <tr> element, given that it currently does not work? 2. Is there a better / more efficient way to get the rendered outline (box) of a DOM node? My current code falls a bit short in some situations -- <td> cells don't always extend all the way to their cell edge, inline elements that start near the end of the line and contain a soft break appear to be a single block extending off of the screen, that sort of thing. If there's a better way to go about this, please let me know. Stephen Deken stephen.deken@gmail.com
Hi Stephen, Are you using shipping Safari, or a WebKit nightly, to do your testing? http://nightly.webkit.org/ Dave On Jan 16, 2007, at 7:20 AM, Stephen Deken wrote:
Hello,
This is a plea for help.
I have a project for which I need to get the rendered outline of a DOM element. For my purposes, using the DOM offsetWidth and offsetHeight, combined with the offsetLeft and offsetTop (with the offsetParent's coords) gives me what I need in most cases. However, when dealing with <tr> elements, it appears as though WebKit is returning a value of zero in all cases.
I have two questions:
1. How difficult would it be to calculate the offsetWidth and offsetHeight for the <tr> element, given that it currently does not work? 2. Is there a better / more efficient way to get the rendered outline (box) of a DOM node?
My current code falls a bit short in some situations -- <td> cells don't always extend all the way to their cell edge, inline elements that start near the end of the line and contain a soft break appear to be a single block extending off of the screen, that sort of thing.
If there's a better way to go about this, please let me know.
Stephen Deken stephen.deken@gmail.com
Are you using shipping Safari, or a WebKit nightly, to do your testing?
I'm using shipping Safari in 10.4.8 with all patches applied. Does the nightly not have this issue? I'll look into linking in the nightly tonight to see if it corrects my issue. Is there any other way to get the box (or boxes) for the rendered nodes? I'm using elementAtPoint: to get the DOMNode under the cursor and highlight it. The highlighting itself is done by posing as WebHTMLView and overriding drawRect:, and there's probably a better way to do that. -- Stephen Deken stephen.deken@gmail.com
I'll look into linking in the nightly tonight to see if it corrects my issue.
Is there any other way to get the box (or boxes) for the rendered nodes? I'm using elementAtPoint: to get the DOMNode under the cursor and highlight it.
The nightly webkit appears to solve this issue, and actually does me one better -- the web inspector tool gets the (sometimes disjoint) render boxes that outline the selected node. If the web inspector does it, it stands to reason that I can do it too. Any kind souls care to point me in the direction of the web inspector code in trunk, before I go off spelunking? Many thanks, Stephen Deken stephen.deken@gmail.com
On 17/01/2007, at 11:28 AM, Stephen Deken wrote:
The nightly webkit appears to solve this issue, and actually does me one better -- the web inspector tool gets the (sometimes disjoint) render boxes that outline the selected node. If the web inspector does it, it stands to reason that I can do it too.
Any kind souls care to point me in the direction of the web inspector code in trunk, before I go off spelunking?
I believe the code relevant to determining where to draw the highlight outline is at <http://trac.webkit.org/projects/webkit/ browser/trunk/WebKit/WebInspector/WebInspector.m#L554>. Cheers, -- Mark Rowe <http://bdash.net.nz/>
On Jan 16, 2007, at 6:34 PM, Mark Rowe wrote:
I believe the code relevant to determining where to draw the highlight outline is at <http://trac.webkit.org/projects/webkit/ browser/trunk/WebKit/WebInspector/WebInspector.m#L554>.
Beautiful, that's exactly what I needed. Now my dilemma is this. My understanding of the situation is that I can't ship WebKit.framework with my application. But my application won't work correctly unless it has the latest version of WebKit.framework. When were these changes introduced? Will they be included in Leopard? Will they be included in the next rev of Safari for Tiger? Many thanks, Stephen Deken stephen.deken@gmail.com
There is nothing that says you can't ship your own copy of WebKit (legal or otherwise)! OmniWeb does just that. You just have to weigh the consequences, the most obvious of which is that if Apple ships an update to WebKit (security fix or bug fix), your application won't take advantage of that since it's using it's own internal copy. See Bug 12199 Comment #3 for my *speculation* on what *may* happen when Apple ships Leopard. http://bugs.webkit.org/show_bug.cgi?id=12199#c3 Dave On Jan 17, 2007, at 7:35 AM, Stephen Deken wrote:
On Jan 16, 2007, at 6:34 PM, Mark Rowe wrote:
I believe the code relevant to determining where to draw the highlight outline is at <http://trac.webkit.org/projects/webkit/ browser/trunk/WebKit/WebInspector/WebInspector.m#L554>.
Beautiful, that's exactly what I needed.
Now my dilemma is this. My understanding of the situation is that I can't ship WebKit.framework with my application. But my application won't work correctly unless it has the latest version of WebKit.framework.
When were these changes introduced? Will they be included in Leopard? Will they be included in the next rev of Safari for Tiger?
Many thanks,
Stephen Deken stephen.deken@gmail.com
On 1/17/07, David D. Kilzer <ddkilzer@kilzer.net> wrote:
There is nothing that says you can't ship your own copy of WebKit (legal or otherwise)! OmniWeb does just that.
Strange -- I'd read some discussion (apparently from 2004) which indicated the WebKit framework was not licensed for distribution: http://lists.apple.com/archives/webkitsdk-dev/2004/Mar/msg00038.html If this has changed since then, great! I love it when the solution gets handed to me. :) Now my only problem is that XCode really, really wants to link against the WebKit in /System/Library/Frameworks instead of my private copy. Something is wonky with my linker settings, and I wasn't able to discern exactly what it was in the few minutes I had this morning. I wound up just setting DYLD_FRAMEWORK_PATH and WEBKIT_UNSET_DYLD_FRAMEWORK_PATH to get it working, but obviously this won't work when shipping.
You just have to weigh the consequences, the most obvious of which is that if Apple ships an update to WebKit (security fix or bug fix), your application won't take advantage of that since it's using it's own internal copy.
That's not such a large problem if I can eventually use the shipping version. If your speculation bears fruit, this is all moot anyway, since we won't be shipping until after Leopard debuts. Many thanks, David and Mark, for all your help. -- Stephen Deken stephen.deken@gmail.com
Hi Stephen, On 18/01/2007, at 3:03 AM, Stephen Deken wrote:
On 1/17/07, David D. Kilzer <ddkilzer@kilzer.net> wrote:
There is nothing that says you can't ship your own copy of WebKit (legal or otherwise)! OmniWeb does just that.
Strange -- I'd read some discussion (apparently from 2004) which indicated the WebKit framework was not licensed for distribution:
http://lists.apple.com/archives/webkitsdk-dev/2004/Mar/msg00038.html
If this has changed since then, great! I love it when the solution gets handed to me. :)
The email you reference was written prior to WebKit being open- sourced. At that time you would have required Apple's consent to redistribute the framework. Now that it is open-source, it is permissible to do so. I'm aware of several applications that bundle custom versions of WebKit -- OmniWeb and Sandvox being the most recognized of that group.
Now my only problem is that XCode really, really wants to link against the WebKit in /System/Library/Frameworks instead of my private copy. Something is wonky with my linker settings, and I wasn't able to discern exactly what it was in the few minutes I had this morning. I wound up just setting DYLD_FRAMEWORK_PATH and WEBKIT_UNSET_DYLD_FRAMEWORK_PATH to get it working, but obviously this won't work when shipping.
How are you specifying which framework to link against? I believe you'll need to either add the directory containing {WebKit,WebCore,JavaScriptCore}.framework to Xcode's framework search path, or change the framework references to use absolute pathnames. If you're building using an SDK you may have slightly more issues, as I encountered some difficulty in making Xcode cooperate when doing this recently. Cheers, Mark Rowe
The email you reference was written prior to WebKit being open-sourced.
Ah, of course.
How are you specifying which framework to link against?
I'm specifying my WebKitBuild/Release directory in my Framework Search Paths, and I'm copying the frameworks into my app bundle's Frameworks directory. I'm also specifying @executable_path/../ Frameworks so that the frameworks can be found at runtime. otool -L reports that I'm getting my handbuilt copies of WebCore, JavaScriptGlue, and JavaScriptCore -- only WebKit is pointing to the / System version. That suggests to me that it's a precedence issue, but moving my WebKitBuild/Release path before the 10.4u.sdk path results in a build error (unable to find class names for WebHTMLView, WebView, etc). So I'm sort of at a loss as to what the problem is. Probably the same SDK issues you referred to. -- Stephen Deken stephen.deken@gmail.com
On 18/01/2007, at 11:10 AM, Stephen Deken wrote:
How are you specifying which framework to link against?
I'm specifying my WebKitBuild/Release directory in my Framework Search Paths, and I'm copying the frameworks into my app bundle's Frameworks directory. I'm also specifying @executable_path/../ Frameworks so that the frameworks can be found at runtime.
otool -L reports that I'm getting my handbuilt copies of WebCore, JavaScriptGlue, and JavaScriptCore -- only WebKit is pointing to the /System version.
That suggests to me that it's a precedence issue, but moving my WebKitBuild/Release path before the 10.4u.sdk path results in a build error (unable to find class names for WebHTMLView, WebView, etc). So I'm sort of at a loss as to what the problem is. Probably the same SDK issues you referred to.
You may want to have a look at how the Drosera project is configured. It builds + links against tip of tree WebKit, and it's revision history should give a bit of info about what was required to make that work. Cheers, Mark Rowe
On 1/17/07, Mark Rowe <bdash@webkit.org> wrote:
You may want to have a look at how the Drosera project is configured. It builds + links against tip of tree WebKit, and it's revision history should give a bit of info about what was required to make that work.
I'll look into that for a permanent solution. For now I got around it by putting my WebKitBuild first on the precedence list and setting "-undefined dynamic_lookup" in "Other Linker Flags". This seems like "ZeroPointFiveLink" to me, since it tries to resolve all of the symbols it can at compile time and then punts on the rest until runtime, but it's a solution. It looks like (from looking at Drosera.xcodeproj/project.pbxproj) Drosera is linking against the WebKit in /System/Library/Frameworks, and it's using "-weak_framework JavaScriptCore -weak_framework WebCore" in their OTHER_LDFLAGS, so I'm not sure it will help. I need my local build of WebKit to be linked in. Being stranded in Windows during the day isn't helping me much. :( Once again, thanks for all the insight. -- Stephen Deken stephen.deken@gmail.com
participants (3)
-
David D. Kilzer
-
Mark Rowe
-
Stephen Deken