[webkit-dev] Some questions about adobe air version webkit
1. I compiled adobe air webkit(http://download.macromedia.com/pub/opensource/webkit/webkit_dreamweavercs5_labs_01.zip) on Windows, but it’s size reach to 10m, and Adobe compiled it to 4m, can somebody give me any adives? 2. It seems the webkit version on above address is used in dreamwave and some funtions are missing . How to download other version of air webkit on http://webkit_view:webkit_v...@stlab.adobe.com:8080 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Hi, On 15.6.2011, at 20.25, ext Greg Simon wrote: From what I can tell the spec offers no way for the web application to initialize any algorithm based on the battery/power state because there is no guarantee of minimum time when a new document is created and the first battery event arrives. Ideally there would be a way to kick the UA into sending the battery event on demand. To keep the minimum time as small as possible, the first BatteryStatusEvent should be fed into an appropriate task queue upon event listener registration. An excerpt from the spec: [[ When an event listener is registered with the event type batterystatus, then the User Agent must retrieve the relevant information and dispatch a BatteryStatusEvent event asynchronously as defined in [DOM-LEVEL-3-EVENTS]. ]] The relevant section in the D3E spec would be: http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#sync-async Otherwise the web application starts at full-throttle (burning battery) on a device with 10% battery left until it *drains* enough to get a batteryEvent. I agree we'll need to handle that case, and that's why the above-mentioned requirement is in the spec. On 15.6.2011, at 21.29, ext Darin Fisher wrote: There should probably be a way to poll the current state. Much as you can poll the document.readyState and respond to progress events, it would seem to make sense to have a way to poll the battery state as well as respond to battery state change events. The current design is quite similar to that of the Device Orientation Event. We discussed the polling option but settled on the current design. Let me know if you'd like me to dig into archives for some pointers on that design decision. -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DOM tree vs. Render tree
Hi, Could some share what's the design consideration about the DOM tree and Render tree separation? Thanks, Song ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree vs. Render tree
On Jun 16, 2011, at 7:21 AM, song.7@nokia.com wrote: Could some share what’s the design consideration about the DOM tree and Render tree separation? CSS styling makes it easy for almost any DOM node to render as almost anything. To give one trivial example, a paragraph element can be turned into a table cell with display: table-cell or removed from rendering entirely with display: none. The main reason to have a separate render tree is that the structure and classes of the render tree nodes can reflect the post-style-computation decisions of what will actually be rendered, which can be quite a bit different from the structure of the document itself. The DOM tree nodes represent the document’s structure. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some questions about adobe air version webkit
This is probably not the right place to ask Adobe about what they’ve done. I don’t think Adobe engineers answer those kinds questions on this list, and they historically haven’t participated here much. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 15.6.2011, at 20.25, ext Greg Simon wrote: From what I can tell the spec offers no way for the web application to initialize any algorithm based on the battery/power state because there is no guarantee of minimum time when a new document is created and the first battery event arrives. Ideally there would be a way to kick the UA into sending the battery event on demand. To keep the minimum time as small as possible, the first BatteryStatusEvent should be fed into an appropriate task queue upon event listener registration. An excerpt from the spec: [[ When an event listener is registered with the event type batterystatus, then the User Agent must retrieve the relevant information and dispatch a BatteryStatusEvent event asynchronously as defined in [DOM-LEVEL-3-EVENTS]. ]] The relevant section in the D3E spec would be: http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#sync-async Otherwise the web application starts at full-throttle (burning battery) on a device with 10% battery left until it *drains* enough to get a batteryEvent. I agree we'll need to handle that case, and that's why the above-mentioned requirement is in the spec. On 15.6.2011, at 21.29, ext Darin Fisher wrote: There should probably be a way to poll the current state. Much as you can poll the document.readyState and respond to progress events, it would seem to make sense to have a way to poll the battery state as well as respond to battery state change events. The current design is quite similar to that of the Device Orientation Event. We discussed the polling option but settled on the current design. Let me know if you'd like me to dig into archives for some pointers on that design decision. I'd be curious to read them. Off-hand it seems like device orientation suffers from the same problem. You wouldn't want the application to do too much work that would be discarded once it finds out that the orientation is X instead of Y. It seems like this is information that we have available immediately, and it is a bit unfortunate that page authors need to delay initialization until they receive the initial orientation or battery status event. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree vs. Render tree
Thanks, but why not generate a tree according to document ang css style at the same time? Or why is the post style decision needed? Thanks, Song -原信息- 发自： ext Darin Adler 发送： 2011-06-16, 23:54 To: Liu Song.7 (Nokia-MP/Beijing) Cc: webkit-dev@lists.webkit.org 主题： Re: [webkit-dev] DOM tree vs. Render tree On Jun 16, 2011, at 7:21 AM, song.7@nokia.com wrote: Could some share what’s the design consideration about the DOM tree and Render tree separation? CSS styling makes it easy for almost any DOM node to render as almost anything. To give one trivial example, a paragraph element can be turned into a table cell with display: table-cell or removed from rendering entirely with display: none. The main reason to have a separate render tree is that the structure and classes of the render tree nodes can reflect the post-style-computation decisions of what will actually be rendered, which can be quite a bit different from the structure of the document itself. The DOM tree nodes represent the document’s structure. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree vs. Render tree
On Jun 16, 2011, at 4:30 PM, song.7@nokia.com wrote: Thanks, but why not generate a tree according to document ang css style at the same time? Or why is the post style decision needed? I can see from your question that you didn’t understand, but I’m not sure how to clear things up. The DOM tree needs to match the document structure and can’t be influenced by style. This is what makes the DOM API work; the DOM tree is a parsed form of the document explicitly exposed as API. Style can change many ways at times when the DOM must not change, for example, when a stylesheet finishes loading, the styles from that sheet can affect how the DOM elements are displayed. We can’t change the DOM tree in response to style changes. I think we’ll have to get to a more specific question to have a useful discussion. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree vs. Render tree
On Jun 16, 2011, at 8:53 AM, Darin Adler da...@apple.com wrote: On Jun 16, 2011, at 7:21 AM, song.7@nokia.com wrote: Could some share what’s the design consideration about the DOM tree and Render tree separation? CSS styling makes it easy for almost any DOM node to render as almost anything. To give one trivial example, a paragraph element can be turned into a table cell with display: table-cell or removed from rendering entirely with display: none. The main reason to have a separate render tree is that the structure and classes of the render tree nodes can reflect the post-style-computation decisions of what will actually be rendered, which can be quite a bit different from the structure of the document itself. The DOM tree nodes represent the document’s structure. -- Darin On the topic of trees: I've used the canvas to swap out and use my own render tree. The ARIA spec has attributed like aria-owns which in some manner, allow one to set an accessibility tree that differs from the Dom tree. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
