Aren't both text/html;charset=windows-1252 and text/html;
charset=windows-1252 valid MIME types? Should we make the tests a bit more
accepting?
Reading http://www.w3.org/Protocols/rfc1341/4_Content-Type.html it's not
crystal clear if spaces are accepted, although white spaces and space
are
On Mon, May 6, 2013 at 9:31 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
...
The reason the tests test that is because the specification requires
exactly that. If you want to change the tests, you'd first have to
change the specification. (What HTTP says on the matter is not
Hey Anne,
I don't quite get why you're saying HTTP is irrelevant.
As an example, regarding the content-type *request *header, the XHR spec
clearly states:
If a Content-Type header is in author request
headershttp://www.w3.org/TR/XMLHttpRequest/#author-request-headers
and
its value is a valid
could make the XMLHttpRequest talk about
the value in a more abstract manner rather than any particular
serialization and leave the serialization undefined, but it's not
clear we should do that.
As an example, regarding the content-type request header, the XHR spec
clearly states:
If a Content
, but it's not
clear we should do that.
As an example, regarding the content-type request header, the XHR spec
clearly states:
If a Content-Type header is in author request headers and its value is a
valid MIME type that has a charset parameter whose value is not a
case-insensitive match
On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote:
It seems strange the spec would require a case-sensitive value for
Content-Type in certain circumstances. Are these deviations from the
case-insensitiveness of the header really necessary ? Are they beneficial
for authors ?
I hear you, but isn't having a case-sensitive value of Content-Type *in
certain circumstances* triggering the kind of problem you're talking about
(developers to depend on
certain things they really should not depend on) ?
As I see it, the tests in question here are doing something that is wrong
On Tue, 07 May 2013 01:39:26 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
On Mon, May 6, 2013 at 4:33 PM, Julian Aubourg j...@ubourg.net wrote:
It seems strange the spec would require a case-sensitive value for
Content-Type in certain circumstances. Are these deviations from the
Since XHR is the API to facilitate a valid HTTP transaction, IMHO, it should be
fully compliant with HTTP - no more and no less. A valid HTTP request and
response should be interpreted consistently across UA's and devices.
Interoperability is very important across UA's and devices. If the XHR
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21650
Bug ID: 21650
Summary: Require that XHR is available in workers
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Last year we agreed to stop work on the baseline XHR spec because no
one was willing to work on that version of the spec. Since then, the new
XHR Editors agreed to work on a baseline version as well as to continue
to work on the `bleeding edge` version.
One goal of the baseline version
On Thu, 28 Feb 2013 15:46:34 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
Last year we agreed to stop work on the baseline XHR spec because no
one was willing to work on that version of the spec. Since then, the new
XHR Editors agreed to work on a baseline version as well
can i ask, how do you use the abort event handler?
and error event handler
In jQuery 1.x, we don't even use onsuccess, onerror and onabort. Reason
being onreadystatechange is the only cross-browser means to handle
XMLHttpRequest when you have to support old IEs (and we try and avoid
having
I have the same questions as Jungkee. What is it you want to remove
exactly? Why do you think the distinction between an user-initiated abort
and a network error is irrelevant? If I am to believe jQuery's bug tracker,
our users want and need the distinction.
On 25 February 2013 07:49, Jungkee
On Mon, Feb 25, 2013 at 8:20 AM, Julian Aubourg j...@ubourg.net wrote:
I have the same questions as Jungkee. What is it you want to remove exactly?
Why do you think the distinction between an user-initiated abort and a
network error is irrelevant? If I am to believe jQuery's bug tracker, our
AFAIK, clicking the stop button of the navigator or clicking on a link in
the page will abort outbound requests. That's exactly the kind of aborts
authors want to differentiate from network errors. I assume those buttons
are UI features that permit request cancellation for users? Or am I
completly
On Mon, Feb 25, 2013 at 9:22 AM, Julian Aubourg j...@ubourg.net wrote:
AFAIK, clicking the stop button of the navigator or clicking on a link in
the page will abort outbound requests. That's exactly the kind of aborts
authors want to differentiate from network errors. I assume those buttons
the progress bars for fetching after the page had loaded (body
load fired) were disabled as they were just too confusing.
Some data points:
- Firefox already sends onerror if you hit escape while an XHR is in
progress. The onerror handler can just start another XHR request, and
pressing escape again
fired) were disabled as they were just too confusing.
Some data points:
- Firefox already sends onerror if you hit escape while an XHR is in
progress. The onerror handler can just start another XHR request, and
pressing escape again will once again onerror that new request.
- In WebKit
to expose this distinction from a network error in the API? I think we should merge them. Chrome(WebKit) and Firefox has ability to abort XHR requests:With ESC key (in chrome it works while page is loading), also XHR is aborted while page unloading.Chrome fires “abort”Firefox fires “error” In Firefox I can
Key here is to make it possible for author to know what's going on and onabort seems quite confusing can i ask, how do you use the "abort" event handler?and "error" event handler" in case of user abort, it is not good to reconnect or show warningbut in case of error, it is good
Currently the XMLHttpRequest Standard special cases the condition
where the end user terminates the request. Given that there's less and
less likely to be UI for that kind of feature, does it still make
sense to expose this distinction from a network error in the API? I
think we should merge them.
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
Currently the XMLHttpRequest Standard special cases the condition
where the end user terminates the request. Given that there's less and
less likely to be UI for that kind of feature, does it still make
sense to expose
On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
Currently the XMLHttpRequest Standard special cases the condition
where the end user terminates the request. Given that there's less and
less likely
From: Timmy Willison [mailto:timmywill...@gmail.com]
Sent: Monday, February 25, 2013 2:55 AM
On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl
wrote:
Currently the XMLHttpRequest Standard special
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17046
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
Hi,
Nicolas Chambrier (he's not registered to the list, please keep him in
the CC in your replies) and I came across that case recently:
1) create an XHR object (POST in case it matters)
2) set the Content-Type header explicitly (it changes, but we noticed
it with something like application
On Tue, Feb 19, 2013 at 5:51 PM, David Bruant bruan...@gmail.com wrote:
My understanding of the spec is that the charset shouldn't be added,
because:
1) the Content-Type header is in author request header
2) the value is a valid MIME-type (tell me if I'm wrong on this)
3) it does not have a
On 2/19/13 1:40 PM, Anne van Kesteren wrote:
On Tue, Feb 19, 2013 at 5:51 PM, David Bruant bruan...@gmail.com wrote:
My understanding of the spec is that the charset shouldn't be added,
because:
1) the Content-Type header is in author request header
2) the value is a valid MIME-type (tell me if
On Tue, Feb 19, 2013 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Note that Firefox adds the charset even if it wasn't set by the page because
web developers were asking for it to aid server-side processing... The
alternative is that the server has no idea what to do with the data. :(
On 2013-02-19 19:51, Anne van Kesteren wrote:
On Tue, Feb 19, 2013 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Note that Firefox adds the charset even if it wasn't set by the page because
web developers were asking for it to aid server-side processing... The
alternative is that the
On 2/19/13 1:51 PM, Anne van Kesteren wrote:
Does that include cases though where the page did set a Content-Type
through setRequestHeader()?
That's a good question. I don't remember anymore; I'd have to go read
the relevant bugs.
Because technically what Firefox does
violates HTTP
On Tue, Feb 12, 2013 at 8:00 PM, Anne van Kesteren ann...@annevk.nl wrote:
Hmm I see what you mean. But the user agent can provide the
Authorization header too based on a previous visit. That is the
meaning that is most often meant, but in the particular case of CORS
the semantics are subtly
On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain mon...@gmail.com wrote:
The XHR spec defines user credentials as cookies, HTTP authentication,
and client-side SSL certificates. Its not clear to me what HTTP
authentication referring to.
I assumed it was referring to the HTTP authentication
On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain mon...@gmail.com wrote:
The XHR spec defines user credentials as cookies, HTTP authentication,
and client-side SSL certificates. Its not clear to me what HTTP
On Tue, Feb 12, 2013 at 7:30 PM, Monsur Hossain mon...@gmail.com wrote:
On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote:
User credentials stored by the user agent based on a previous visit to the
URL.
Ok thanks. I think it would be useful if the HTTP authentication
On Tue, Feb 12, 2013 at 1:36 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Feb 12, 2013 at 7:30 PM, Monsur Hossain mon...@gmail.com wrote:
On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl
wrote:
User credentials stored by the user agent based on a previous visit
On Tue, Feb 12, 2013 at 7:52 PM, Monsur Hossain mon...@gmail.com wrote:
I think what was confusing to me is that the
Access-Control-Allow-Credentials section of the CORS spec indicates that a
true value indicates that the actual request can include user
credentials.
In the case of cookies,
On Jan 22, 2013, at 9:42 AM, Cyril Concolato wrote:
Hi Arun,
Le 22/01/2013 15:04, Arun Ranganathan a écrit :
Hi Cyril,
1) I'm wondering why in progressive mode, does the spec say: partial Blob
data is an ArrayBuffer [TypedArrays] object consisting of the bytes loaded
so far. Why
Hi Cyril,
1) I'm wondering why in progressive mode, does the spec say: partial Blob
data is an ArrayBuffer [ TypedArrays ] object consisting of the bytes loaded so
far . Why isn't it the bytes loaded since the previous progress event?
AR: It is always a new ArrayBuffer. The phraseology so
as well.
Certainly, if you had binary data of infinite size, you'll get
several result objects. The file API, particularly FileReader,
shouldn't be used in streaming scenarios.
I disagree. The File API combined with XHR should be fine for reading
(large) files for which the size
but if it is an ArrayBuffer, since it is immutable,
it cannot be incremented.
Strings in JS are immutable. So it will always be a new string.
So in the case the final length of the Blob is not
known yet (e.g. chunked XHR), result has to be a new object each time. Am I
wrong here? If not, could you clarify
On 12/14/12 6:49 AM, Jungkee Song wrote:
FWIW, document.open() does not create a new Window object
Yes, it does. See
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-open
processing steps step 14. WebKit gets this wrong, but other UAs do it
right.
On Fri, Dec 14, 2012 at 5:30 PM, Boris Zbarsky bzbar...@mit.edu wrote:
But note that you can get the same effect by just navigating the a browsing
context, then calling a function that was defined in the no-longer-active
document, without worrying about browsers that have buggy open()
? In that case, there is no
problem with the document per se; the only question is whether the XHR
has an associated document object at all in that case... and per spec
not having one does NOT cause open() to throw.
-Boris
On Fri, Dec 14, 2012 at 6:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Which other case? The document.open() one? In that case, there is no
problem with the document per se; the only question is whether the XHR has
an associated document object at all in that case... and per spec not
having
On 12/14/12 12:54 PM, Anne van Kesteren wrote:
On Fri, Dec 14, 2012 at 6:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Which other case? The document.open() one? In that case, there is no
problem with the document per se; the only question is whether the XHR has
an associated document object
On 12/14/12 1:55 PM, Anne van Kesteren wrote:
It seems to depend on whether or not the old Window object still has
an associated document. If it still points to the active document the
above would work. If it points nowhere the above cannot work
Well. It depends on whether we want to use the
On 12/14/12 2:29 PM, Anne van Kesteren wrote:
Per Hixie the Document is associated with both the old and the new
Window. Meaning that XMLHttpRequest will function normally even though
XMLHttpRequest != window.XMLHttpRequest.
I'm not sure it actually will; Olli had some concerns about event
On 12/14/2012 09:46 PM, Boris Zbarsky wrote:
On 12/14/12 2:29 PM, Anne van Kesteren wrote:
Per Hixie the Document is associated with both the old and the new
Window. Meaning that XMLHttpRequest will function normally even though
XMLHttpRequest != window.XMLHttpRequest.
I'm not sure it
document?
}
This document is later used by the open() method of XHR, which also
checks it's fully active and throws an exception otherwise.
--
http://annevankesteren.nl/
that is not
implementable. The WebIDL used in XHR is not valid according to the 19
April 2012 CR of WebIDL.
[...]
[chaals' example of currently unwritten requirements]
I find this comparison, in particular, to be unhelpful and rather rude.
I'm sorry. If you'd like to discuss this further, in an appropriate forum
On Tue, 4 Dec 2012, Charles McCathie Nevile wrote:
This is a formal warning.
I do not support the chairs in this. I stand by Ms2ger. He has not acted
inappropriately and his complaints are valid.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/
On Tue, 04 Dec 2012 01:50:35 +0100, Ian Hickson i...@hixie.ch wrote:
... This is just plagiarism.
Ian, this accusation against colleagues of yours working in good faith is
offensive, and it is untrue. It is therefore inappropriate for this
mailing list.
I will repeat, since you may have
version of XHR, or next draft of this spec? Either way, I
don't see that this should stop publication.
- The last three commits (Nov 22) in WHATWG has not been incorporated
yet.
We're publishing a Working Draft. And we are happy to produce a stabilised
version and work on a new one. We want
venues; I won't go into it again.
Furthermore, I should point out that referencing the TR draft of WebIDL
would (if anybody tried to implement the TR spec and its TR references;
nobody does, of course) lead to a specification that is not
implementable. The WebIDL used in XHR is not valid according
On Sat, 1 Dec 2012, Ms2ger wrote:
I object to this publication because of this change:
http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
I agree. That change is offensive. It gives credit to dozens of people who
have done basically nothing productive at all, for work that a few of us
have spent
On Sun, Dec 2, 2012 at 11:07 AM, James Robinson jam...@google.com wrote:
Sure there is if the W3C version is stale, as is the case here.
I don't think it's a technical issue to discuss. There should be
corresponding publication rules.
Art, Charles, Doug,
Can you help clarifying which links we
On 12/02/2012 12:07 PM, Jungkee Song wrote:
On Sun, Dec 2, 2012 at 11:07 AM, James Robinson jam...@google.com wrote:
Sure there is if the W3C version is stale, as is the case here.
I don't think it's a technical issue to discuss. There should be
corresponding publication rules.
Art,
On 12/1/12 3:34 PM, ext Ms2ger wrote:
I object to this publication because of this change:
http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
For a couple of years now, if a spec proposed for publication in TR
includes a normative reference that hahas published as a TR, PLH has
insisted
On 12/02/2012 01:38 PM, Arthur Barstow wrote:
On 12/1/12 3:34 PM, ext Ms2ger wrote:
I object to this publication because of this change:
http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
For a couple of years now, if a spec proposed for publication in TR
includes a normative reference that hahas
On 11/27/2012 02:16 PM, Arthur Barstow wrote:
On 11/27/12 12:21 AM, ext Jungkee Song wrote:
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Tuesday, November 27, 2012 3:05 AM
I think the next step is for the XHR Editors to create a TR version
using the WD template so that everyone
On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote:
On 11/27/2012 02:16 PM, Arthur Barstow wrote:
On 11/27/12 12:21 AM, ext Jungkee Song wrote:
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Tuesday, November 27, 2012 3:05 AM
I think the next step is for the XHR
On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams gl...@skynav.com wrote:
On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote:
I object to this publication because of this change:
http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
pushed with a misleading commit message.
since you don't say
to this publication because of this change:
http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
pushed with a misleading commit message.
since you don't say what is misleading, and since commit messages are
irrelevant for W3C process, this objection is immaterial
Ms2ger objected to the change
, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote:
I object to this publication because of this change:
http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
pushed with a misleading commit message.
since you don't say what is misleading, and since commit messages are
irrelevant for W3C
...@gmail.comwrote:
On Sat, Dec 1, 2012 at 4:44 PM, Glenn Adams gl...@skynav.com wrote:
On Sat, Dec 1, 2012 at 1:34 PM, Ms2ger ms2...@gmail.com wrote:
I object to this publication because of this change:
http://dvcs.w3.org/hg/xhr/rev/2341e31323a4
pushed with a misleading commit message.
since you
On 11/27/12 12:21 AM, ext Jungkee Song wrote:
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Tuesday, November 27, 2012 3:05 AM
I think the next step is for the XHR Editors to create a TR version
using the WD template so that everyone can see exactly what is being
proposed
On 11/26/12 1:38 AM, ext Jungkee Song wrote:
I suggest we put the following wordings for Anne's work and WHATWG to be
credited. If we make consensus, let me use this content for publishing the WD.
Please put your proposed text in a version of the spec we can review and
send us the URL of
On Mon, Nov 26, 2012 at 4:05 AM, Ian Hickson i...@hixie.ch wrote:
I don't know what official would mean here. I just meant the intent that
is behind my (and Anne's, I believe) advocacy of open licensing for
specifications.
Yup.
--
http://annevankesteren.nl/
I agree with Ian's other observations/comments.
On Fri, Nov 23, 2012 at 10:22 PM, Ian Hickson i...@hixie.ch wrote:
What I don't really understand, though, is why any of this is needed at
all. What value is the W3C adding by creating these forks?
In the end (dunno when that will be), patent
.
Please put your proposed text in a version of the spec we can review and
send us the URL of that version.
Please find the version at:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
Jungkee
use this content for publishing the
WD.
Please put your proposed text in a version of the spec we can review and
send us the URL of that version.
Please find the version at:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
Thanks, this looks a lot better. However, I'd also like to see
(12/11/26 21:25), Anne van Kesteren wrote:
I agree with Ian's other observations/comments.
I suppose that doesn't include
(12/11/24 5:22), Ian Hickson wrote:
Also, the document asks for feedback on the public-webapps list, but
that fragments feedback on the spec; the WHATWG copy instead
On Mon, Nov 26, 2012 at 3:11 PM, Kang-Hao (Kenny) Lu
kangh...@oupeng.com wrote:
(12/11/24 5:22), Ian Hickson wrote:
Also, the document asks for feedback on the public-webapps list, but
that fragments feedback on the spec; the WHATWG copy instead suggests
feedback go to the WHATWG list.
?
(12/11/26 22:11), Kang-Hao (Kenny) Lu wrote:
(12/11/26 21:25), Anne van Kesteren wrote:
I agree with Ian's other observations/comments.
I suppose that doesn't include
(12/11/24 5:22), Ian Hickson wrote:
Also, the document asks for feedback on the public-webapps list, but
that fragments
use this content for publishing the
WD.
Please put your proposed text in a version of the spec we can review and
send us the URL of that version.
Please find the version at:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
Thanks Jungkee.
I think the next step is for the XHR Editors
On Mon, 26 Nov 2012, Anne van Kesteren wrote:
I agree with Ian's other observations/comments.
On Fri, Nov 23, 2012 at 10:22 PM, Ian Hickson i...@hixie.ch wrote:
What I don't really understand, though, is why any of this is needed
at all. What value is the W3C adding by creating these
for Anne's work and WHATWG to be
credited. If we make consensus, let me use this content for publishing
the
WD.
Please put your proposed text in a version of the spec we can review and
send us the URL of that version.
Please find the version at:
http://dvcs.w3.org/hg/xhr/raw-file/tip
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Tuesday, November 27, 2012 3:05 AM
I think the next step is for the XHR Editors to create a TR version
using the WD template so that everyone can see exactly what is being
proposed for publication as a TR. Please create that version
Le 22/11/2012 18:16, Ms2ger a écrit :
On 11/22/2012 02:01 PM, Arthur Barstow wrote:
TheXHR Editors would like to publish a new WD of XHR and this is a
Call for Consensus to do so using the following ED (not yet using the
WD template) as the basis
http://dvcs.w3.org/hg/xhr/raw-file/tip
Group public-webapps@w3.org
Former editors:
Adam Barth w...@adambarth.com
Erik Arvidsson a...@chromium.org
Michael[tm] Smith m...@w3.org
]]
In the case of XHR, the new Editors would be listed as Editors and if they made contributions to the spec, they would also be added to the Author list too.
If somethin
On Sun, Nov 25, 2012 at 10:34 AM, David Bruant bruan...@gmail.com wrote:
Le 22/11/2012 18:16, Ms2ger a écrit :
On 11/22/2012 02:01 PM, Arthur Barstow wrote:
TheXHR Editors would like to publish a new WD of XHR and this is a
Call for Consensus to do so using the following ED (not yet
On Sun, 25 Nov 2012 22:34:03 +0400, David Bruant bruan...@gmail.com
wrote:
Le 22/11/2012 18:16, Ms2ger a écrit :
On 11/22/2012 02:01 PM, Arthur Barstow wrote:
TheXHR Editors would like to publish a new WD of XHR and this is a
Call for Consensus to do so using the following ED (not yet
Le 25/11/2012 20:07, Kyle Huey a écrit :
Have you read Adam Barth's contributions to this discussion?
Sure, and I personally mostly agree with these points.
He has summarized the point well, I think. There is a difference
between what the license legally obligates one to do
I talked very
On Sun, 25 Nov 2012, David Bruant wrote:
The intent is clear: the WHATWG publishes documents in the public domain
for very good reason. Anyone (W3C included!) can reuse them under close
to no condition, not even credit.
I can speak pretty authoritatively to the intent, if that's what you
On Sun, Nov 25, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 25 Nov 2012, David Bruant wrote:
The intent is clear: the WHATWG publishes documents in the public domain
for very good reason. Anyone (W3C included!) can reuse them under close
to no condition, not even credit.
I
On Sun, 25 Nov 2012, Jonas Sicking wrote:
On Sun, Nov 25, 2012 at 12:38 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 25 Nov 2012, David Bruant wrote:
The intent is clear: the WHATWG publishes documents in the public
domain for very good reason. Anyone (W3C included!) can reuse them
Hi,
I suggest we put the following wordings for Anne's work and WHATWG to be
credited. If we make consensus, let me use this content for publishing the WD.
As the co-Editors of W3C XHR spec wrote in the threads, we have our role and
contribution in moving this spec toward the W3C REC. Up
can live with it
test.
As the co-Editors of W3C XHR spec wrote in the threads, we have our role
and contribution in moving this spec toward the W3C REC. Up to the
moment, we mostly had to take care of the gaps between W3C version and
WHATWG version to make them convergent. We will try
On Thu, Nov 22, 2012 at 6:27 AM, Anne van Kesteren ann...@annevk.nl wrote:
If you have any comments or concerns about this proposal, please reply to
this e-mail by December 29 at the latest.
Putting my name as former editor while all the text is either written
by me or copied from me seems
On Fri, Nov 23, 2012 at 12:09 AM, Adam Barth w...@adambarth.com wrote:
On Thu, Nov 22, 2012 at 9:16 AM, Ms2ger ms2...@gmail.com wrote:
On 11/22/2012 02:01 PM, Arthur Barstow wrote:
TheXHR Editors would like to publish a new WD of XHR and this is a
Call for Consensus to do so using
On Fri, Nov 23, 2012 at 4:57 PM, Glenn Adams gl...@skynav.com wrote:
If Anne's work was submitted to and prepared in the context of the WebApps
WG, then it is a product of the WG, and there is no obligation to refer to
other, prior or variant versions.
To be clear, in http://dvcs.w3.org/hg/xhr
a new WD of XHR and this is a
Call for Consensus to do so using the following ED (not yet using the
WD template) as the basis
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html.
Agreement to this proposal: a) indicates support for publishing a new
WD; and b) does not necessarily indicate
Are you claiming that the W3C is in the business of plagiarizing?
I'm saying that the W3C (and this working group in particular) is
taking Anne's work, without his permission, and passing it off as its
own.
Speaking as one of the W3C-editors of the spec: first I agree that crediting
On 11/23/12 5:36 PM, Adam Barth w...@adambarth.com wrote:
However, we should be honest about the origin of the text and not try
to pass off Anne's work as our own.
Or better yet, provide a canvas where Anne is able to do his work as part
of the WebApps WG.
--tobie
On Fri, Nov 23, 2012 at 9:01 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Are you claiming that the W3C is in the business of plagiarizing?
I'm saying that the W3C (and this working group in particular) is
taking Anne's work, without his permission, and passing it off as its
On Fri, Nov 23, 2012 at 9:36 AM, Adam Barth w...@adambarth.com wrote:
My concern is not about copyright. My concern is about passing off
Anne's work as our own.
As I have pointed out above, W3C specs do not track authorship or
individual contributions to the WG process. If Anne performed his
Hi all,
In an ideal world, Anne would be the editor of the W3C version of the spec
and that would be the end of it. Such is not the case. Anne is not the
editor of the W3C version: he doesn't edit and/or publish anything related
to the W3C XHR spec. Current editors do and while it's mostly brain
I would think that listing Anne as Editor or Former Editor and
listing Anne in an Acknowledgments paragraph should be entirely
consistent with all existing W3C practice.
But it's not consistent with that existing W3C practice to get all the text for
a spec from a document edited outside the
301 - 400 of 1217 matches
Mail list logo
