Re: [webkit-dev] XPath Issues?
On Wed, Nov 3, 2010 at 6:28 PM, Alexey Proskuryakov a...@webkit.org wrote: 03.11.2010, в 10:11, Alex Milowski написал(а): many of the incompatibilities may not occur within the context of the browser with a pre-built DOM. WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. Also, we can't expect to stay at XPath 1.0 forever. Actually, I see this situation as similar to XHTML 2.0. XPath is embedded into browsers both directly and via XSLT. Any incompatible specification featuring the same name is likely to end up as an academic exercise, dead on arrival. Looking at Mozilla bugs, they seem to have zero interest in XPath 2.0 and XSLT 2.0: https://bugzilla.mozilla.org/show_bug.cgi?id=396966 https://bugzilla.mozilla.org/show_bug.cgi?id=370173 They might not but users do. Mozilla has its own XSLT 1.0 implementation that is not complete. I don't think that's a great comparison. We would need to pull an off the shelf implementation of XPath and XSLT 2.0. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Thu, Nov 4, 2010 at 2:16 PM, Alex Milowski a...@milowski.org wrote: WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. My belief, and please correct me if I'm wrong, is that once the XML has been parsed and built into a DOM, applyXSLTransform() at Document.cpp:3954 is eventually called with the correct XSLT from some xml-stylesheet processing instruction. With the libxslt, the DOM is serialized back into a string so it can be loaded into their internal format as they don't provide a way to give them a pre-existing DOM. I've been trying to trace through all the places where XSLT is used and how this all fits together. Finding an alternative to libxslt is something I think is a worthwhile endeavor due to the inability to integrate tightly with a pre-built DOM instance. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Thu, Nov 4, 2010 at 2:17 PM, Alex Milowski a...@milowski.org wrote: On Thu, Nov 4, 2010 at 2:16 PM, Alex Milowski a...@milowski.org wrote: WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. Nevermind. My mistake. I should have dug further. Yes, I see that in the case of XSLT via the xml-stylesheet, we use the cached source. In the case of the Javascript XSLT processor, that's not the case and that's how we get differences. Nevertheless, I don't see how the xml-stylesheet spec [1] says you have to use the bytes off the wire. [1] http://www.w3.org/TR/xml-stylesheet/ -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGtk app memory leaks , please help
As far as I know you can not listen for DOM event using QWebElement. On Wed, Nov 3, 2010 at 4:44 PM, Xan Lopez x...@gnome.org wrote: On Wed, Nov 3, 2010 at 1:20 PM, Fedor Kryukov y...@mail.ru wrote: Thanks, As I understand this is a WebkitGtk bug only? So I can temporarily switch to QT WebKit to avoid leaks? Possibly, but I don't know, you should ask them. Also, both bindings are not equally feature-complete (I believe in general the GTK+ ones have more features), so you'll have to be careful with that too. Xan Xan Lopez-3 wrote: On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote: After calling webkit_web_view_get_dom_document() and similar functions ( webkit_dom... * ) memory is not freed, what am I doing wrong? I wrote simple application which handle events ( load-started/load-finished/etc ) and make some changes in loaded page DOM content, so after loading several pages I have a lot of lost memory, no idea how to release it. I tried to use g_object_unref, but it destroys something.. -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html Sent from the Webkit mailing list archive at Nabble.com. The memory management of the GObject DOM bindings is still a work in progress (unfortunately!). We are trying to figure the best to automatically collect them, but for now you are correct in saying that they are essentially leaked until the process is over. See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion on the topic. Our plan is to have this issue resolved before the next stable release in April. Xan ___ 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 -- View this message in context: http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30126515.html Sent from the Webkit mailing list archive at Nabble.com. ___ 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 -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Size Of Ruby Text?
Argh… sent from the wrong alias again...Begin forwarded message:From: webkit-dev-ow...@lists.webkit.orgSubject: Re: [webkit-dev] Size Of Ruby Text?Date: November 4, 2010 9:56:21 AM HSTTo: mader_e...@apple.comYou must be subscribed in order to post to this mailing list.From: Eric Mader mader_e...@apple.comSubject: Re: [webkit-dev] Size Of Ruby Text?Date: November 4, 2010 9:54:42 AM HSTTo: Roland Steiner rolandstei...@google.comCc: Yasuo Kida k...@apple.com, WebKit Development webkit-dev@lists.webkit.orgHere's Kida-san's example as displayed with my local ruby changes:(hope the image makes it all the way to the list)This includes my early line-stacking changes. Notice that the ruby text (in "ruby" red ;-) overlaps the previous line - my code doesn't check to see if the ruby overlaps the pervious line or spills outside of the frame's top bounds.The inter-character spacing is better, but not perfect. My overhang code needs to add inter-character spacing to the base text if the ruby text is wider and can't overlap its neighbors.What were were discussing below is the space between the base text and the ruby text. The ruby text should be closer to the base text. As you can see above, it's getting laid out as if it were just a previous line.Regards,EricOn Nov 3, 2010, at 9:35 PM, Roland Steiner wrote:FWIW, since Eric is working on ruby overhang, AFAIK, white space should become much less pronounced. I therefore would personally opt for more legible ruby characters (read: 8px or 9px) over whitespace worries. Cheers,- RolandOn Thu, Nov 4, 2010 at 8:05 AM, Yasuo Kida k...@apple.com wrote: Right. It is partly because webkit currently does not use glyphs that are designed for ruby. I would not worry this too much as with 14px many kanjis are only barely legible in anyway without the context. The lower bound for ruby can be 8px for base 16px = 12pt in 96dpi. I am reluctant to raise it to 9 px. It would be more important to keep the 50% ratio until we hit the threshold to avoid too many white spaces between base characters.- kida [snip] ___webkit-dev mailing listwebkit-dev@lists.webkit.orghttp://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] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
I don't think calling these Request events fits with the rest of the web platform. Essentially, these are events that fire before some action occurs and gives the web developer the opportunity to cancel that action. The precedence in web events is to call those before* events. So, instead of having an UndoRequest event, we'd have a BeforeUndo event. These events seem completely consistent with other before* events in their expected behavior. To be clear, I'm not trying to block you moving forward with this. I completely agree these use-cases need to be met. I just want to make sure we do something that is consistent with the rest of the platform and meets as many use cases as possible. Other responses inline... On Tue, Nov 2, 2010 at 3:01 PM, James Craig jcr...@apple.com wrote: On Nov 2, 2010, at 12:48 PM, Ojan Vafai wrote: I still don't see why beforeInput would not be sufficient. It might be more clear if you enumerated the list of things you expect to have UIRequestEvents for. There are several examples in the proposal, including: Users, wanting to change the value of a custom range widget (ARIA slider, ARIA media progressbar, etc.) in a web application, can indicate their intent a number of ways, including pressing various keys (up, down, left, right, pageup, pagedown, home, end) on most keyboard-controlled interfaces, and through gestures on many touch-enabled interfaces. User agents understanding this intent should initiate a ValueChangeRequest event. Web authors who have registered for this event, should process the event to determine whether to cancel the event. If the value change action is understood in the context of the web application, web authors should change the value of the associated widget by an amount determined via the changeType argument, and cancel the event using the event object's ---() method. If the event is not cancelled by the web author, user agents may pass the literal interaction event to the web application; in this case, in the form of a keypress event. I think one area of confusion is that I don't get why UIScrollRequestEvent, UIValueChangeRequestEvent and DOMAttributeChangeRequestEvent inherit from UIRequestEvent. The event types currently listed under UIRequestEvent all seem like they'd be appropriate for beforeInput. I understand that UIScrollRequestEvent, UIValueChangeRequestEvent and DOMAttributeChangeRequestEvent might not be met be replaceable by beforeInput (scroll clearly isn't!). As I stated in the bug tracker comments, the W3C DOM and PF working groups discussed this, and the outcome was to work on a standalone specification as a joint effort of the two groups. The initial document editors will likely be Doug Schepers (W3C staff contact for www-dom) and me. From the teleconference discussions, these will be an add-on to DOM 3 Events and/or ARIA 1.0, because both of those documents are currently in Last Call. The only major change to the proposal so far that we're discussing a new method to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so that we don't have to cancel the event by overloading the original use of the preventDefault method. What's the difference between preventDefault and suppressEvents? preventDefault only prevents the default action of the current event. supressEvents would allow the author to inform the user agent that any remaining events for the same user interaction are no longer relevant. For example, if the user pressed either Delete key and the application intercepted the DeleteRequest event, it could call Event.suppressEvents() (or whatever we call it) to indicate that the related events (keydown, keyup, keypress) are no longer needed, and the user agent should not fire them. The issue here is that these are meta events that could correspond to different default actions? I think it would be fine to spec it such that the default action depends on what the user did. For example, if the user hits the delete key, the default action would be the keydown. preventDefault on the DeleteRequest would prevent the keydown and thus they keypress/keyup. If the user deletes from the menu, then the default action is just the delete itself. Web developers are already confused enough by the combination of preventDefault and stopPropagation. I don't think this situation calls for adding a third method. We can just hide the complexity in the speccing of the default actions for each event. Also, earlier in this thread, you said that you don't know of anything that requires these events to be synchronous, but that seems to contradict James's point above and the patch in question fires the events synchronously. The spec text all also implies that the event fires, then application has the chance to prevent it and then the action happens. So, unless I'm misreading, the events need to be synchronous and fire before the associated action occurs. All events are like that. For
[webkit-dev] Can the build bot trigger be limited to trunk?
As far as I can tell, all of the builders and testers use trunk, so changes to branches and tags should not trigger a build. Can the build bot be configured accordingly? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can the build bot trigger be limited to trunk?
On Nov 4, 2010, at 7:51 PM, Dan Bernstein wrote: As far as I can tell, all of the builders and testers use trunk, so changes to branches and tags should not trigger a build. Can the build bot be configured accordingly? Only commits to trunk will trigger builds. The two lines that accomplish this are: http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/build.webkit.org-config/config.json#L214 http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/build.webkit.org-config/master.cfg#L434 -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
