[webkit-dev] Feeling stuck on preparing next patches for CSSRegions/CSSExclusions
Hello, Part of our efforts towards enabling CSSRegions/CSSExclusions support in WebKit, we have submitted 2 patches last week: [61726][CSSExclusions]Parse wrap shape property [61730][CSSRegions]Parse flow property In addition to these patches, we would like to prepare more patches. However, we feel a little stuck because we want to make sure that the code and the associated tests we submitted with the first patches are going in the right direction. Specifically, for the addition of new CSS properties, is there a template we should follow for parsing and testing? We have seen some patterns for handling properties and we are not sure which one to follow. This is important because we would like to start working on support for additional properties, and avoid repeating the same mistakes if there are any in these initial patches. Thanks in advance for your help! Cheers, Mihnea ___ 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 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: 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. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] 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. In addition to the above mentioned reason, a synchronous API might encourage web authors to write badly performing code, i.e. poll the battery status via setInterval() too often. In the current event-driven design a new event is dispatched only when the battery status changes. -Anssi ___ 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 Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: 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. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] The proposal wasn't to make blocking APIs that query any devices. Instead, you would be able to get synchronous access to the last known value for a device property (last known battery state, last known device orientation, etc.). In particular, you would get access to the last known value prior to your page being loaded. Synchronous access to this value seems helpful for the reasons stated in this thread. But, let me expand on that for a moment. Suppose an application wanted to know both the battery state and the device orientation before generating its content. It would need to asynchronously query both states before proceeding. That seems quite awkward, especially when the information could be provided synchronously. 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. In addition to the above mentioned reason, a synchronous API might encourage web authors to write badly performing code, i.e. poll the battery status via setInterval() too often. In the current event-driven design a new event is dispatched only when the battery status changes. Do we have experience showing that such polling abuse is a problem caused by document.readyState? I think that people would write setInterval based polling code if there were no convenient event subscription API. But, the proposal is to provide both, just as both are provided for page load progress information. Regards, -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Feeling stuck on preparing next patches for CSSRegions/CSSExclusions
On Jun 17, 2011, at 1:58 AM, Mihnea-Vlad Ovidenie wrote: We have seen some patterns for handling properties and we are not sure which one to follow. It would be helpful if you were more specific here. What were the patterns you have seen? If you give a specific bug number or revision number I can help answer the question of whether that patch reflects best practices for adding new CSS properties. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Feeling stuck on preparing next patches for CSSRegions/CSSExclusions
I made some comments in the bugs. Simon On Jun 17, 2011, at 9:38 AM, Darin Adler wrote: On Jun 17, 2011, at 1:58 AM, Mihnea-Vlad Ovidenie wrote: We have seen some patterns for handling properties and we are not sure which one to follow. It would be helpful if you were more specific here. What were the patterns you have seen? If you give a specific bug number or revision number I can help answer the question of whether that patch reflects best practices for adding new CSS properties. ___ 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 Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: 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. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] The proposal wasn't to make blocking APIs that query any devices. Instead, you would be able to get synchronous access to the last known value for a device property (last known battery state, last known device orientation, etc.). In particular, you would get access to the last known value prior to your page being loaded. Synchronous access to this value seems helpful for the reasons stated in this thread. But, let me expand on that for a moment. Suppose an application wanted to know both the battery state and the device orientation before generating its content. It would need to asynchronously query both states before proceeding. That seems quite awkward, especially when the information could be provided synchronously. In the case of device orientation, having such a synchronous property would probably mean having the UA do a lot of wasted work, constantly exercising the underlying hardware just in case some Web app might need this information at start-up. However, I think it's reasonable to expect that Web apps using this API will be built in such a way that they will do work in response to orientation changes, so it's perhaps natural for them to treat the initial orientation the same way. Thanks, Andrei ___ 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 Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com wrote: On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: 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. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] The proposal wasn't to make blocking APIs that query any devices. Instead, you would be able to get synchronous access to the last known value for a device property (last known battery state, last known device orientation, etc.). In particular, you would get access to the last known value prior to your page being loaded. Synchronous access to this value seems helpful for the reasons stated in this thread. But, let me expand on that for a moment. Suppose an application wanted to know both the battery state and the device orientation before generating its content. It would need to asynchronously query both states before proceeding. That seems quite awkward, especially when the information could be provided synchronously. In the case of device orientation, having such a synchronous property would probably mean having the UA do a lot of wasted work, constantly exercising the underlying hardware just in case some Web app might need this information at start-up. However, I think it's reasonable to expect that Web apps using this API will be built in such a way that they will do work in response to orientation changes, so it's perhaps natural for them to treat the initial orientation the same way. That's a good point. I guess I feel less strongly about orientation events, especially since there is such a large continuum of states. Whereas with battery state, there are fewer states and less frequent changes. navigator.onLine and the online/offline events are somewhat comparable to battery state in my opinion. Both change at a relatively low frequency. -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
We ran into this problem on webOS with orientation where we did not want to have the UI drawn wrong the first time and then (eventually) re-layed out and painted at the correct device orientation. It looked VERY sloppy and web-page-ish, not what we were trying to accomplish. Sure we could have gamed the UA and transmitted the orientation at *just the right time* when the app launched, but that would have been a nasty race condition and yet another quirk. For battery display we used the a proprietary XHR-type with subscription so we could initialize the battery UI+level, and then get updates as the proposed spec is shooting for. On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com wrote: On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: 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. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] The proposal wasn't to make blocking APIs that query any devices. Instead, you would be able to get synchronous access to the last known value for a device property (last known battery state, last known device orientation, etc.). In particular, you would get access to the last known value prior to your page being loaded. Synchronous access to this value seems helpful for the reasons stated in this thread. But, let me expand on that for a moment. Suppose an application wanted to know both the battery state and the device orientation before generating its content. It would need to asynchronously query both states before proceeding. That seems quite awkward, especially when the information could be provided synchronously. In the case of device orientation, having such a synchronous property would probably mean having the UA do a lot of wasted work, constantly exercising the underlying hardware just in case some Web app might need this information at start-up. However, I think it's reasonable to expect that Web apps using this API will be built in such a way that they will do work in response to orientation changes, so it's perhaps natural for them to treat the initial orientation the same way. Thanks, Andrei ___ 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] Adding ENABLE_BATTERY_STATUS to WebCore
My 2¢: I'm confused by who the client of this API would be. It seems that web sites don't really need to know my battery state. But web applications that are on mobile phone (like WebOS, or Apple's original vision for iPhone apps) would want battery state information, but would want *more* information than this spec provides (imagine trying to write any power-management application like the zillion examples available for Apple's Dashboard, or iPhone). I'm also not sure that I want all web sites knowing this information. I wonder what fingerprinting vectors this API would expose (if any?). Certainly websites could know if their visitors are laptop users or not (but I suspect they can already figure that out from screen size and UA strings). It's also possible that I'm just spreading FUD here, and that smarter people than I have already hashed this all out on the spec list... -eric On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com wrote: On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: 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. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] The proposal wasn't to make blocking APIs that query any devices. Instead, you would be able to get synchronous access to the last known value for a device property (last known battery state, last known device orientation, etc.). In particular, you would get access to the last known value prior to your page being loaded. Synchronous access to this value seems helpful for the reasons stated in this thread. But, let me expand on that for a moment. Suppose an application wanted to know both the battery state and the device orientation before generating its content. It would need to asynchronously query both states before proceeding. That seems quite awkward, especially when the information could be provided synchronously. In the case of device orientation, having such a synchronous property would probably mean having the UA do a lot of wasted work, constantly exercising the underlying hardware just in case some Web app might need this information at start-up. However, I think it's reasonable to expect that Web apps using this API will be built in such a way that they will do work in response to orientation changes, so it's perhaps natural for them to treat the initial orientation the same way. That's a good point. I guess I feel less strongly about orientation events, especially since there is such a large continuum of states. Whereas with battery state, there are fewer states and less frequent changes. navigator.onLine and the online/offline events are somewhat comparable to battery state in my opinion. Both change at a relatively low frequency. -Darin ___ 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] Adding ENABLE_BATTERY_STATUS to WebCore
I think there are web app developers that would do things differently if they knew their user was running on battery power. An app might scale back its CPU usage, or run a timer at a lower frequency. Crazy idea: Maybe an advertising network could be nice and not show animated ads to such users? ;-) -Darin On Fri, Jun 17, 2011 at 10:47 AM, Eric Seidel e...@webkit.org wrote: My 2¢: I'm confused by who the client of this API would be. It seems that web sites don't really need to know my battery state. But web applications that are on mobile phone (like WebOS, or Apple's original vision for iPhone apps) would want battery state information, but would want *more* information than this spec provides (imagine trying to write any power-management application like the zillion examples available for Apple's Dashboard, or iPhone). I'm also not sure that I want all web sites knowing this information. I wonder what fingerprinting vectors this API would expose (if any?). Certainly websites could know if their visitors are laptop users or not (but I suspect they can already figure that out from screen size and UA strings). It's also possible that I'm just spreading FUD here, and that smarter people than I have already hashed this all out on the spec list... -eric On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com wrote: On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: 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. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] The proposal wasn't to make blocking APIs that query any devices. Instead, you would be able to get synchronous access to the last known value for a device property (last known battery state, last known device orientation, etc.). In particular, you would get access to the last known value prior to your page being loaded. Synchronous access to this value seems helpful for the reasons stated in this thread. But, let me expand on that for a moment. Suppose an application wanted to know both the battery state and the device orientation before generating its content. It would need to asynchronously query both states before proceeding. That seems quite awkward, especially when the information could be provided synchronously. In the case of device orientation, having such a synchronous property would probably mean having the UA do a lot of wasted work, constantly exercising the underlying hardware just in case some Web app might need this information at start-up. However, I think it's reasonable to expect that Web apps using this API will be built in such a way that they will do work in response to orientation changes, so it's perhaps natural for them to treat the initial orientation the same way. That's a good point. I guess I feel less strongly about orientation events, especially since there is such a large continuum of states. Whereas with battery state, there are fewer states and less frequent changes. navigator.onLine and the online/offline events are somewhat comparable to battery state in my opinion. Both change at a relatively low frequency. -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
Given how many desktop applications do this, I think we're well off into the land of wishes and fairy tales. :) But it's also possible that libraries like jquery or Google's closure could do this... but again, I'm skeptical. Then again, if we don't expose information like this, they don't ever have a chance to prove me wrong. -eric On Fri, Jun 17, 2011 at 10:54 AM, Darin Fisher da...@chromium.org wrote: I think there are web app developers that would do things differently if they knew their user was running on battery power. An app might scale back its CPU usage, or run a timer at a lower frequency. Crazy idea: Maybe an advertising network could be nice and not show animated ads to such users? ;-) -Darin On Fri, Jun 17, 2011 at 10:47 AM, Eric Seidel e...@webkit.org wrote: My 2¢: I'm confused by who the client of this API would be. It seems that web sites don't really need to know my battery state. But web applications that are on mobile phone (like WebOS, or Apple's original vision for iPhone apps) would want battery state information, but would want *more* information than this spec provides (imagine trying to write any power-management application like the zillion examples available for Apple's Dashboard, or iPhone). I'm also not sure that I want all web sites knowing this information. I wonder what fingerprinting vectors this API would expose (if any?). Certainly websites could know if their visitors are laptop users or not (but I suspect they can already figure that out from screen size and UA strings). It's also possible that I'm just spreading FUD here, and that smarter people than I have already hashed this all out on the spec list... -eric On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu andr...@google.com wrote: On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: 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. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] The proposal wasn't to make blocking APIs that query any devices. Instead, you would be able to get synchronous access to the last known value for a device property (last known battery state, last known device orientation, etc.). In particular, you would get access to the last known value prior to your page being loaded. Synchronous access to this value seems helpful for the reasons stated in this thread. But, let me expand on that for a moment. Suppose an application wanted to know both the battery state and the device orientation before generating its content. It would need to asynchronously query both states before proceeding. That seems quite awkward, especially when the information could be provided synchronously. In the case of device orientation, having such a synchronous property would probably mean having the UA do a lot of wasted work, constantly exercising the underlying hardware just in case some Web app might need this information at start-up. However, I think it's reasonable to expect that Web apps using this API will be built in such a way that they will do work in response to orientation changes, so it's perhaps natural for them to treat the initial orientation the same way. That's a good point. I guess I feel less strongly about orientation events, especially since there is such a large continuum of
Re: [webkit-dev] Feeling stuck on preparing next patches for CSSRegions/CSSExclusions
You should also feel welcome to land test suites which entirely/mostly fail, and then later land the code changes which make them pass. We used this method with great success for the HTML parser re-write. This can be useful in cases where your individual tests have larger coverage than any individual change. -eric On Fri, Jun 17, 2011 at 1:58 AM, Mihnea-Vlad Ovidenie mih...@adobe.com wrote: Hello, Part of our efforts towards enabling CSSRegions/CSSExclusions support in WebKit, we have submitted 2 patches last week: [61726][CSSExclusions]Parse wrap shape property [61730][CSSRegions]Parse flow property In addition to these patches, we would like to prepare more patches. However, we feel a little stuck because we want to make sure that the code and the associated tests we submitted with the first patches are going in the right direction. Specifically, for the addition of new CSS properties, is there a template we should follow for parsing and testing? We have seen some patterns for handling properties and we are not sure which one to follow. This is important because we would like to start working on support for additional properties, and avoid repeating the same mistakes if there are any in these initial patches. Thanks in advance for your help! Cheers, Mihnea ___ 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] Compiling SVG lighting filters for ARM NEON
On Fri, Jun 17, 2011 at 5:04 AM, itisravi cybera...@gmail.com wrote: Hello, 1.Could someone give inputs on what specific project files are to be modified in a webkit-gtk build if I add new sources to the tree? 2.I was trying to build the FELighting Filters for NEON; the build fails with the following message: Source/WebCore/platform/graphics/filters/FELighting.cpp:37: fatal error: FELightingNEON.h: No such file or directory Are you working from a release tarball? If so, you should probably start by getting the repository from git or svn. It's likely that we just didn't ship this file. We probably just need to add it to Source/WebCore/ GNUmakefile.list.am in the repo before the next release. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Making WebKit on ubuntu 10.10 looks for xcodebuild?
Hello, I'm trying to install Webkit on ubuntu 10.10. When I run the make file I get an xcodebuild: not found error. So I tried using the autogen.sh to use automake but when m4 is executed it doesn't like the argument --gnu specifically the error is: unrecognized option '--gnu'. The gnuMakeFile in the root directory is an automake file. I have an older release and the release from the Git Clone, both are producing roughly the same results. Can anyone help? Best regards, Tom ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making WebKit on ubuntu 10.10 looks for xcodebuild?
Figuring out how to get WebKit to build is a topic for webkit-help, not webkit-dev. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] 194 bugs in pending-commit
There are a 194 open bugs with an R+ patches attached to them: https://bugs.webkit.org/buglist.cgi?query_format=advancedshort_desc_type=notregexpshort_desc=%5C%5BS60%5C%5Dlong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%2Bfield0-1-0=nooptype0-1-0=equalsvalue0-1-0= Please take a minute to look through this list and clean out any bugs you know about. (Looks like 5 of them are assigned to me, so I'll be following my own advice shortly.) Some recommended actions: 1) Close the bug if the patch has already been landed. 2) Mark the patch as obsolete / clear the review flag if we're not going to land the patch. 3) Mark the patch commit-queue+ if you'd like the commit queue to land the patch. 4) Land the patch manually if the patch needs some tweaking before landing. Thanks, and happy bug scrubbing! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
