Re: [webkit-dev] Using GitHub to Contribute to WebKit (Experimental)
On Tue, Apr 24, 2012 at 6:14 AM, Adam Roben aro...@webkit.org wrote: On Fri, Mar 16, 2012 at 5:40 PM, Adam Barth aba...@webkit.org wrote: On Fri, Mar 16, 2012 at 2:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we do some Bugzilla integration as Jarred suggested? If you're excited about using GitHub, you should feel free to do that work. It sounds like there is already work going on on GitHub (e.g., the iframe seamless support) even though this integration hasn't yet been built. I echo Ariya and Ryosuke's concern that the reduced visibility of that work makes it harder for WebKit contributors to provide feedback, or even to realize that the work is going on. Is there anyone working on improving the integration between GitHub and our current tools so that work that occurs there can be as easily discovered as work that goes on in bugs.webkit.org? I don't believe so. The iframe seamless work, in particular, was announced on webkit-dev, so folks shouldn't have trouble finding it. Some (small) parts of the branch have landed in trunk, but we put them through the normal bugs.webkit.org review process. My sense is that we're still experimenting with GitHub, so investing in integration still seems a bit premature. GitHub certainly made it easy for me to contribute the navigation part of seamless to Eric's branch, which seems like a win over him using SVN, patch files, or even git locally. I'll update the wiki after seamless lands to reflect what we've learned. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] github mirror
Tor, I think we should retire the author rewriting script on GitHub. Jame's is right that there's a lot of value in having git.webkit.org and GitHub using the same hashes. For example, both Eric and Gavin requested that when they started using GitHub. We would have some trouble adopting the author rewriting script on git.webkit.org. For example, the instructions for using git with WebKit http://trac.webkit.org/wiki/UsingGitWithWebKit suggest configuring git-svn to allow you to commit from your git repository. When git-svn imports changes from SVN into your git repository, it won't know to apply the author rewriting script. That will cause your local repository to diverge from an author-rewriting git.webkit.org, which is bad times. Therefore, it seems like the best way to synchronize the hashes between git.webkit.org and GitHub is to retire the author rewriting script on GitHub and do a non-fastforward push of the unrewritten repository. That will be somewhat disruptive for folks currently using the GitHub repository, but at least it's only a one-time cost. Adam On Tue, Apr 24, 2012 at 11:06 AM, James Robinson jam...@google.com wrote: On Tue, Apr 24, 2012 at 7:15 AM, Tor Arne Vestbø tor.arne.ves...@nokia.com wrote: On 24.04.12 16:04, ext Shezan Baig wrote: On Tue, Apr 24, 2012 at 9:55 AM, Adam Robenaro...@webkit.org wrote: In what situation does this cause issues? Probably the biggest issue is for people who've been using git.webkit.org and now want to try out GitHub. Since the commits are distinct between the two repositories, they have to do a full clone to make the switch. In theory though, these users should be able to just add a remote to their existing clone. Then it will just sync the commit objects, and not the trees and blobs. Not ideal, they would have two different 'masters', but still doable, and not *that* much of an overhead. Switching between the different masters should also be fast since the trees will be the same. Right, a fetch should ideally just pull down the commit objects, but it appears git does not have this optimization. If it did, I don't think the issue of two remote masters would be that big, since you would at some point likely transition to use one of the mirrors anyways. And if not, having multiple mirrors/remotes should be fine -- I'm using both the github and gitorious mirror without any issues. But I agree these two repos should probably merge sooner rather than later, just to avoid confusion for new users etc :) I would support that if it means cleaning up the author-script (which I'm happy to do), and using that on webkit.org. Whatever we decide to do in the future, author rewriting seems like extremely low value compared to having matching SHA1s. I think we should get a clone on github.com that matches the existing git.webkit.org SHA1s and then make sure that they stay in sync (either with rewriting or not, but whatever webkit.org does). - James tor arne ___ 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] webkitPostMessage
I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm
still unsure how to proceed with removing webkitPostMessage and
aligning postMessage with the spec. No one responded to my earlier
message, so I'm inclined to just post a patch.
Many thanks,
Adam
On Tue, Apr 10, 2012 at 9:08 PM, Adam Barth aba...@webkit.org wrote:
I'm trying to understand why we have both DOMWindow.webkitPostMessage
and DOMWindow.postMessage. I'm also trying to understand the
following comment in {JS,V8}DOMWindowCustom.cpp:
// This function has variable arguments and can be:
// Per current spec:
// postMessage(message, targetOrigin)
// postMessage(message, targetOrigin, {sequence of transferrables})
// Legacy non-standard implementations in webkit allowed:
// postMessage(message, {sequence of transferrables}, targetOrigin);
Specifically:
1) Can we remove webkitPostMessage? If we can't remove it now, is
there a time in the future at which we can remove it?
2) Can we adopt the behavior in the specification (and drop the
non-standard behavior)? If not, should we change the specification to
match our behavior?
Many thanks,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
wrt #1, I believe that postMessage implements what is in the spec and
webkitPostMessage additional has support for ArrayBuffers which wasn't in
the postMessage spec yet but was going to be added. If the behaviors from
webkitPostMessage were added to postMessage, then it coudl be removed.
wrt #2, I don't know. I think it will break some tests if you go with the
spec behavior, but if you wish to try this, I don't know of any big reason
not to.
dave
On Sun, Apr 29, 2012 at 11:01 AM, Adam Barth aba...@webkit.org wrote:
I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm
still unsure how to proceed with removing webkitPostMessage and
aligning postMessage with the spec. No one responded to my earlier
message, so I'm inclined to just post a patch.
Many thanks,
Adam
On Tue, Apr 10, 2012 at 9:08 PM, Adam Barth aba...@webkit.org wrote:
I'm trying to understand why we have both DOMWindow.webkitPostMessage
and DOMWindow.postMessage. I'm also trying to understand the
following comment in {JS,V8}DOMWindowCustom.cpp:
// This function has variable arguments and can be:
// Per current spec:
// postMessage(message, targetOrigin)
// postMessage(message, targetOrigin, {sequence of transferrables})
// Legacy non-standard implementations in webkit allowed:
// postMessage(message, {sequence of transferrables}, targetOrigin);
Specifically:
1) Can we remove webkitPostMessage? If we can't remove it now, is
there a time in the future at which we can remove it?
2) Can we adopt the behavior in the specification (and drop the
non-standard behavior)? If not, should we change the specification to
match our behavior?
Many thanks,
Adam
___
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] webkitPostMessage
On Sun, Apr 29, 2012 at 11:15 AM, David Levin le...@google.com wrote:
wrt #1, I believe that postMessage implements what is in the spec and
webkitPostMessage additional has support for ArrayBuffers which wasn't in
the postMessage spec yet but was going to be added. If the behaviors from
webkitPostMessage were added to postMessage, then it coudl be removed.
It looks like the spec has been updated to include support for ArrayBuffers:
http://www.whatwg.org/specs/web-apps/current-work/#dom-window-postmessage
wrt #2, I don't know. I think it will break some tests if you go with the
spec behavior, but if you wish to try this, I don't know of any big reason
not to.
Ok, I'll make these changes in separate patches in case either causes
trouble down the line.
Thanks!
Adam
On Sun, Apr 29, 2012 at 11:01 AM, Adam Barth aba...@webkit.org wrote:
I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm
still unsure how to proceed with removing webkitPostMessage and
aligning postMessage with the spec. No one responded to my earlier
message, so I'm inclined to just post a patch.
Many thanks,
Adam
On Tue, Apr 10, 2012 at 9:08 PM, Adam Barth aba...@webkit.org wrote:
I'm trying to understand why we have both DOMWindow.webkitPostMessage
and DOMWindow.postMessage. I'm also trying to understand the
following comment in {JS,V8}DOMWindowCustom.cpp:
// This function has variable arguments and can be:
// Per current spec:
// postMessage(message, targetOrigin)
// postMessage(message, targetOrigin, {sequence of transferrables})
// Legacy non-standard implementations in webkit allowed:
// postMessage(message, {sequence of transferrables},
targetOrigin);
Specifically:
1) Can we remove webkitPostMessage? If we can't remove it now, is
there a time in the future at which we can remove it?
2) Can we adopt the behavior in the specification (and drop the
non-standard behavior)? If not, should we change the specification to
match our behavior?
Many thanks,
Adam
___
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] webkitPostMessage
On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote: I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm still unsure how to proceed with removing webkitPostMessage and aligning postMessage with the spec. No one responded to my earlier message, so I'm inclined to just post a patch. Comparing your post to the recommended steps on that page (the page says the same steps should be applied to removing only the prefixed version of a feature): It looks like you did this: Any deprecation should be sent to webkit-dev for discussion. It doesn't look like you did any of these yet: Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify: usage statistics in the wild (either by instrumenting the browser or any other means). some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized. some proof that there is others way to achieve the same result that are better. some proof that web-developers don't care much about this feature. ... It seems like this hasn't really happened but you did give people due notice: If several vendors are supporting the feature, we expect people to have interacted with them to assess their support towards the removal. == I can add that I'm not aware of any WebKit-specific content at Apple that uses webkitPostMessage. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Deprecating features guideline wiki
On Apr 27, 2012, at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: BTW, the page at https://trac.webkit.org/wiki/DeprecatingFeatures seems to be using deprecate in the sense of remove entirely. Is that what is meant? If so, I think it would be helpful to change the wording to removing features. In non-Web contexts, deprecate often means a step short of removal. I agree that Removing features is clearer and more to the point :). When to deprecate features in the sense of we recommend you use this other feature instead is an entirely different conversation. Now that I look closer, I see that it says: Deprecating a feature means we will remove it in the future. Deprecation is not meant as a usage metric collection or to assess web-developers' reactions. This seems to imply that there actually is a step of deprecation that comes prior to removal. What exactly is this step? How are features supposed to be marked deprecated? What is the effect of being deprecated, if any, other than future removal? Does anyone who was at the session know the answer? My own recommendation would be to just remove features that we've decided to remove. Any data gathering related to potential removal should happen before we make a decision. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote: I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm still unsure how to proceed with removing webkitPostMessage and aligning postMessage with the spec. No one responded to my earlier message, so I'm inclined to just post a patch. Comparing your post to the recommended steps on that page (the page says the same steps should be applied to removing only the prefixed version of a feature): It looks like you did this: - Any deprecation should be sent to webkit-dev for discussion. It doesn't look like you did any of these yet: - Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify: - usage statistics in the wild (either by instrumenting the browser or any other means). - some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized. - some proof that there is others way to achieve the same result that are better. It appears to me that the the unprefixed version will be a better alternative in this case since the websites can just use the same API on all spec-compliant browsers if ArrayBuffer is supported in the unprefixed version. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote: I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm still unsure how to proceed with removing webkitPostMessage and aligning postMessage with the spec. No one responded to my earlier message, so I'm inclined to just post a patch. Comparing your post to the recommended steps on that page (the page says the same steps should be applied to removing only the prefixed version of a feature): It looks like you did this: * Any deprecation should be sent to webkit-dev for discussion. Yes. It doesn't look like you did any of these yet: * Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify: * usage statistics in the wild (either by instrumenting the browser or any other means). * some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized. * some proof that there is others way to achieve the same result that are better. On Sun, Apr 29, 2012 at 12:53 PM, Ryosuke Niwa rn...@webkit.org wrote: It appears to me that the the unprefixed version will be a better alternative in this case since the websites can just use the same API on all spec-compliant browsers if ArrayBuffer is supported in the unprefixed version. Agreed. On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.com wrote: * some proof that web-developers don't care much about this feature. * ... It seems like this hasn't really happened but you did give people due notice: * If several vendors are supporting the feature, we expect people to have interacted with them to assess their support towards the removal. == I can add that I'm not aware of any WebKit-specific content at Apple that uses webkitPostMessage. Great. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Deprecating features guideline wiki
On Sun, Apr 29, 2012 at 12:37 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 27, 2012, at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: BTW, the page at https://trac.webkit.org/wiki/DeprecatingFeatures seems to be using deprecate in the sense of remove entirely. Is that what is meant? If so, I think it would be helpful to change the wording to removing features. In non-Web contexts, deprecate often means a step short of removal. I agree that Removing features is clearer and more to the point :). When to deprecate features in the sense of we recommend you use this other feature instead is an entirely different conversation. Now that I look closer, I see that it says: Deprecating a feature means we will remove it in the future. Deprecation is not meant as a usage metric collection or to assess web-developers' reactions. This seems to imply that there actually is a step of deprecation that comes prior to removal. What exactly is this step? How are features supposed to be marked deprecated? What is the effect of being deprecated, if any, other than future removal? Does anyone who was at the session know the answer? I'd assume this is something like outputting a warning in the console. (Disclaimer: I didn't attend this session.) My own recommendation would be to just remove features that we've decided to remove. Any data gathering related to potential removal should happen before we make a decision. I agree that data needs to be gathered before making a decision to remove a feature. When we were discussing about adding mutation observer API in the hope to eventually remove the mutation events, we added histogram callbacks in WebKit (http://trac.webkit.org/changeset/100222) to figure out the API usage (in Chromium port). I also searched through js code in the wild via Google code search (unfortunately no longer available). But we did these data collections prior to removing the feature. In fact, even prior to proposing the replacement. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote: I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm still unsure how to proceed with removing webkitPostMessage and aligning postMessage with the spec. No one responded to my earlier message, so I'm inclined to just post a patch. Comparing your post to the recommended steps on that page (the page says the same steps should be applied to removing only the prefixed version of a feature): It looks like you did this: Any deprecation should be sent to webkit-dev for discussion. It doesn't look like you did any of these yet: Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify: usage statistics in the wild (either by instrumenting the browser or any other means). some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized. some proof that there is others way to achieve the same result that are better. It appears to me that the the unprefixed version will be a better alternative in this case since the websites can just use the same API on all spec-compliant browsers if ArrayBuffer is supported in the unprefixed version. Is there evidence that authors are either not using the prefixed version or are highly willing to migrate? I ask because another part of the policy says: The burden on the overall project needs to be evaluated as it should be the primary driver for dropping any feature. Small features that require very little maintenance may not qualify under this rule and their deprecation would need to be argued extensively. This implies to me that the burden of proof is higher for lower-maintenance-cost features (which I imagine applies to a prefixed method that also exists in unprefixed form). I'm not necessarily saying that lots of evidence is required in this case. But we can use this instance as a test case to adjust the policy. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Deprecating features guideline wiki
On Apr 29, 2012, at 1:04 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 12:37 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 27, 2012, at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: BTW, the page at https://trac.webkit.org/wiki/DeprecatingFeatures seems to be using deprecate in the sense of remove entirely. Is that what is meant? If so, I think it would be helpful to change the wording to removing features. In non-Web contexts, deprecate often means a step short of removal. I agree that Removing features is clearer and more to the point :). When to deprecate features in the sense of we recommend you use this other feature instead is an entirely different conversation. Now that I look closer, I see that it says: Deprecating a feature means we will remove it in the future. Deprecation is not meant as a usage metric collection or to assess web-developers' reactions. This seems to imply that there actually is a step of deprecation that comes prior to removal. What exactly is this step? How are features supposed to be marked deprecated? What is the effect of being deprecated, if any, other than future removal? Does anyone who was at the session know the answer? I'd assume this is something like outputting a warning in the console. (Disclaimer: I didn't attend this session.) That sounds plausible, but I'm hoping to hear from someone who attended the session to say for sure. If deprecate means console warning, followed by removal later, then I'd suggest we go straight to removal. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Deprecating features guideline wiki
On Sun, Apr 29, 2012 at 1:08 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 1:04 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 12:37 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 27, 2012, at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: BTW, the page at https://trac.webkit.org/wiki/DeprecatingFeatures seems to be using deprecate in the sense of remove entirely. Is that what is meant? If so, I think it would be helpful to change the wording to removing features. In non-Web contexts, deprecate often means a step short of removal. I agree that Removing features is clearer and more to the point :). When to deprecate features in the sense of we recommend you use this other feature instead is an entirely different conversation. Now that I look closer, I see that it says: Deprecating a feature means we will remove it in the future. Deprecation is not meant as a usage metric collection or to assess web-developers' reactions. This seems to imply that there actually is a step of deprecation that comes prior to removal. What exactly is this step? How are features supposed to be marked deprecated? What is the effect of being deprecated, if any, other than future removal? Does anyone who was at the session know the answer? I'd assume this is something like outputting a warning in the console. (Disclaimer: I didn't attend this session.) That sounds plausible, but I'm hoping to hear from someone who attended the session to say for sure. If deprecate means console warning, followed by removal later, then I'd suggest we go straight to removal. Outputting console warnings prior to a feature removal appears to be a common practice (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=749920). I'm also afraid that not giving any advance notice for features that have some users like mutation events might be perceived badly by developers. On the other hand, I'm certain we don't need to output console warnings if we're removing features nobody uses (e.g. support for khtml prefixes for recently added CSS properties). So we probably can't (and shouldn't) make a unilateral policy here. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Deprecating features guideline wiki
On Apr 29, 2012, at 1:18 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 1:08 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 1:04 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 12:37 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 27, 2012, at 6:29 PM, Dirk Pranke dpra...@chromium.org wrote: BTW, the page at https://trac.webkit.org/wiki/DeprecatingFeatures seems to be using deprecate in the sense of remove entirely. Is that what is meant? If so, I think it would be helpful to change the wording to removing features. In non-Web contexts, deprecate often means a step short of removal. I agree that Removing features is clearer and more to the point :). When to deprecate features in the sense of we recommend you use this other feature instead is an entirely different conversation. Now that I look closer, I see that it says: Deprecating a feature means we will remove it in the future. Deprecation is not meant as a usage metric collection or to assess web-developers' reactions. This seems to imply that there actually is a step of deprecation that comes prior to removal. What exactly is this step? How are features supposed to be marked deprecated? What is the effect of being deprecated, if any, other than future removal? Does anyone who was at the session know the answer? I'd assume this is something like outputting a warning in the console. (Disclaimer: I didn't attend this session.) That sounds plausible, but I'm hoping to hear from someone who attended the session to say for sure. If deprecate means console warning, followed by removal later, then I'd suggest we go straight to removal. Outputting console warnings prior to a feature removal appears to be a common practice (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=749920). I'm also afraid that not giving any advance notice for features that have some users like mutation events might be perceived badly by developers. On the other hand, I'm certain we don't need to output console warnings if we're removing features nobody uses (e.g. support for khtml prefixes for recently added CSS properties). So we probably can't (and shouldn't) make a unilateral policy here. I agree that it's a good idea to give content authors due notice. But I don't think a console warning is a very good way to do it. I think most authors pay no attention to console spam. A blog post would probably reach more authors successfully than a console warning. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote: I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm still unsure how to proceed with removing webkitPostMessage and aligning postMessage with the spec. No one responded to my earlier message, so I'm inclined to just post a patch. Comparing your post to the recommended steps on that page (the page says the same steps should be applied to removing only the prefixed version of a feature): It looks like you did this: - Any deprecation should be sent to webkit-dev for discussion. It doesn't look like you did any of these yet: - Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify: - usage statistics in the wild (either by instrumenting the browser or any other means). - some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized. - some proof that there is others way to achieve the same result that are better. It appears to me that the the unprefixed version will be a better alternative in this case since the websites can just use the same API on all spec-compliant browsers if ArrayBuffer is supported in the unprefixed version. Is there evidence that authors are either not using the prefixed version or are highly willing to migrate? I ask because another part of the policy says: The burden on the overall project needs to be evaluated as it should be the primary driver for dropping any feature. Small features that require very little maintenance may not qualify under this rule and their deprecation would need to be argued extensively. This implies to me that the burden of proof is higher for lower-maintenance-cost features (which I imagine applies to a prefixed method that also exists in unprefixed form). I'm not necessarily saying that lots of evidence is required in this case. But we can use this instance as a test case to adjust the policy. There is very little cost on the WebKit project to maintain webkitPostMessage in addition to postMessage. Instead, supporting webkitPostMessage imposes a cost on the web platform at large by reducing interoperability between browsers. I'm not sure that this is a good test case for the policy. The intent of https://trac.webkit.org/wiki/DeprecatingFeatures seems to be more about deleting features wholesale rather than simply removing vendor prefixes. Perhaps we should write different guidelines for removing vendor prefixes (e.g., related to specification maturity and implementation by other vendors). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
On Apr 29, 2012, at 1:35 PM, Adam Barth aba...@webkit.org wrote: There is very little cost on the WebKit project to maintain webkitPostMessage in addition to postMessage. Instead, supporting webkitPostMessage imposes a cost on the web platform at large by reducing interoperability between browsers. I'm not sure that this is a good test case for the policy. The intent of https://trac.webkit.org/wiki/DeprecatingFeatures seems to be more about deleting features wholesale rather than simply removing vendor prefixes. Perhaps we should write different guidelines for removing vendor prefixes (e.g., related to specification maturity and implementation by other vendors). I think the intent of the Deprecating a prefixed feature section is that the same policy applies to removing only the prefixed version of a feature that exists unprefixed, as to removing a feature entirely: Deprecating a prefixed feature should be treated as deprecating an existing features and should follow the previous steps. I don't know whether that makes sense or not. We can certainly come up with something different. It's almost always the case that the marginal maintenance burden for a prefixed feature that also exists in unprefixed form is very low. Does it make sense to say that, therefore, removal of the prefixed version should always be argued extensively? I do think there are some features where removing the prefixed version would cause lots of content to break, regardless of spec maturity or other implementations. So I'm not sure those can be the sole factors for removing a prefixed version of something. For example, it will likely be a long time, if ever, before we can remove support for -webkit-transform. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
On Apr 29, 2012, at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: I'm actually curious as to how the session participants reached this consensus (probably on a separate thread). It seems like the bar shouldn't too high for removing prefixed APIs when they are unprefixed equivalents because I'm certain web developers want to use the ones that work on all browsers instead of just on WebKit. Here's some evidence that Web developers do not always care about this, and that lack of support for webkit-prefixed properties can be detrimental to Web compatibility: http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/ Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
Maciej Stachowiak wrote: On Apr 29, 2012, at 1:25 PM, Ryosuke Niwarn...@webkit.org wrote: I'm actually curious as to how the session participants reached this consensus (probably on a separate thread). It seems like the bar shouldn't too high for removing prefixed APIs when they are unprefixed equivalents because I'm certain web developers want to use the ones that work on all browsers instead of just on WebKit. Here's some evidence that Web developers do not always care about this, and that lack of support for webkit-prefixed properties can be detrimental to Web compatibility: http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/ I agree with this, including the careful do not always and can be detrimental words ;-). This message may not be interesting to webkit-dev. Skip if you are not interested in prefix usage studies, what Mozilla might do about prefixes, etc. We have been studying prefix usage in: https://bugzilla.mozilla.org/show_bug.cgi?id=708406 The situation for Opera is much worse than for Mozilla for many properties, e.g. border-radius, where -moz- is often observed to be used alongside -webkit-. See in particular: https://bugzilla.mozilla.org/show_bug.cgi?id=708406#c39 The table's tabs don't lay out nicely in bugzilla. Here's my attempt at fixing the layout by hand: base_property num_domains num_rules pct_no_unprefixed_and_no_moz animation-count11 100.0 animation-delay5137 80.0 animation-direction810 62.5 animation-duration 73 324 87.9 animation-fill-mode23 50.0 animation-iteration-count 51 78 84.7 animation-name 72 756 87.6 animation-play-state 230.0 animation-timing-function 51 100 94.5 text-size-adjust 779 635299.5 transform-origin 68 196 56.9 transform-origin-y 230.0 transform-style35 50 100.0 transition-delay 19 53 63.2 transition-duration208 853 71.5 transition-property156 491 76.2 transition-timing 120.0 transition-timing-function 45 111 58.9 Clearly Mozilla feels Opera's pain for certain properties, e.g. text-size-adjust. Per the bug, 99.5% of 6352 found instances do not have unprefixed or -moz-prefixed equivalents of text-size-adjust. Lack of -webkit- prefix support may not be detrimental to a particular browser's mobile web compatibility where that browser engine's prefix (or no prefix) is widely used. It depends on the browser and the particular style property. So (just FYI) we at Mozilla are not contemplating emulating -webkit- quite so much as Opera may be. We do want to sort this all out in the CSS-WG and avoid unnecessary fragmentation. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding archive.org-based page loading time performance tests
On Fri, Apr 27, 2012 at 1:49 AM, Nat Duca nd...@chromium.org wrote: I'm concerned at how well this would work graphics performance tests. Consider: http://web.archive.org/web/20110111083848/http://techcrunch.com/ http://web.archive.org/web/20110222032916/http://www.nytimes.com/ http://web.archive.org/web/20110429194113/http://www.thewildernessdowntown.com/ What do we do for the cases where archive.org is getting bad/incomplete ... erm, archives? There's no fix to it. If archive.org doesn't work, then we need to pull data directly from the website. We can do that. The infrastructure I'm developing is agnostic of whether we use archive.org or not. However, pulling data directly from websites will make the test suite behave differently depending on when you run the test so the test suite can't be open that way. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] LayoutTestHelper
Hi folks, new-run-webkit-tests seems to mess with the system color profile on Mac, even when not running pixel tests. Historically, I believe we did this only when running pixel tests. I noticed that this is because it launches the LayoutTestHelper tool unconditionally, and in addition to changing the color profile on Mac, it also changes font smoothing settings on Windows. Does anyone know whether this work is required when running non-pixel tests? If not, I'd like to change NRWT to only launch LayoutTestHelper in pixel mode, and perhaps also rename LayoutTestHelper to PixelTestHelper. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTestHelper
On Apr 29, 2012, at 5:49 PM, Maciej Stachowiak m...@apple.com wrote: Hi folks, new-run-webkit-tests seems to mess with the system color profile on Mac, even when not running pixel tests. Historically, I believe we did this only when running pixel tests. I noticed that this is because it launches the LayoutTestHelper tool unconditionally, and in addition to changing the color profile on Mac, it also changes font smoothing settings on Windows. Does anyone know whether this work is required when running non-pixel tests? If not, I'd like to change NRWT to only launch LayoutTestHelper in pixel mode, and perhaps also rename LayoutTestHelper to PixelTestHelper. I went ahead assumed that this tool was never necessary for non-pixel tests, if I'm wrong, please comment here: https://bugs.webkit.org/show_bug.cgi?id=81729 Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
On Sun, Apr 29, 2012 at 2:25 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 1:35 PM, Adam Barth aba...@webkit.org wrote: There is very little cost on the WebKit project to maintain webkitPostMessage in addition to postMessage. Instead, supporting webkitPostMessage imposes a cost on the web platform at large by reducing interoperability between browsers. I'm not sure that this is a good test case for the policy. The intent of https://trac.webkit.org/wiki/DeprecatingFeatures seems to be more about deleting features wholesale rather than simply removing vendor prefixes. Perhaps we should write different guidelines for removing vendor prefixes (e.g., related to specification maturity and implementation by other vendors). I think the intent of the Deprecating a prefixed feature section is that the same policy applies to removing only the prefixed version of a feature that exists unprefixed, as to removing a feature entirely: Deprecating a prefixed feature should be treated as deprecating an existing features and should follow the previous steps. I don't know whether that makes sense or not. We can certainly come up with something different. It's almost always the case that the marginal maintenance burden for a prefixed feature that also exists in unprefixed form is very low. Does it make sense to say that, therefore, removal of the prefixed version should always be argued extensively? Honestly, if you make people argue extensively, they're just not going to bother. I do think there are some features where removing the prefixed version would cause lots of content to break, regardless of spec maturity or other implementations. So I'm not sure those can be the sole factors for removing a prefixed version of something. For example, it will likely be a long time, if ever, before we can remove support for -webkit-transform. Sure, but we're not talking about -webkit-transform. Rather than trying to find the grand unified theory of vendor prefixing, I'm inclined to just remove webkitPostMessage given that postMessage incorporates the new functionality. If we run into compat problems down the road, we can figure out what to do then. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
On Apr 29, 2012, at 6:42 PM, Adam Barth aba...@webkit.org wrote: On Sun, Apr 29, 2012 at 2:25 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 1:35 PM, Adam Barth aba...@webkit.org wrote: There is very little cost on the WebKit project to maintain webkitPostMessage in addition to postMessage. Instead, supporting webkitPostMessage imposes a cost on the web platform at large by reducing interoperability between browsers. I'm not sure that this is a good test case for the policy. The intent of https://trac.webkit.org/wiki/DeprecatingFeatures seems to be more about deleting features wholesale rather than simply removing vendor prefixes. Perhaps we should write different guidelines for removing vendor prefixes (e.g., related to specification maturity and implementation by other vendors). I think the intent of the Deprecating a prefixed feature section is that the same policy applies to removing only the prefixed version of a feature that exists unprefixed, as to removing a feature entirely: Deprecating a prefixed feature should be treated as deprecating an existing features and should follow the previous steps. I don't know whether that makes sense or not. We can certainly come up with something different. It's almost always the case that the marginal maintenance burden for a prefixed feature that also exists in unprefixed form is very low. Does it make sense to say that, therefore, removal of the prefixed version should always be argued extensively? Honestly, if you make people argue extensively, they're just not going to bother. I do think there are some features where removing the prefixed version would cause lots of content to break, regardless of spec maturity or other implementations. So I'm not sure those can be the sole factors for removing a prefixed version of something. For example, it will likely be a long time, if ever, before we can remove support for -webkit-transform. Sure, but we're not talking about -webkit-transform. Rather than trying to find the grand unified theory of vendor prefixing, I'm inclined to just remove webkitPostMessage given that postMessage incorporates the new functionality. If we run into compat problems down the road, we can figure out what to do then. I think the relevant question is how much (if any) content uses webkitPostMessage (without unprefixed postMessage fallback). The fact that postMessage incorporates the new functionality doesn't answer that question. I'm willing to believe almost no one uses it, but I don't have any evidence for this proposition. The proposed deprecation process reasonably asks for some kind of evidence. I don't think delete and see what breaks is a good way to gather the relevant info, either in this case, or in general. I am sure there are low-cost ways to gather some concrete information about usage. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkitPostMessage
On Apr 29, 2012, at 6:56 PM, Maciej Stachowiak m...@apple.com wrote: I think the relevant question is how much (if any) content uses webkitPostMessage (without unprefixed postMessage fallback). The fact that postMessage incorporates the new functionality doesn't answer that question. I'm willing to believe almost no one uses it, but I don't have any evidence for this proposition. The proposed deprecation process reasonably asks for some kind of evidence. I don't think delete and see what breaks is a good way to gather the relevant info, either in this case, or in general. I am sure there are low-cost ways to gather some concrete information about usage. So, after thinking about it, perhaps this thread just indicates that the deprecation policy is not ready for prime time when it comes to prefixes. For now, maybe it makes sense to just apply a standard of if no one objects. In the longer term, here's a few things we should think about: - Historically, we've almost never removed prefixed versions of features that get promoted to unprefixed. The marginal maintenance cost is low and there's usually some nonzero compat benefit. We have not usually considered benefit to the Web platform as a whole to be a major deciding factor. Should we change this assumption, and start removing prefixed versions of features more aggressively? - Does prefixing work well for JavaScript APIs (as opposed to CSS properties)? For whatever reason it seems more disruptive. What should be our approach to adding prefixed JS APIs, and at what point should we promote them to unprefixed? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
On Sun, Apr 29, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.comwrote: On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote: I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm still unsure how to proceed with removing webkitPostMessage and aligning postMessage with the spec. No one responded to my earlier message, so I'm inclined to just post a patch. Comparing your post to the recommended steps on that page (the page says the same steps should be applied to removing only the prefixed version of a feature): It looks like you did this: - Any deprecation should be sent to webkit-dev for discussion. It doesn't look like you did any of these yet: - Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify: - usage statistics in the wild (either by instrumenting the browser or any other means). - some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized. - some proof that there is others way to achieve the same result that are better. It appears to me that the the unprefixed version will be a better alternative in this case since the websites can just use the same API on all spec-compliant browsers if ArrayBuffer is supported in the unprefixed version. Is there evidence that authors are either not using the prefixed version or are highly willing to migrate? I ask because another part of the policy says: The burden on the overall project needs to be evaluated as it should be the primary driver for dropping any feature. Small features that require very little maintenance may not qualify under this rule and their deprecation would need to be argued extensively. This implies to me that the burden of proof is higher for lower-maintenance-cost features (which I imagine applies to a prefixed method that also exists in unprefixed form). I'm not necessarily saying that lots of evidence is required in this case. But we can use this instance as a test case to adjust the policy. I'm actually curious as to how the session participants reached this consensus (probably on a separate thread). It seems like the bar shouldn't too high for removing prefixed APIs when they are unprefixed equivalents because I'm certain web developers want to use the ones that work on all browsers instead of just on WebKit. The discussion went like this: It is good to remove vendor prefixed features in favor of their standardized, unprefixed forms. However, the process for removing a vendor prefixed feature is the same as the process for removing any feature. In both cases, we care about the impact to users of WebKit-based products. The vendor prefix just provides motivation for wanting to remove a feature. It doesn't necessarily make it any easier to remove a feature. Just as we announce feature addition on webkit-dev, I think it is a good idea to announce feature removal on webkit-dev. -- If we have data to indicate that a feature is nearly unused, then removing the feature straight-away seems good. We can learn quickly if we made a mistake. -- If we have data to indicate that a feature is somewhat used, then we can still deprecate it, but we probably need to take our time, complain in the JS console about deprecated API usage for some time, and then remove the feature from trunk and see who complains. -- If we have data to indicate that a feature is highly used, then perhaps we are stuck with the feature. We may have some hard discussions here if someone is truly motivated to remove such a feature. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
