Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties
What's the right thing to do for something that is in a CR spec, but the draft spec for the next version has it behave differently? Specifically, in Selectors 3, :not only accepts a single simple selector. In Selectors 4, it accepts a comma separated list of compound selectors (a superset of the Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994. I see three options: 1. Wait until Selectors 4 hits CR before changing :not. 2. Implement :-webkit-not to match Selectors 4 and leave :not matching Selectors 3. 3. Make :not match Selectors 4. My preference in this instance is option 3. Ojan On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt hy...@apple.com wrote: As was mentioned already, we've been trying to follow the general guideline of dropping the prefix when a draft hits CR and keeping it otherwise. An exception to this rule is if our syntax has not yet been updated to match the CR syntax, in which case we keep the prefix. dave ___ 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] subject line of webkit-changes message
Hi, I'd appreciate it if the webkit-changes maintainer(s) could consider the following. Can the subject line of a webkit-changes message be changed, for example, from: [webkit-changes] [82407] trunk/Tools to: [webkit-changes] [82407] make webkit-patch upload respect -d ? That is, show the first line of the log message (skipping Reviewer line) instead of the directory. I'd say the subject would be more meaningful that way. Yuzo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Building WebkitGTK on Mac OSX 10.6
Hey, I try to build WebkitGTK and on various revisions I get errors similar to that one: https://gist.github.com/894025 I have version 2.28 of glib and installed all of the dependencies from sources, cause I use homebrew for installing packages (usually latest ones). Should I try some older revisions? And if yes, which one should I try? Cheers! Piotr Sarnacki ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building WebkitGTK on Mac OSX 10.6
This is not the right mailing list for discussion of how to use WebKit or work around bugs. This mailing list is for people involved in the development of WebKit to work together. For an GTK-specific issue I suggest webkit-gtk mailinglist. See http://www.webkit.org/contact.html. - Patrick Am 30.03.2011 um 11:21 schrieb Piotr Sarnacki: Hey, I try to build WebkitGTK and on various revisions I get errors similar to that one: https://gist.github.com/894025 I have version 2.28 of glib and installed all of the dependencies from sources, cause I use homebrew for installing packages (usually latest ones). Should I try some older revisions? And if yes, which one should I try? Cheers! Piotr Sarnacki ___ 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] Reftests are available on new-run-webkit-tests
If you have not heard about 'reftests', please see the following wiki entry about reftests in WebKit: https://trac.webkit.org/wiki/Writing%20Reftests The new-run-webkit-tests now can run reftests in default. You can see the sample reftest here: http://trac.webkit.org/changeset/81644 I'm still doing a bit more testing and wouldn't mind some beta testers or feedbacks. One important thing to note is that old-run-webkit-tests, which is a default test harness on most platforms, doesn't support reftests. The old-run-webkit-tests simply skips reftests. Let me quote the following disclaimer from the above wiki entry: Currently, reftests run only with new-run-webkit-tests. That means a patch which is only tested with reftests might not be allowed to be checked in. Anyone not working in the chromium port will not run the reftests and can not notice regressions. Please be aware this limitation and use reftests carefully at your responsibility until reftests are available on all platforms. There are on-going efforts that try to run new-run-webkit-tests on all platforms. https://bugs.webkit.org/show_bug.cgi?id=34984 I would be happy if reftests will make people's lives easier. It would be also nice if this feature might encourage people to fix those issues which block new-run-webkit-tests to run on other ports. Any feedbacks, suggestions are welcome. -- Hayato ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties
If the change is backwards compatible (i.e. if you don't break the behavior described in Selectors 3), then I don't think it needs to be prefixed. What have other vendors done? Simon On Mar 30, 2011, at 12:05 AM, Ojan Vafai wrote: What's the right thing to do for something that is in a CR spec, but the draft spec for the next version has it behave differently? Specifically, in Selectors 3, :not only accepts a single simple selector. In Selectors 4, it accepts a comma separated list of compound selectors (a superset of the Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994. I see three options: 1. Wait until Selectors 4 hits CR before changing :not. 2. Implement :-webkit-not to match Selectors 4 and leave :not matching Selectors 3. 3. Make :not match Selectors 4. My preference in this instance is option 3. Ojan On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt hy...@apple.com wrote: As was mentioned already, we've been trying to follow the general guideline of dropping the prefix when a draft hits CR and keeping it otherwise. An exception to this rule is if our syntax has not yet been updated to match the CR syntax, in which case we keep the prefix. dave ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UA string changes blog draft
On Fri, Mar 25, 2011 at 1:08 PM, Peter Kasting pkast...@google.com wrote: On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe mr...@apple.com wrote: Safari 5.0.3 will always report a build version of 533.19.4. Safari 5.0.4 will always report a build version of 533.20.27. You already used the former in your before examples. Ideally, I would like the Safari-on-Windows and Safari-on-Mac strings from a trunk build as of around the time my change landed, which I'd use as the identical before and after strings, and only change the portions actually affected by the UA changes that landed. Since this is slated for publication this morning, I checked with dglazkov and updated my draft to use the current UA strings from a ToT WebKit build. Hopefully now all the version numbers are sane and consistent. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of -webkit- prefix on CSS Values and Properties
Yeah, I'd prefer not to prefix :not. (Haha.) In fact :not used to actually support more complex selectors, and I had to dumb it down to pass stupid CSS 2.1 tests that deliberately checked for the lack of complexity... so all we'd be doing is going back to our old behavior. We should probably make sure those tests are not in the current version of the suite though. dave (hy...@apple.com) On Mar 30, 2011, at 10:50 AM, Simon Fraser wrote: If the change is backwards compatible (i.e. if you don't break the behavior described in Selectors 3), then I don't think it needs to be prefixed. What have other vendors done? Simon On Mar 30, 2011, at 12:05 AM, Ojan Vafai wrote: What's the right thing to do for something that is in a CR spec, but the draft spec for the next version has it behave differently? Specifically, in Selectors 3, :not only accepts a single simple selector. In Selectors 4, it accepts a comma separated list of compound selectors (a superset of the Selectors 3 behavior). See https://bugs.webkit.org/show_bug.cgi?id=56994. I see three options: 1. Wait until Selectors 4 hits CR before changing :not. 2. Implement :-webkit-not to match Selectors 4 and leave :not matching Selectors 3. 3. Make :not match Selectors 4. My preference in this instance is option 3. Ojan On Tue, Mar 29, 2011 at 7:17 AM, David Hyatt hy...@apple.com wrote: As was mentioned already, we've been trying to follow the general guideline of dropping the prefix when a draft hits CR and keeping it otherwise. An exception to this rule is if our syntax has not yet been updated to match the CR syntax, in which case we keep the prefix. dave ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Evolving the Sunspider Benchmark
I am wondering what the webkit community thoughts are with respect to possibly evolving the sunspider benchmark. I have worked with webkit based browsers and various javascript engines shipping on mobile devices today and am seeing some very peculiar behavior now starting to show up. As the various javascript engines have evolved and become more and more efficient over the past few years, the time spent executing individual sunspider subtests has decreased to a point that javascript execution no longer seems to consuming most of the execution time. Majority of the subtests have fallen to under 100ms in execution times even on mobile devices. Rather, while the tests are executing, other events like screen refreshes and paints seem to consume more time and even tend to overshadow the end results reported by the testsuite at times. Note, that my above observation is actually specific only to the sunspider benchmark. In terms of real page loading timelines, javascript execution still appears to be a significant factor. Also, several of the other javascript specific benchmarks like Google's V8suite and Mozilla's Kraken benchmarks do not seem to show this same sort of limiting behavior since they seem to be geared towards scripts running over longer timelines. So, I was wondering if any others in the community were starting to notice similar behavior and even more importantly if any effort is being planned to try and evolve the sunspider benchmark to add any javascript issues being noticed in todays newer websites into the benchmark so that it can be kept up-to-date. Thanks, Dineel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
