Web Intents on WebApps' May 1-2 f2f meeting agenda?
Hi James, Greg, All - in case you did not know, WebApps is having a f2f meeting May 1-2 in Mountain View (logistical details below). Given Web Intents is a joint deliverable with WebApps, perhaps it would be useful to allocate some agenda time for Web Intents e.g. an update on the status, plans, etc. If we do want to allocate some time, we can of course use the W3C voice conference bridge to facilitate remote participants but we would need to nail down the day + time slot. WDYT? -AB Begin forwarded message: Resent-From: public-webapps@w3.org From: ext Arthur Barstow art.bars...@nokia.com Date: April 9, 2012 9:40:28 AM EDT To: public-webapps public-webapps@w3.org Subject: Reminder: May 1-2 f2f meeting: registration deadline is April 16 archived-at: http://www.w3.org/mid/046aa975-d33f-4b99-9b57-13c0739e7...@nokia.com Reminder: April 16 is the deadline to register for WebApps' May 1-2 f2f meeting http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. Please send agenda topic proposals to the list or add them to the meeting page http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. -Thanks, AB Begin forwarded message: Resent-From: public-webapps@w3.org From: ext Arthur Barstow art.bars...@nokia.com Date: March 15, 2012 8:13:54 AM EDT To: public-webapps public-webapps@w3.org Subject: Call for Agenda Topics: May 1-2 f2f meeting; Registration deadline April 16 archived-at: http://www.w3.org/mid/4f61dd02.2000...@nokia.com Hi All, I created a meeting page for our May 1-2 f2f meeting at a Microsoft facility in the Silicon Valley http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. Participants must register for this meeting via https://www.w3.org/2002/09/wbs/1/webappshtml-s2012--meeting/ and the deadline for registration is April 16. As we have done with our previous f2f meetings, I propose a mixture of pre-determined topics and topics agreed at the meeting. As such, please consider this as a call for agenda topics and if so desired, include a proposed day + time slot for the topic. Since WebApps' revised charter http://www.w3.org/2012/03/webapps-proposed-charter.html should be formally approved by the meeting, I think we should consider all of our new specs as potential candidates for agenda topics. -Thanks, ArtB
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
wrote:
Sounds great to me. The ports attribute is basically useless except in
this
one instance since ports are these days expose as part of structured
clones.
Avoiding using it in this arguably weird way in this one instance seems
like a win to me.
I'd like to have an opinion from WebKit and Microsoft about this proposal.
Can someone comment or cc relevant people, please?
FWIW this to me seems like a good improvement to the intuitiveness. Since
a MessageEvent interface is being used, qualifying that *source* WindowProxy
is populated is all that's needed?
cheers
/ Jonas
On Wednesday, April 4, 2012, Simon Pieters wrote:
Hi,
In Opera Extensions we use something that resembles shared workers. One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.
I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.
What do people think?
currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }
proposed change:
onconnect = function(e) { e.source.postMessage('pong') }
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org
wrote:
On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
wrote:
Sounds great to me. The ports attribute is basically useless except in
this
one instance since ports are these days expose as part of structured
clones.
Avoiding using it in this arguably weird way in this one instance seems
like a win to me.
I'd like to have an opinion from WebKit and Microsoft about this
proposal.
Can someone comment or cc relevant people, please?
FWIW this to me seems like a good improvement to the intuitiveness.
OK. To make things clear, are you OK with making this change in WebKit?
Since
a MessageEvent interface is being used, qualifying that *source*
WindowProxy
is populated is all that's needed?
It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
IDL for MessageEvent's source member would need to change type from
WindowProxy? to object?.
cheers
/ Jonas
On Wednesday, April 4, 2012, Simon Pieters wrote:
Hi,
In Opera Extensions we use something that resembles shared workers.
One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.
I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.
What do people think?
currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }
proposed change:
onconnect = function(e) { e.source.postMessage('pong') }
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
Re: Reminder: May 1-2 f2f meeting: registration deadline is April 16
Art, I added the item below to the wiki: Use cases and requirements for extending Server-Sent Events to support other bearers / underlying protocols: related to the proposed charter update item for Server-Sent Events extended to work with other push notification schemes such as Push SMS. Thanks, Bryan Sullivan From: Arthur Barstow art.bars...@nokia.com Date: Mon, 9 Apr 2012 09:40:28 -0400 To: public-webapps public-webapps@w3.org Subject: Reminder: May 1-2 f2f meeting: registration deadline is April 16 Resent-From: public-webapps@w3.org Resent-Date: Mon, 09 Apr 2012 13:40:49 + Reminder: April 16 is the deadline to register for WebApps' May 1-2 f2f meeting http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. Please send agenda topic proposals to the list or add them to the meeting page http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. -Thanks, AB Begin forwarded message: Resent-From: public-webapps@w3.org From: ext Arthur Barstow art.bars...@nokia.com Date: March 15, 2012 8:13:54 AM EDT To: public-webapps public-webapps@w3.org Subject: Call for Agenda Topics: May 1-2 f2f meeting; Registration deadline April 16 archived-at: http://www.w3.org/mid/4f61dd02.2000...@nokia.com Hi All, I created a meeting page for our May 1-2 f2f meeting at a Microsoft facility in the Silicon Valley http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. Participants must register for this meeting via https://www.w3.org/2002/09/wbs/1/webappshtml-s2012--meeting/ and the deadline for registration is April 16. As we have done with our previous f2f meetings, I propose a mixture of pre-determined topics and topics agreed at the meeting. As such, please consider this as a call for agenda topics and if so desired, include a proposed day + time slot for the topic. Since WebApps' revised charter http://www.w3.org/2012/03/webapps-proposed-charter.html should be formally approved by the meeting, I think we should consider all of our new specs as potential candidates for agenda topics. -Thanks, ArtB
New public mailing list for discussions on potential NFC work at W3C
At the suggestion of my W3C Team colleagues, I have created a new public mailing list for discussions of potential W3C work on Near Field Communications. The aim is to consider the scope, use cases and work items for W3C work on NFC APIs. The mailing list archive is accessible by anyone. Email address: public-...@w3.org Archived at: http://lists.w3.org/Archives/Public/public-nfc/ If people think it appropriate I will ask for a new W3C wiki on NFC. Let me know what you think. At this point, there has been no decision on which existing or new working group would deal with NFC, and your thoughts on where to address NFC are welcome. p.s. anyone will be able to subscribe to this list and participate in the discussions without any commitment to the W3C Patent Policy. Such commitments would however be necessary to participate in any W3C Community Group or Working Group that we choose to set up to progress this work further. -- Dave Raggett d...@w3.org http://www.w3.org/People/Raggett
Re: File API oneTimeOnly is too poorly defined
On Mon, Apr 9, 2012 at 3:52 PM, Feras Moussa fer...@microsoft.com wrote:
We agree that the spec text should be updated to more clearly define what
dereference means.
When we were trying to solve this problem, we looked for a simple and
consistent way that a developer can understand what dereferencing is.
What we came up with was the following definition: revoking should happen at
the first time that any of the bits of the BLOB are accessed.
This is a simple concept for a developer to understand, and is not complex to
spec or implement. This also helps avoid having to explicitly spec
out in the File API spec the various edge cases that different APIs exhibit –
such as XHR open/send versus imgtag.src load versus css link href
versus when a URL gets resolved or not. Instead those behaviors will continue
to be documented in their respective spec.
The definition above would imply that some cases, such as a
cross-site-of-origin request to a Blob URL do not revoke, but we think that
is OK
since it implies a developer error. If we use the above definition for
dereferencing, then in the XHR example you provided, xhr.send would
be responsible for revoking the URL.
Depending on how you define accessing the bits I think this has the
risk of resulting in quite a few race conditions, both in a single
implementation, as well as across implementations.
For example, the following code:
url = URL.createObjectURL(blob, { oneTimeOnly: true; });
myImg.src = url;
setTimeout(function() { myOtherImg.src = url }, 0);
Assuming that the blob is backed by a OS file, this will start reading
the bits from the blob as soon as the IO thread is free to read from
the requested file. When that is depends on a lot of other things,
such as what happens in other tabs, what other actions did the page
just do, how much of a back-log does the IO thread currently have etc.
In gecko things are even worse since blobs can be backed by either OS
files, or by memory, or a combination thereof. We plan to use various
optimizations for determining which backing type to use. For example
if you get a blob from a WebSocket connection, it might depend on how
much data was downloaded before .binaryType was set to blob as well
as how big the websocket frame is.
So if what you have is a memory backed blob then accessing the bits
will likely happen sooner making it more likely that the above code
snippet will fail to load the second image.
I would expect other browsers to use other strategies for what backing
stores to use, introducing more uncertainty.
Like Glenn points out, basically all of the situations we are talking
about are error conditions. The way you should use the url after using
oneTimeOnly is to load from it exactly once. Anything else is an
error for some definition of an error. But we all know that people
use web APIs in ways we wish they didn't. Intentionally or
accidentally.
What will happen for the following three code snippets in IE?
1.
url = URL.createObjectURL(blob, { oneTimeOnly: true; });
myImg.src = url;
setTimeout(function() { myOtherImg.src = url }, 0);
2.
url = URL.createObjectURL(blob);
myImg.src = url;
setTimeout(function() { URL.revokeObjectURL(url) }, 0);
3.
url = URL.createObjectURL(blob);
myImg.src = url;
URL.revokeObjectURL(url);
/ Jonas
Re: Delay in File * spec publications in /TR/ [Was: CfC: publish LCWD of File API; deadline March 3]
On Mar 30, 2012, at 2:25 PM, ext Eric U wrote: On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow art.bars...@nokia.com wrote: Hi All - the publication of the File API LC was delayed because of some logistical issues for Arun as well as some additional edits he intends to make. This delay also resulted in Eric's two File * specs not being published since they have a dependency on the latest File API spec. Arun - can you please give us at least a rough idea when you expect the spec to be ready for LC publication? Jonas - as co-Editor of File API, can you help get the File API LC published? Eric - your File * docs were last published in April 2011 so I think it would be good to get new versions published in /TR/ soon-ish. OTOH, if they have dependencies on the latest File API, it may be better to postpone their publication until File API is published. WDYT? If it's going to be more than a month to get Arun+Jonas's spec up, we might as well go ahead and publish mine; they've had quite a bit of change. If it's less than that, let's just do them all together. Eric - I haven't received any responses from Arun or Jonas so I will contact you off list about getting your two File specs ready for publication on /TR/. -Thanks, Art
Re: Shared workers - use .source instead of .ports[0] ?
I'll agree that having to use ports[0] to access the MessagePort in a
connect event has always felt a bit like an API wart. However, I don't
entirely recall why we wanted to have the connect event use the
MessageEvent interface. So I'd be uncomfortable with changing connect event
to not match that interface without understanding why we made those
interfaces match in the first place (perhaps Ian can chime in here).
I'll also note that the MessageEvent for cross-document messaging has a
|ports| attribute, so I'm not certain why removing this attribute on the
connect event makes it closer to the [cross-document messaging] API - can
you clarify your reasoning here? Also, since MessagePort is not a
WindowProxy, I'm not sure we want to encourage developers to treat them as
the same by putting them both as the |source| attribute in MessageEvents in
different contexts, especially since the postMessage() APIs don't precisely
match.
-atw
On Tue, Apr 10, 2012 at 5:27 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org
wrote:
On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
wrote:
Sounds great to me. The ports attribute is basically useless except in
this
one instance since ports are these days expose as part of structured
clones.
Avoiding using it in this arguably weird way in this one instance seems
like a win to me.
I'd like to have an opinion from WebKit and Microsoft about this
proposal.
Can someone comment or cc relevant people, please?
FWIW this to me seems like a good improvement to the intuitiveness.
OK. To make things clear, are you OK with making this change in WebKit?
Since
a MessageEvent interface is being used, qualifying that *source*
WindowProxy
is populated is all that's needed?
It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
IDL for MessageEvent's source member would need to change type from
WindowProxy? to object?.
cheers
/ Jonas
On Wednesday, April 4, 2012, Simon Pieters wrote:
Hi,
In Opera Extensions we use something that resembles shared workers. One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.
I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.
What do people think?
currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }
proposed change:
onconnect = function(e) { e.source.postMessage('pong') }
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, Apr 10, 2012 at 8:27 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org
wrote:
On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
wrote:
Sounds great to me. The ports attribute is basically useless except in
this
one instance since ports are these days expose as part of structured
clones.
Avoiding using it in this arguably weird way in this one instance seems
like a win to me.
I'd like to have an opinion from WebKit and Microsoft about this
proposal.
Can someone comment or cc relevant people, please?
FWIW this to me seems like a good improvement to the intuitiveness.
OK. To make things clear, are you OK with making this change in WebKit?
Since
a MessageEvent interface is being used, qualifying that *source*
WindowProxy
is populated is all that's needed?
It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
IDL for MessageEvent's source member would need to change type from
WindowProxy? to object?.
I think this ought to be considered as a last resort until we understand
the ramifications. On a personal note, I think having *source* mean
different things in different contexts would introduce confusion and is not
in line with least-surprise. Perhaps hixie can weigh in on this proposal.
cheers
/ Jonas
On Wednesday, April 4, 2012, Simon Pieters wrote:
Hi,
In Opera Extensions we use something that resembles shared workers. One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.
I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.
What do people think?
currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }
proposed change:
onconnect = function(e) { e.source.postMessage('pong') }
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs
changed to support object transfers after we defined the connect event
structure, so it's not unreasonable that we should take another look at the
connect event to try to make it match the current definition of
postMessage().
I think the model of connect event we've used in the past
(pre-structure-clone-transfer) is as if the creator of the SharedWorker
were sending a message like so:
postMessage(, [newPort]);
The recipient then receives a MessageEvent with data= and ports=[newPort].
In the new world where postMessage() supports a transfer object, I think
the appropriate analogous connect event would be to result in a
MessageEvent with both the |data| and |ports| attributes pointing at an
array containing a single MessagePort. I don't think putting the
MessagePort as the source attribute is the right model.
-atw
On Tue, Apr 10, 2012 at 10:33 AM, Andrew Wilson atwil...@google.com wrote:
I'll agree that having to use ports[0] to access the MessagePort in a
connect event has always felt a bit like an API wart. However, I don't
entirely recall why we wanted to have the connect event use the
MessageEvent interface. So I'd be uncomfortable with changing connect event
to not match that interface without understanding why we made those
interfaces match in the first place (perhaps Ian can chime in here).
I'll also note that the MessageEvent for cross-document messaging has a
|ports| attribute, so I'm not certain why removing this attribute on the
connect event makes it closer to the [cross-document messaging] API - can
you clarify your reasoning here? Also, since MessagePort is not a
WindowProxy, I'm not sure we want to encourage developers to treat them as
the same by putting them both as the |source| attribute in MessageEvents in
different contexts, especially since the postMessage() APIs don't precisely
match.
-atw
On Tue, Apr 10, 2012 at 5:27 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org
wrote:
On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote:
On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc
wrote:
Sounds great to me. The ports attribute is basically useless except in
this
one instance since ports are these days expose as part of structured
clones.
Avoiding using it in this arguably weird way in this one instance seems
like a win to me.
I'd like to have an opinion from WebKit and Microsoft about this
proposal.
Can someone comment or cc relevant people, please?
FWIW this to me seems like a good improvement to the intuitiveness.
OK. To make things clear, are you OK with making this change in WebKit?
Since
a MessageEvent interface is being used, qualifying that *source*
WindowProxy
is populated is all that's needed?
It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The
IDL for MessageEvent's source member would need to change type from
WindowProxy? to object?.
cheers
/ Jonas
On Wednesday, April 4, 2012, Simon Pieters wrote:
Hi,
In Opera Extensions we use something that resembles shared workers.
One
modification is that the 'connect' event's source port is exposed in
.source instead of in .ports[0], to make it closer to the API for
cross-document messaging. Maybe we should make this change to Shared
Workers as well.
I think shared workers hasn't seen wide adoption yet, so maybe changes
like this are still possible.
What do people think?
currently:
onconnect = function(e) { e.ports[0].postMessage('pong') }
proposed change:
onconnect = function(e) { e.source.postMessage('pong') }
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
--
Simon Pieters
Opera Software
RE: Shared workers - use .source instead of .ports[0] ?
-Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Tuesday, April 10, 2012 5:27 AM To: Jarred Nicholls Cc: Jonas Sicking; public-weba...@w3c.org Subject: Re: Shared workers - use .source instead of .ports[0] ? On Tue, 10 Apr 2012 14:01:47 +0200, Jarred Nicholls jar...@webkit.org wrote: On Tue, Apr 10, 2012 at 1:20 AM, Simon Pieters sim...@opera.com wrote: On Wed, 04 Apr 2012 18:37:46 +0200, Jonas Sicking jo...@sicking.cc wrote: Sounds great to me. The ports attribute is basically useless except in this one instance since ports are these days expose as part of structured clones. Avoiding using it in this arguably weird way in this one instance seems like a win to me. I'd like to have an opinion from WebKit and Microsoft about this proposal. Can someone comment or cc relevant people, please? FWIW this to me seems like a good improvement to the intuitiveness. OK. To make things clear, are you OK with making this change in WebKit? Since a MessageEvent interface is being used, qualifying that *source* WindowProxy is populated is all that's needed? It wouldn't be a WindowProxy, but a port. I'd also make .ports null. The IDL for MessageEvent's source member would need to change type from WindowProxy? to object?. IE10 does not implement SharedWorkers at the present time. We also don’t yet implement the updated Transferrable notion for MessagePorts in the structured clone algorithm. We do ship Workers now, and so my primary concern is that the spec doesn't remove the ports property of the MessageEvent. I don't mind the proposal to re-use .source of MessageEvent for a connect event on a SharedWorker. I think it's a bit ugly to swap the WindowProxy type of .source to any just for this case. I am curious to see where this latest discussion on perhaps using a different Event interface for connect events will lead...
Re: Web Intents on WebApps' May 1-2 f2f meeting agenda?
If we can schedule this for May 1, that would be fantastic. Unfortunately something last-minute has come up and I won't be able to attend May 2. Thanks, James On Tue, Apr 10, 2012 at 5:00 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi James, Greg, All - in case you did not know, WebApps is having a f2f meeting May 1-2 in Mountain View (logistical details below). Given Web Intents is a joint deliverable with WebApps, perhaps it would be useful to allocate some agenda time for Web Intents e.g. an update on the status, plans, etc. If we do want to allocate some time, we can of course use the W3C voice conference bridge to facilitate remote participants but we would need to nail down the day + time slot. WDYT? -AB Begin forwarded message: *Resent-From: *public-webapps@w3.org *From: *ext Arthur Barstow art.bars...@nokia.com *Date: *April 9, 2012 9:40:28 AM EDT *To: *public-webapps public-webapps@w3.org *Subject: **Reminder: May 1-2 f2f meeting: registration deadline is April 16* *archived-at: * http://www.w3.org/mid/046aa975-d33f-4b99-9b57-13c0739e7...@nokia.com Reminder: April 16 is the deadline to register for WebApps' May 1-2 f2f meeting http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. Please send agenda topic proposals to the list or add them to the meeting page http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. -Thanks, AB Begin forwarded message: *Resent-From: *public-webapps@w3.org *From: *ext Arthur Barstow art.bars...@nokia.com *Date: *March 15, 2012 8:13:54 AM EDT *To: *public-webapps public-webapps@w3.org *Subject: **Call for Agenda Topics: May 1-2 f2f meeting; Registration deadline April 16* *archived-at: *http://www.w3.org/mid/4f61dd02.2000...@nokia.com Hi All, I created a meeting page for our May 1-2 f2f meeting at a Microsoft facility in the Silicon Valley http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting. Participants must register for this meeting via https://www.w3.org/2002/09/wbs/1/webappshtml-s2012--meeting/ and the deadline for registration is April 16. As we have done with our previous f2f meetings, I propose a mixture of pre-determined topics and topics agreed at the meeting. As such, please consider this as a call for agenda topics and if so desired, include a proposed day + time slot for the topic. Since WebApps' revised charter http://www.w3.org/2012/03/webapps-proposed-charter.html should be formally approved by the meeting, I think we should consider all of our new specs as potential candidates for agenda topics. -Thanks, ArtB
Re: informal survey - on spec philosophy
This came up in… 2001 during the W3C QA Workshop which started the W3C QA activity. http://www.w3.org/2001/01/qa-ws/agenda.html Le 26 mars 2012 à 18:43, Tab Atkins Jr. a écrit : The statement you quoted is more or less accurate. Behavior that isn't specced is almost certain to not be interoperable. If the spec is incomplete or unclear in some aspect, that's a spec bug, not an opportunity for implementations to make up their own behavior based on what the engineer thinks is reasonable at the time they're writing the code. Specifically a position paper and presentation made by Thierry Kormann (Ilog): * Implementation Experience http://www.w3.org/2001/01/qa-ws/pp/thierry-kormann-ilog.htm * SLIDES http://www.w3.org/2001/01/qa-ws/slides/thierry-kormann-ilog.htm Thierry made the following point 'Implementation dependant' or unspecified behaviors are really dangerous After many discussions on www-qa-wg mailing list, we talked about optional features and the issues with interoperability. It eventually led to a few guidelines: * Good Practice 15: Use optional features as warranted. http://www.w3.org/TR/qaframe-spec/#need-option-gp * Good Practice 16: Clearly identify optional features. http://www.w3.org/TR/qaframe-spec/#label-options-gp It also fits in the space of extension, aka things which are not defined is a space for extensibility. People, companies will add more features. Sometimes these features are creating interoperability issues. So to try to avoid these, you might want to define an extension mechanism. We have seen that extension mechanisms might also create issues because of the nature of the Web (distributed and decentralized), a popular extension is not anymore an extension but a feature. * Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance. http://www.w3.org/TR/qaframe-spec/#breaking-conformance-gp * Good Practice 18: If extensibility is allowed, define an extension mechanism. http://www.w3.org/TR/qaframe-spec/#extensions-prohibited-gp -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
Exceptions for DOM-XPath
Hi All, We're currently cleaning out some of our error handling code and the turn has come to XPathException. The DOM4+WebIDL specs has created a nice set of exceptions which make it easier for authors to check for specific exceptions. You now only have to check .name (which is a string) rather than .code (which is a magic number) and which interface it implements (DOMException vs. Error vs. XPathException etc). So our plan is to for INVALID_EXPRESSION_ERR throw a SyntaxError (I.e. a DOMException) and for TYPE_ERR throw a plain JS TypeError. Unfortunately the DOM-XPath spec is no longer being maintained so there is noone to issue an Errata, but if this change sounds good to everyone we'll just update our documentation which should hopefully be enough to get authors aware. / Jonas
[DOM4] Question about collections versus maps
Hello,
I am working on updating the CSS Regions CSSOM APIs
(http://dev.w3.org/csswg/css3-regions/#cssom_view_and_css_regions). CSS
Regions adds a set of named flows (created by the flow-into property) to
the Document, currently as a collection:
partial interface Document {
readonly attribute NamedFlowCollection namedFlows;
NamedFlow? getFlowByName(DOMString name);
};
interface NamedFlowCollection {
readonly attribute unsigned long length;
getter NamedFlow? item (unsigned long index);
};
One suggestion we've received
(http://lists.w3.org/Archives/Public/www-style/2012Feb/0327.html) is to
replace the collection with a map, which I believe would look like this:
partial interface Document {
readonly attribute NamedFlowMap namedFlows;
};
interface NamedFlowMap {
getter NamedFlow? (DOMString name);
};
What is this group's API preference for a set of objects identified by
name?
Thanks,
Alan
Re: Exceptions for DOM-XPath
On Tue, 10 Apr 2012 21:30:02 +0200, Jonas Sicking jo...@sicking.cc wrote: We're currently cleaning out some of our error handling code and the turn has come to XPathException. The DOM4+WebIDL specs has created a nice set of exceptions which make it easier for authors to check for specific exceptions. You now only have to check .name (which is a string) rather than .code (which is a magic number) and which interface it implements (DOMException vs. Error vs. XPathException etc). So our plan is to for INVALID_EXPRESSION_ERR throw a SyntaxError (I.e. a DOMException) and for TYPE_ERR throw a plain JS TypeError. Unfortunately the DOM-XPath spec is no longer being maintained so there is noone to issue an Errata, but if this change sounds good to everyone we'll just update our documentation which should hopefully be enough to get authors aware. I (and others) maintain errata here for now: http://wiki.whatwg.org/wiki/DOM_XPath I guess we should also figure out how to deal with Attr nodes - Attr objects. -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOM4] Question about collections versus maps
On 4/10/12 3:35 PM, Alan Stearns wrote: What is this group's API preference for a set of objects identified by name? The real question is what the use cases are, no? The NamedFlowMap approach doesn't provide a good way to enumerate the named flows; if that's a use case that needs supporting, then you need API that allows it. -Boris
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, Apr 10, 2012 at 10:47 AM, Andrew Wilson atwil...@google.com wrote: To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs changed to support object transfers after we defined the connect event structure, so it's not unreasonable that we should take another look at the connect event to try to make it match the current definition of postMessage(). I think the model of connect event we've used in the past (pre-structure-clone-transfer) is as if the creator of the SharedWorker were sending a message like so: postMessage(, [newPort]); The recipient then receives a MessageEvent with data= and ports=[newPort]. In the new world where postMessage() supports a transfer object, I think the appropriate analogous connect event would be to result in a MessageEvent with both the |data| and |ports| attributes pointing at an array containing a single MessagePort. I don't think putting the MessagePort as the source attribute is the right model. Why make .data be an array containing a single MessagePort? Why not just make .data be the MessagePort object itself? The .ports property is basically a relic of the time before we had Transferrable objects. Even if we all end up implementing it, I think we should let authors ignore it once they don't care about down-level browsers. / Jonas
Re: [DOM4] Question about collections versus maps
On Tue, Apr 10, 2012 at 12:39 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/10/12 3:35 PM, Alan Stearns wrote: What is this group's API preference for a set of objects identified by name? The real question is what the use cases are, no? The NamedFlowMap approach doesn't provide a good way to enumerate the named flows; if that's a use case that needs supporting, then you need API that allows it. According to current WebIDL spec, an object with a named property getter exposes the list of names as own properties, so you can get them with for-in enumeration. ~TJ
Re: [DOM4] Question about collections versus maps
On 4/10/12 4:13 PM, Tab Atkins Jr. wrote: According to current WebIDL spec, an object with a named property getter exposes the list of names as own properties, so you can get them with for-in enumeration. 1) for-in enumeration enumerates prototype properties. 2) for-in enumeration enumerates expandos which might have nothing to do with the set of named properties. -Boris
Re: [DOM4] Question about collections versus maps
On Tue, Apr 10, 2012 at 1:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/10/12 4:13 PM, Tab Atkins Jr. wrote: According to current WebIDL spec, an object with a named property getter exposes the list of names as own properties, so you can get them with for-in enumeration. 1) for-in enumeration enumerates prototype properties. Yes, but prototype properties aren't own properties, so you can tell them apart. 2) for-in enumeration enumerates expandos which might have nothing to do with the set of named properties. It's not possible to set an expando on a map object like this. (The setter operation will either do something useful, or will reject the attempt to set.) ~TJ
Re: informal survey - on spec philosophy
A recent example from Canvas specification. http://html5.org/tools/web-apps-tracker?from=7030to=7031 p class=noteThis specification does not define the precise + algorithm to use when scaling an image when the code + title=dom-context-2d-imageSmoothingEnabledimageSmoothingEnabled/code + attribute is set to true./p It all depends on what you mean by interoperability and the expectations of users. I'm pretty sure that graphics designers will have a very strong opinion about smoothing being exactly the same for all browsers. -- Karl Dubost Montréal, QC, Canada http://www.la-grange.net/karl/
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, Apr 10, 2012 at 1:06 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 10, 2012 at 10:47 AM, Andrew Wilson atwil...@google.com wrote: To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs changed to support object transfers after we defined the connect event structure, so it's not unreasonable that we should take another look at the connect event to try to make it match the current definition of postMessage(). I think the model of connect event we've used in the past (pre-structure-clone-transfer) is as if the creator of the SharedWorker were sending a message like so: postMessage(, [newPort]); The recipient then receives a MessageEvent with data= and ports=[newPort]. In the new world where postMessage() supports a transfer object, I think the appropriate analogous connect event would be to result in a MessageEvent with both the |data| and |ports| attributes pointing at an array containing a single MessagePort. I don't think putting the MessagePort as the source attribute is the right model. Why make .data be an array containing a single MessagePort? Why not just make .data be the MessagePort object itself? That's fine with me as well. To be honest, I haven't been closely following the Transferable discussion, so I wasn't certain what the semantics of the |data| and |transfer| attributes were ( http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#messageport). If it's valid to just have |data| point directly at a Transferable rather than a-map-containing-Transferables then that's fine by me. The .ports property is basically a relic of the time before we had Transferrable objects. Even if we all end up implementing it, I think we should let authors ignore it once they don't care about down-level browsers. / Jonas
Re: [DOM4] Question about collections versus maps
On 4/10/12 4:23 PM, Tab Atkins Jr. wrote: On Tue, Apr 10, 2012 at 1:16 PM, Boris Zbarskybzbar...@mit.edu wrote: On 4/10/12 4:13 PM, Tab Atkins Jr. wrote: According to current WebIDL spec, an object with a named property getter exposes the list of names as own properties, so you can get them with for-in enumeration. 1) for-in enumeration enumerates prototype properties. Yes, but prototype properties aren't own properties, so you can tell them apart. Yes, but it's a huge pain that no one will actually remember to do. I didn't say there is _no_ way to enumerate the objects. I said there is no _good_ way. There's a difference. If you expect people to commonly need to enumerate the set of named flows, then there is something to be said for making it easy and safe, not hard and footgunny. 2) for-in enumeration enumerates expandos which might have nothing to do with the set of named properties. It's not possible to set an expando on a map object like this. (The setter operation will either do something useful, or will reject the attempt to set.) The setter for interfaces that support named properties is not applied to things outside the set of supported property names per current WebIDL [1]. So if the set of supported property names here is the set of flow names, then expandos with other names can be defined. The proposal on this list didn't actually say what the set of supported property names is, but the proposal at http://lists.w3.org/Archives/Public/www-style/2012Feb/0327.html does say that the supported property names are the flow names. -Boris [1] Specifically, http://dev.w3.org/2006/webapi/WebIDL/#defineownproperty step 3 is where we would end up. If the name is not a supported property name, 'creating' is set true in step 3.1. We enter step 3.2, because we do not have a property named P. Since 'creating' is true, we skip step 3.2.1. Since 'creating' is false and there is no named property creator, we skip step 3.2.2. So we end up in step 4, which just does a completely normal JS property set on the object; now we have an expando property.
Re: [DOM4] Question about collections versus maps
On Tue, Apr 10, 2012 at 1:49 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/10/12 4:23 PM, Tab Atkins Jr. wrote: On Tue, Apr 10, 2012 at 1:16 PM, Boris Zbarskybzbar...@mit.edu wrote: On 4/10/12 4:13 PM, Tab Atkins Jr. wrote: According to current WebIDL spec, an object with a named property getter exposes the list of names as own properties, so you can get them with for-in enumeration. 1) for-in enumeration enumerates prototype properties. Yes, but prototype properties aren't own properties, so you can tell them apart. Yes, but it's a huge pain that no one will actually remember to do. I didn't say there is _no_ way to enumerate the objects. I said there is no _good_ way. There's a difference. If you expect people to commonly need to enumerate the set of named flows, then there is something to be said for making it easy and safe, not hard and footgunny. Agreed, but ES6 is making this easier with Object.keys() and for-of iteration. (Off the top of my head, I can't come up with a use-case for enumerating all flows in a page anyway, beyond editing environments or the like.) 2) for-in enumeration enumerates expandos which might have nothing to do with the set of named properties. It's not possible to set an expando on a map object like this. (The setter operation will either do something useful, or will reject the attempt to set.) The setter for interfaces that support named properties is not applied to things outside the set of supported property names per current WebIDL [1]. So if the set of supported property names here is the set of flow names, then expandos with other names can be defined. The proposal on this list didn't actually say what the set of supported property names is, but the proposal at http://lists.w3.org/Archives/Public/www-style/2012Feb/0327.html does say that the supported property names are the flow names. -Boris [1] Specifically, http://dev.w3.org/2006/webapi/WebIDL/#defineownproperty step 3 is where we would end up. If the name is not a supported property name, 'creating' is set true in step 3.1. We enter step 3.2, because we do not have a property named P. Since 'creating' is true, we skip step 3.2.1. Since 'creating' is false and there is no named property creator, we skip step 3.2.2. So we end up in step 4, which just does a completely normal JS property set on the object; now we have an expando property. Sorry, I misspoke. You do indeed need to define a named property creator, which either does something useful or just rejects the creation. ~TJ
Re: [DOM4] Question about collections versus maps
On 4/10/12 5:05 PM, Tab Atkins Jr. wrote: Agreed, but ES6 is making this easier with Object.keys() and for-of iteration. Sort of. for-of doesn't necessarily work on this stuff, as I understand. (Off the top of my head, I can't come up with a use-case for enumerating all flows in a page anyway, beyond editing environments or the like.) That's a much stronger reason to go with a map, assuming the editing environment use cases are not a concern. Again, my point was that _if_ there are enumeration use cases then one needs to worry about this stuff. If there are no such use cases, then clearly it doesn't matter whether the API supports enumeration well. -Boris
Re: informal survey - on spec philosophy
Le 10 avr. 2012 à 22:25, Karl Dubost a écrit : A recent example from Canvas specification. http://html5.org/tools/web-apps-tracker?from=7030to=7031 p class=noteThis specification does not define the precise + algorithm to use when scaling an image when the code + title=dom-context-2d-imageSmoothingEnabledimageSmoothingEnabled/code + attribute is set to true./p It all depends on what you mean by interoperability and the expectations of users. I'm pretty sure that graphics designers will have a very strong opinion about smoothing being exactly the same for all browsers. I'm sure to be alone, but for the bitterness, here's another such story we had till two weeks ago: The upgrade to iOS5 broke, for all iPad users, the search function on our website, www.curriki.org. It took us several weeks of debugging, not understanding the single message of debugging inside the console: undefined is not an object (no location). At the end it turned out that the iOS5 upgrade had changed the way javascript parses Date.parse(). Suddenly, the result was undefined and the subsequent printf, given an undefined, sent that odd message. Anywhere you look, Date.parse is left to browser interpretation with the only available standard, ISO-8601, not even being fully implemented in the modern browsers. The very informal w3c note is implemented, while this standard is too big. Does HTML5 change this? I'd be glad to hear this. Is there a way to flag things so that developers routinely protect against unpredictability? paul
[XHR] XMLHttpRequest.send()
Hi All, Our understanding of the current spec is that if someone calls the send function and pass as the body to be sent, this is almost equivalent to not passing a body at all. However, it still changes which Content-Type header is set. Consider the following code: xhr = new XMLHttpRequest; xhr.open(POST, url); xhr.send(); The current spec seems to say that this should set the Content-Type request header to text/plain with a utf8 charset. However it seems a bit strange to me to set this header when absolutely no request body is sent. I had expected that xhr.send(), xhr.send(null) and xhr.send() all would have the same behavior. The same thing happens if you pass a object which has a toString function which returns . Is this intentional? This does match what Gecko does, but we are willing to change this if others agree that it's a better behavior. / Jonas
Re: [XHR] XMLHttpRequest.send()
On Wed, 11 Apr 2012 00:08:47 +0200, Jonas Sicking jo...@sicking.cc wrote: Is this intentional? This does match what Gecko does, but we are willing to change this if others agree that it's a better behavior. Yes, the idea is that you can transmit both the empty entity body and no entity body. The former will also have a Content-Length header set. Whether it is useful to have both... -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] XMLHttpRequest.send()
On Tue, Apr 10, 2012 at 5:21 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 11 Apr 2012 00:08:47 +0200, Jonas Sicking jo...@sicking.cc wrote: Is this intentional? This does match what Gecko does, but we are willing to change this if others agree that it's a better behavior. Yes, the idea is that you can transmit both the empty entity body and no entity body. The former will also have a Content-Length header set. Whether it is useful to have both... I'd find it very surprising if send(getSomeString()) resulted in a different Content-Type depending on the length of the string. A zero-length string is still a string. -- Glenn Maynard
Re: [XHR] XMLHttpRequest.send()
On Tue, Apr 10, 2012 at 3:37 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 10, 2012 at 5:21 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 11 Apr 2012 00:08:47 +0200, Jonas Sicking jo...@sicking.cc wrote: Is this intentional? This does match what Gecko does, but we are willing to change this if others agree that it's a better behavior. Yes, the idea is that you can transmit both the empty entity body and no entity body. The former will also have a Content-Length header set. Whether it is useful to have both... I'd find it very surprising if send(getSomeString()) resulted in a different Content-Type depending on the length of the string. A zero-length string is still a string. Is it more surprising than that .send() and .send(hasSomethingToSend() ? getTheThingToSend() : ) sets a Content-Type even when no body is submitted? / Jonas
Re: [XHR] XMLHttpRequest.send()
On Tue, Apr 10, 2012 at 3:42 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 10, 2012 at 3:37 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 10, 2012 at 5:21 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 11 Apr 2012 00:08:47 +0200, Jonas Sicking jo...@sicking.cc wrote: Is this intentional? This does match what Gecko does, but we are willing to change this if others agree that it's a better behavior. Yes, the idea is that you can transmit both the empty entity body and no entity body. The former will also have a Content-Length header set. Whether it is useful to have both... I'd find it very surprising if send(getSomeString()) resulted in a different Content-Type depending on the length of the string. A zero-length string is still a string. Is it more surprising than that .send() and .send(hasSomethingToSend() ? getTheThingToSend() : ) sets a Content-Type even when no body is submitted? Err.. sorry, that should say: Is it more surprising than that xhr.send(hasSomethingToSend() ? getTheThingToSend() : ); sets the Content-Type header even when no body is submitted? / Jonas
Re: [XHR] XMLHttpRequest.send()
On Tue, Apr 10, 2012 at 5:50 PM, Jonas Sicking jo...@sicking.cc wrote: Is it more surprising than that xhr.send(hasSomethingToSend() ? getTheThingToSend() : ); sets the Content-Type header even when no body is submitted? That's exactly what I would expect. A body that happens to have a zero length is still valid text/plain data. If you want to omit Content-Type in the above case, then you should write: xhr.send(hasSomethingToSend() ? getTheThingToSend() : null); -- Glenn Maynard
Re: [XHR] XMLHttpRequest.send()
On Tue, Apr 10, 2012 at 3:58 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 10, 2012 at 5:50 PM, Jonas Sicking jo...@sicking.cc wrote: Is it more surprising than that xhr.send(hasSomethingToSend() ? getTheThingToSend() : ); sets the Content-Type header even when no body is submitted? That's exactly what I would expect. A body that happens to have a zero length is still valid text/plain data. If you want to omit Content-Type in the above case, then you should write: xhr.send(hasSomethingToSend() ? getTheThingToSend() : null); Or, of course: if(hasSomethingToSend()) xhr.send(getTheThingToSend()); ~TJ
Re: [XHR] XMLHttpRequest.send()
On Tue, Apr 10, 2012 at 4:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 10, 2012 at 3:58 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 10, 2012 at 5:50 PM, Jonas Sicking jo...@sicking.cc wrote: Is it more surprising than that xhr.send(hasSomethingToSend() ? getTheThingToSend() : ); sets the Content-Type header even when no body is submitted? That's exactly what I would expect. A body that happens to have a zero length is still valid text/plain data. I'm not sure everyone is sharing that expectation. If you want to omit Content-Type in the above case, then you should write: xhr.send(hasSomethingToSend() ? getTheThingToSend() : null); Or, of course: if(hasSomethingToSend()) xhr.send(getTheThingToSend()); That isn't terribly useful if you're trying to get a response... If I'm the only one who prefer the other behavior then we should stick to what the spec already says. I'll make sure Gecko maintains that behavior as we implement our new WebIDL bindings. / Jonas
Re: Draft report for offline apps workshop
On 4/7/12 1:42 PM, Arthur Barstow art.bars...@nokia.com wrote: I kinda' recall there was a proposal in the HTML WG to move the app cache functionality to a separate spec. Does anyone know the status of that proposal? I don't know what the status is, but we'd be highly supportive of such a split. --tobie
Re: Web Intents on WebApps' May 1-2 f2f meeting agenda?
On Apr 10, 2012, at 2:28 PM, ext James Hawkins wrote: If we can schedule this for May 1, that would be fantastic. Unfortunately something last-minute has come up and I won't be able to attend May 2. I put Web Intents in the 1:30 to 2:30 slot on Tuesday May 1 http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting#Agenda_May_1. If that doesn't work, let me know. -Thanks, Art Thanks, James On Tue, Apr 10, 2012 at 5:00 AM, Arthur Barstow art.bars...@nokia.com wrote: Hi James, Greg, All - in case you did not know, WebApps is having a f2f meeting May 1-2 in Mountain View (logistical details below). Given Web Intents is a joint deliverable with WebApps, perhaps it would be useful to allocate some agenda time for Web Intents e.g. an update on the status, plans, etc. If we do want to allocate some time, we can of course use the W3C voice conference bridge to facilitate remote participants but we would need to nail down the day + time slot. WDYT? -AB=
Re: [XHR] XMLHttpRequest.send()
On Tue, Apr 10, 2012 at 4:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 10, 2012 at 4:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 10, 2012 at 3:58 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 10, 2012 at 5:50 PM, Jonas Sicking jo...@sicking.cc wrote: Is it more surprising than that xhr.send(hasSomethingToSend() ? getTheThingToSend() : ); sets the Content-Type header even when no body is submitted? That's exactly what I would expect. A body that happens to have a zero length is still valid text/plain data. I'm not sure everyone is sharing that expectation. If you want to omit Content-Type in the above case, then you should write: xhr.send(hasSomethingToSend() ? getTheThingToSend() : null); Or, of course: if(hasSomethingToSend()) xhr.send(getTheThingToSend()); That isn't terribly useful if you're trying to get a response... If I'm the only one who prefer the other behavior then we should stick to what the spec already says. I'll make sure Gecko maintains that behavior as we implement our new WebIDL bindings. I got the following feedback from the WebIDL implementers: One note, though. If we do want the current behavior, then I think that it would make sense to change the IDL for send() to: void send(ArrayBuffer data); void send(Blob data); void send(Document data); void send(optional DOMString? data = null); void send(FormData data); and change the text that currently says If the data argument has been omitted or is null to If the data argument is null. That will make it much clearer to someone reading the IDL that passing nothing has the same behavior as passing null. / Jonas
Re: Reminder: May face-to-face meetings for HTML and WebApps
Is there any possibility to attend remotely for specific topics? Regards, Silvia. On Tue, Apr 3, 2012 at 6:10 AM, Philippe Le Hegaret p...@w3.org wrote: Dear All, This is a friendly reminder for folks to register for the upcoming face-to-face meetings in one month from today: * Web Application Working Group, May 1/2 (Tuesday/Wednesday) * HTML Working Group, May 3/4 (Thursday/Friday) * Web Application Security Working Group, May 2/3 (Wednesday/Thursday) Use the form at [1] to register. Philippe [1] https://www.w3.org/2002/09/wbs/1/webappshtml-s2012--meeting/
Re: [XHR] XMLHttpRequest.send()
On Tue, Apr 10, 2012 at 9:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 10, 2012 at 4:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 10, 2012 at 4:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 10, 2012 at 3:58 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 10, 2012 at 5:50 PM, Jonas Sicking jo...@sicking.cc wrote: Is it more surprising than that xhr.send(hasSomethingToSend() ? getTheThingToSend() : ); sets the Content-Type header even when no body is submitted? That's exactly what I would expect. A body that happens to have a zero length is still valid text/plain data. I'm not sure everyone is sharing that expectation. If you want to omit Content-Type in the above case, then you should write: xhr.send(hasSomethingToSend() ? getTheThingToSend() : null); Or, of course: if(hasSomethingToSend()) xhr.send(getTheThingToSend()); That isn't terribly useful if you're trying to get a response... If I'm the only one who prefer the other behavior then we should stick to what the spec already says. I'll make sure Gecko maintains that behavior as we implement our new WebIDL bindings. I got the following feedback from the WebIDL implementers: One note, though. If we do want the current behavior, then I think that it would make sense to change the IDL for send() to: void send(ArrayBuffer data); void send(Blob data); void send(Document data); void send(optional DOMString? data = null); void send(FormData data); and change the text that currently says If the data argument has been omitted or is null to If the data argument is null. That will make it much clearer to someone reading the IDL that passing nothing has the same behavior as passing null. / Jonas This makes sense. I too am of the opinion that is text/plain even if empty and ought to be distinguishable. However I can see your point Jonas since is falsy.
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, 10 Apr 2012 20:26:04 +0200, Travis Leithead travis.leith...@microsoft.com wrote: IE10 does not implement SharedWorkers at the present time. We also don’t yet implement the updated Transferrable notion for MessagePorts in the structured clone algorithm. Ah, OK. We do ship Workers now, and so my primary concern is that the spec doesn't remove the ports property of the MessageEvent. Yep, I'm not suggesting to remove it. I don't mind the proposal to re-use .source of MessageEvent for a connect event on a SharedWorker. I think it's a bit ugly to swap the WindowProxy type of .source to any just for this case. Anne said the type could be (WindowProxy or MessagePort)?. I am curious to see where this latest discussion on perhaps using a different Event interface for connect events will lead... -- Simon Pieters Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, 10 Apr 2012 19:33:55 +0200, Andrew Wilson atwil...@google.com
wrote:
I'll agree that having to use ports[0] to access the MessagePort in a
connect event has always felt a bit like an API wart. However, I don't
entirely recall why we wanted to have the connect event use the
MessageEvent interface. So I'd be uncomfortable with changing connect
event
to not match that interface without understanding why we made those
interfaces match in the first place (perhaps Ian can chime in here).
I don't see the problem with using MessageEvent for connect.
I'll also note that the MessageEvent for cross-document messaging has a
|ports| attribute, so I'm not certain why removing this attribute on the
connect event makes it closer to the [cross-document messaging] API -
can
you clarify your reasoning here?
The code you write looks more like in cross-document messaging:
// cross-document messaging:
// I can get a message event from several places
onmessage = function(e) {
// post a pong message back
e.source.postMessage('pong', '*');
}
// shared workers:
// I can get a connect event from several places
onconnect = function(e) {
// post a pong message back
e.source.postMessage('pong');
}
The author doesn't need to care that e.source are different objects in the
two cases, they only need to care that it exposes a postMessage method
that they can use to communicate back.
Also, since MessagePort is not a
WindowProxy, I'm not sure we want to encourage developers to treat them
as
the same by putting them both as the |source| attribute in MessageEvents
in
different contexts, especially since the postMessage() APIs don't
precisely
match.
Hey, we use MessageEvent in lots of different contexts with different
semantics -- cross-document messaging, workers, shared workers,
EventSource, WebSocket... I don't think making this change to shared
workers is going to invalidate the usage of MessageEvent.
On Tue, 10 Apr 2012 19:47:12 +0200, Andrew Wilson atwil...@google.com
wrote:
To follow up on Jonas' earlier comment, the postMessage/MessageEvent APIs
changed to support object transfers after we defined the connect event
structure, so it's not unreasonable that we should take another look at
the
connect event to try to make it match the current definition of
postMessage().
I think the model of connect event we've used in the past
(pre-structure-clone-transfer) is as if the creator of the SharedWorker
were sending a message like so:
postMessage(, [newPort]);
The recipient then receives a MessageEvent with data= and
ports=[newPort].
In the new world where postMessage() supports a transfer object, I think
the appropriate analogous connect event would be to result in a
MessageEvent with both the |data| and |ports| attributes pointing at an
array containing a single MessagePort. I don't think putting the
MessagePort as the source attribute is the right model.
I don't think authors think of it in this way.
--
Simon Pieters
Opera Software
Re: Shared workers - use .source instead of .ports[0] ?
What is the backwards compatibility story for websites already using SharedWorkers with the interface that has been in the spec for over a year now? There are sites using them. For example, Google Docs uses them and Google Web Toolkit exposes them. dave
Re: Shared workers - use .source instead of .ports[0] ?
On Tue, Apr 10, 2012 at 10:44 PM, David Levin le...@google.com wrote: What is the backwards compatibility story for websites already using SharedWorkers with the interface that has been in the spec for over a year now? There are sites using them. For example, Google Docs uses them and Google Web Toolkit exposes them. As far as I can see there are no backwards compat breaking changes proposed. Are there any particular parts you are worried about? / Jonas
