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] 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] 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] 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] 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] webkitPostMessage
[+dslomov]
I found a thread on public-webapps that seems related to this
question. Dmitry, do you know what current status is here? I'd like
to make sure we're on a path towards interoperability with other
browsers.
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] webkitPostMessage
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
