On Jun 8, 2008, at 11:35 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
On Jun 6, 2008, at 2:20 PM, Travis Leithead wrote:
While implementing some improvements to getAttribute in IE8, we
actually checked in code that is conformant to what the spec says
about the return value
On Jun 6, 2008, at 7:55 AM, Mark Baker wrote:
On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu [EMAIL PROTECTED]
wrote:
Hello,
I am interested in working on a specification of a DOM API that
allows
Web pages to access the user's geolocation information (e.g. latitude
and longitude).
On Jun 6, 2008, at 2:20 PM, Travis Leithead wrote:
While implementing some improvements to getAttribute in IE8, we
actually checked in code that is conformant to what the spec says
about the return value:
Return Value
DOMString
The Attr value as a string, or the empty string if that
At this point I am really confused about where to discuss geolocation
APIs, and I would rather not have it bounce back and forth. Maybe we
should just wait until the chartering process reaches its conclusion.
Regards,
Maciej
On Jun 3, 2008, at 7:24 AM, Doug Schepers wrote:
Hi, Ian-
On Jun 3, 2008, at 11:19 AM, Doug Schepers wrote:
Hi, Maciej-
Maciej Stachowiak wrote (on 6/3/08 1:53 PM):
At this point I am really confused about where to discuss
geolocation APIs, and I would rather not have it bounce back and
forth. Maybe we should just wait until the chartering
On Jun 3, 2008, at 7:12 AM, Doug Schepers wrote:
Hi, Anne-
Anne van Kesteren wrote (on 6/3/08 9:44 AM):
On Tue, 03 Jun 2008 15:33:34 +0200, Erik Dahlstrom [EMAIL PROTECTED]
wrote:
The SVG WG would like to request a two week extension for
reviewing the XMLHttpRequest LC draft.
Please
On May 27, 2008, at 11:56 PM, Ian Hickson wrote:
(In particular, I think we really need to get over the concept of but
that's a host language issue or that doesn't belong in my spec
and so
on -- we're defining a single platform here, it isn't useful for us
to be
declining responsibility
On May 27, 2008, at 2:01 PM, Doug Schepers wrote:
Hi, Ian-
Thanks for this proposal.
I strongly believe that W3C should be working on this, and over the
last few weeks, Mike Smith and I have been talking to key vendors
and other parties to bring together the proper resources to do
On May 25, 2008, at 11:40 AM, Jonas Sicking wrote:
Julian Reschke wrote:
Anne van Kesteren wrote:
On Sat, 24 May 2008 18:27:47 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Anne van Kesteren wrote:
Per the updated specification which uses Web IDL IE and Safari
are conformant here.
On May 25, 2008, at 3:19 PM, Anne van Kesteren wrote:
On Sun, 25 May 2008 18:04:14 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Apparently existing content does not rely on it (FF gets away with
implementing something that IMHO makes *much* more sense). So why
standardize it at all,
On May 17, 2008, at 1:03 AM, Julian Reschke wrote:
Sunava Dutta wrote:
...
At this point, I'm not sure why we're bothering with XHR1 at all.
It is
*not* what the current implementations do anyway.
[Sunava Dutta] I'm sorry, this statement is concerning and I'd like
to understand it
On May 15, 2008, at 1:24 PM, Julian Reschke wrote:
practice, take anything away from the ability to get interoperable
implemenations of the feature described in XHR1.
Really?
What if Apple implements the thing as defined by HTML5-as-of-2008,
and Microsoft as defined in
On May 13, 2008, at 5:08 AM, Charles McCathieNevile wrote:
On Sun, 11 May 2008 05:10:57 +0200, Aaron Boodman [EMAIL PROTECTED]
wrote:
On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
... I'm not really clear on why Blobs must be distinct from
ByteArrays
On May 12, 2008, at 12:44 AM, Jonas Sicking wrote:
Lachlan Hunt wrote:
Jonas Sicking wrote:
What are the remaining issues that are still holding us back? It
seems to me like if we know we're going to add this in a version
2, but we already have a done specification for it, why not
On May 12, 2008, at 5:52 AM, Bjoern Hoehrmann wrote:
* Maciej Stachowiak wrote:
A function is not a particularly convenient way to specify a
namespace
mapping, and it creates these error handling issues as well as
causing
problems with case (in)sensitivity. Even though NSResolver is what
On May 12, 2008, at 8:00 AM, Bjoern Hoehrmann wrote:
* Maciej Stachowiak wrote:
This does not look much better (it does avoid repeatedly mentioning
the xmlns namespace at least):
function resolver(prefix) {
if (prefix == xht) {
return http://www.w3.org/1999/xhtml;;
} else
On May 12, 2008, at 9:38 AM, Bjoern Hoehrmann wrote:
* Maciej Stachowiak wrote:
You can just use `function(p) { return namespaces[p]; }` then.
Sure, but there's no actual need to allow running arbitrary code and
all the risks that creates/
Which is no risks at all. You can simply parse
On May 10, 2008, at 11:39 PM, Chris Prince wrote:
On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
I'm not really clear on why Blobs must be distinct from ByteArrays.
The only explanation is: The primary difference is that Blobs are
immutable*, and can therefore
On May 11, 2008, at 4:08 PM, Aaron Boodman wrote:
On Sun, May 11, 2008 at 3:02 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Both of these can be addressed by the APIs (including the worker
transfer
mechanism) making a copy, which can use a copy-on-write mechanism
to avoid
actually
On May 11, 2008, at 4:40 PM, Aaron Boodman wrote:
On Sun, May 11, 2008 at 4:22 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Here's one additional question on how this would work with
ByteArray.
The read API for ByteArray is currently synchronous. Doesn't this
mean
that with large
On May 11, 2008, at 6:01 PM, Aaron Boodman wrote:
On Sun, May 11, 2008 at 5:46 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Well, that depends on how good the OS buffer cache is at
prefetching. But in
general, there would be some disk access.
It seems better if the read API is just
On May 7, 2008, at 10:08 PM, Aaron Boodman wrote:
Hi everyone,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has been lingering so long as a work item.
The Gears team has also been putting together a proposal for file
access which
On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:
Hi folks,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has been lingering so long as a work item.
In a nutshell, it provides the ability for a web application to get a
Hey Chaals,
On May 7, 2008, at 10:39 AM, Charles McCathieNevile wrote:
On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
Yep. That's the idea.
Here are some of the more obvious security issues:
[several obviously interesting things]
6) Despite clearly
On May 5, 2008, at 2:13 PM, Lachlan Hunt wrote:
*Solution 5*
Define the methods to behave as if an implicit :scope selector
and descendant combinator were prepended to each selector in
the group.
This would work by taking the selector and appending the equivalent
of :scope to the
On May 2, 2008, at 2:15 PM, John Resig wrote:
There's a solution to the above that is both simple and intuitive:
The first character of the selector that the UA doesn't know what to
do with. For example, in the above, it would be:
:not(a:link)
^
:not|test|
^
:note
^
Your
On May 2, 2008, at 7:37 PM, Cameron McCormack wrote:
Boris Zbarsky:
In that case, the null behavior doesn't make any sense to me... I
would
expect querySelector(null) to either behave as
querySelector(null) (as
in Opera) or as querySelector() (as in Gecko and apparently
Webkit)...
On May 2, 2008, at 8:03 PM, Cameron McCormack wrote:
Maciej Stachowiak:
I'm not sure what NoNull is supposed to mean, but existing DOM APIs
that
take strings almost always either treat JS null the same as , or
the
same as null. I think Web IDL should define a property to
distinguish
On Apr 30, 2008, at 1:37 PM, John Resig wrote:
* Combinator-rooted Queries
I read about some prior discussion concerning this (especially in
relation to DOMElement.querySelectorAll-style queries). This is an
important part of most libraries, as it stands. Maciej's proposed
solution of
, and do the data collection serverside
instead.
It's not impossible; it just requires deviations from current
standards and probably a lot of work.
On Wednesday 2008-04-16 14:39 -0700, Maciej Stachowiak wrote:
I'd like us to understand how it is feasible to every fully solve
this
problem before
rules set a non-color property that is not set
for :visited). It also seems to still leave holes for timing attacks.
Cheers,
Maciej
-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 16, 2008 2:40 PM
To: Arve Bersvendsen
Cc: Travis Leithead
On Apr 16, 2008, at 7:50 PM, Kris Zyp wrote:
We still do not have anyway to advice user agents of long-lived
responses in order to avoid the problem of indefinitely queued
pipelined requests/responses. With both pipelining and long-lived
responses becoming more common, this seems to be
On Apr 9, 2008, at 11:07 AM, Travis Leithead wrote:
In considering a design for the event iterator (allow devs to
enumerate what events have been _added_ via addEventListener to a
given object), I looked at too general approaches:
Before analyzing the pros and cons of specific designs,
On Apr 2, 2008, at 2:44 AM, Jonas Sicking wrote:
Henri Sivonen wrote:
On Apr 2, 2008, at 00:48, Boris Zbarsky wrote:
OK. So item() would be available on Element after casting it to
NodeList in those implementations. I guess you're saying that the
cast would not longer be unambiguous
On Apr 2, 2008, at 4:52 PM, Close, Tyler J. wrote:
Sending the user's cookies, as AC4CSR does, is just not a viable
design, since the target resource cannot determine whether or not
the user consented to the request. I've posted several explanations
of the attacks enabled by this use
On Mar 19, 2008, at 12:08 AM, Maciej Stachowiak wrote:
ECMA-262 actually allows typeof to return anything at all for host
objects (which all of the DOM binding objects are). So it would not
be an ECMA-262 violation, technically, for an uncallable object to
give typeof == 'function
On Mar 18, 2008, at 2:22 PM, Travis Leithead wrote:
Not to say that I object... :)
...but why this API and not showModelessDialog too?
I'd be interested to know the rationale for this decision on
WebKit's part.
We've been shipping showModalDialog for years on Mac, but I think it
On Mar 17, 2008, at 2:29 PM, Sunava Dutta wrote:
Maciej Stachowiak [EMAIL PROTECTED] said:
But not exactly identical, since forms can't be used to POST XML
content with a proper MIME type cross-domain.
You're right-- setting an arbitrary request content-type is a
capability not present
On Mar 14, 2008, at 4:59 PM, Eric Lawrence wrote:
=
Maciej Stachowiak [EMAIL PROTECTED] asked:
How does this compare to the Cross-Site Extensions for
XMLHttpRequest standard that is being developed by Web API and Web
App Formats (and as implemented in Firefox betas)? From Apple's
On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:
Can you describe what you mean by persistent allow design?
Anne and I discussed this comment on IRC. One possible flaw is that
the OPTIONS request to guard against an unaware server receiving cross-
domain POST or other methods is
On Mar 12, 2008, at 12:25 PM, Boris Zbarsky wrote:
Is there a reason why querySelector(All) is not supported on
DocumentFragment nodes? It seems to me that such support could be
useful... It's already supported on disconnected subtrees rooted by
an Element, as far as I can tell, so
at the XHR level) and
somewhat confusing (because it will break if there's normal,
permitted DNS round-robin going on, e.g.).
Maciej, does XXX = XHR L2 or XDR?
-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 1:25 PM
To: Jonas Sicking
Cc
On Mar 14, 2008, at 1:56 PM, Jonas Sicking wrote:
I think ability to do element-rooted selector queries (either
through a new method or a :scope pseudo-element) is more important,
since it's needed to replicate the feature set of JS query libraries.
If we could get a :scope
On Mar 14, 2008, at 2:25 PM, Boris Zbarsky wrote:
Jonas Sicking wrote:
If we merge DocumentSelector and ElementSelector into simply
NodeSelector we'll more or less automatically get the functions on
DocumentFragments.
Not necessarily. I'm not advocating that all Nodes be castable to
On Mar 11, 2008, at 7:00 AM, Kris Zyp wrote:
for UAs is best approach, and that it should be a number-based
advice, not a boolean, so that it could be used more effectively
and flexibly in heuristic algorithms for making informed
pipelining decisions.
Can you be more specific in
On Mar 10, 2008, at 4:37 PM, Jonas Sicking wrote:
Kris Zyp wrote:
However, there are web apps in existence (e.g., Gmail)
that set the connection: close header to inform the
user-agent that the HTTP transaction is going to take
a long time. (This is also informative for the
server.) This
On Mar 10, 2008, at 7:34 AM, Kris Zyp wrote:
If the problem we are trying to solve is preventing potentially
long- lived requests from blowing out the connection limit I think
it would be better to either:
1) Add an explicit XHR property that indicates this request may be
long-lived -
On Mar 7, 2008, at 2:38 AM, Doug Schepers wrote:
Hi, Aaron-
Aaron Boodman wrote (on 3/6/08 8:55 PM):
I work on Google Gears team. If you're not familiar with what Gears
is, you can learn more here: http://code.google.com/apis/gears.
We've been working on an API that will allow an
On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote:
Currently getResponseHeader() returns the empty string for invalid
header names. Would people object if I changed that to returning
null instead (basically making it equivalent to headers not part of
the response)? Thanks.
What do
On Mar 7, 2008, at 3:12 PM, Anne van Kesteren wrote:
On Sat, 08 Mar 2008 00:06:02 +0100, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
On Mar 7, 2008, at 2:59 PM, Anne van Kesteren wrote:
Currently getResponseHeader() returns the empty string for invalid
header names. Would people object
On Mar 7, 2008, at 3:02 PM, Morgan L wrote:
Ah, that make sense to me. I think the current text
has caused major browser engines to mistakenly stop
supporting connection: close. It is easy to blindly
implement whatever the standards say :-)
I think it would help if a caveat were added
On Mar 6, 2008, at 7:09 AM, Kris Zyp wrote:
Thanks for the heads up, Mark, I will be watching the activity
there, that would be great if the problem can be dealt with in that
group.
However, the issues of responses being indefinitely queued in
pipelining situations and unbounded memory
On Feb 19, 2008, at 7:55 AM, Kris Zyp wrote:
Extra Connection Support
The XMLHttpRequest should define a property called
extraConnection. When
extraConnection is set to true, it indicates that this XHR object's
connection SHOULD NOT be counted against the user agent's connection
limit.
On Feb 19, 2008, at 11:12 AM, Robert Sayre wrote:
On Feb 19, 2008 1:50 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Probably the appropriate forum to make this proposal would be the
IETF
HTTP Working Group. I'll join the appropriate mailing list if others
are interested in pursuing
On Feb 8, 2008, at 12:03 PM, Charles McCathieNevile wrote:
On Fri, 08 Feb 2008 22:22:59 +0530, Chris Wilson [EMAIL PROTECTED]
wrote:
2) In fact, on that note, we're interested to see the test suite be
linked, normatively if necessary.
Yes. I think this is a valuable piece of
Hi Doug,
On Feb 7, 2008, at 2:32 PM, Doug Schepers wrote:
Hi, Anne-
I'm stepping in here to inform on a matter of process. This is not
a judgment on the technical merits of either position.
Anne van Kesteren wrote (on 2/7/08 5:42 AM):
o As per our agreement in the tech plenary the
On Dec 17, 2007, at 5:44 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
On Dec 14, 2007, at 4:11 PM, Jonas Sicking wrote:
Julian Reschke wrote:
Jonas Sicking wrote:
Does any currently released browse include the body when doing
an XHR GET request? If a big majority of them currently
On Dec 10, 2007, at 6:05 AM, Julian Reschke wrote:
I think my bottom line is the same as Boris's, I would like to see
the spec allow XHR implementations not to send GETs with an entity-
body.
I would argue that both the simplest thing and the right thing here
is not to state anything
On Dec 10, 2007, at 11:16 AM, Charles McCathieNevile wrote:
On Mon, 10 Dec 2007 17:54:49 +0100, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
What would look compelling to me is web content depending on the
specific names. That's more important than whether someone shipped
On Oct 13, 2007, at 8:44 PM, Cameron McCormack wrote:
Hi group.
The SVG WG is currently tightening the description of the getURL and
postURL methods so that it is clear what to do when faced with non-
HTTP
IRIs. You can see the current definition here:
On Sep 27, 2007, at 1:20 AM, Mike Wilson wrote:
There is a possible alternate goal of documenting for authors what
current implementations do and giving them enough information to
target the interoperable subset.
I too haven't followed the XHR discussion in detail for a while, but
I
Hi Sunava,
Thanks for sending this feedback.
Here are my high-level comments:
1) I am strongly opposed to greatly weakening the implementation
conformance requirements. Changing the spec requirements so that
existing implementations, even if they vary significantly in behavior,
are
On Sep 26, 2007, at 12:41 AM, Maciej Stachowiak wrote:
Hi Sunava,
Thanks for sending this feedback.
Here are my high-level comments:
1) I am strongly opposed to greatly weakening the implementation
conformance requirements. Changing the spec requirements so that
existing
On Sep 25, 2007, at 2:29 AM, Steve K Speicher wrote:
These comments are regarding the 18-June-2007 XMLHttpRequest WD [1]
and a
bit delayed but hopefully still useful.
1) #conformance for Comforming user agent, it states:
If the user agent does not support XML (including support for
On Sep 25, 2007, at 5:53 AM, Anne van Kesteren wrote:
On Wed, 29 Aug 2007 08:51:29 +0200, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
Could you say how you'd envision the fix to address the problem?
The current spec doesn't define same origin at all. Thinking
about it more though
On Sep 21, 2007, at 3:34 AM, Anne van Kesteren wrote:
On Wed, 29 Aug 2007 05:04:24 +0200, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
Since this affects interoperability as well as security I would
suggest adding a definition, unless the spec expected to define
same-origin is going
On Aug 28, 2007, at 8:25 PM, Bjoern Hoehrmann wrote:
* Maciej Stachowiak wrote:
The XHR spec doesn't define same-origin. We had a webkit bug filed
differently where we apparently interpreted same-origin differently
than IE or Firefox: http://bugs.webkit.org/show_bug.cgi?id=15100
On Aug 29, 2007, at 12:03 AM, Boris Zbarsky wrote:
Maciej Stachowiak wrote:
Any definition of a same-origin policy would have to define how to
determine the hostname and port.
For what it's worth, an origin in Gecko also includes the scheme.
This handles things like http-to-https
On Aug 29, 2007, at 12:52 AM, Bjoern Hoehrmann wrote:
* Maciej Stachowiak wrote:
The requests will be sent with different 'Host' http request headers
headers. A server configured as a virtual host could easily return
different content for example.com:443 and example.com. So it's
The XHR spec doesn't define same-origin. We had a webkit bug filed
differently where we apparently interpreted same-origin differently
than IE or Firefox: http://bugs.webkit.org/show_bug.cgi?id=15100
In particular, we would not consider https://example.com:443/ to be
the same origin as
On Aug 2, 2007, at 6:12 AM, Anne van Kesteren wrote:
On Tue, 31 Jul 2007 01:00:14 +0200, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
I'm a little bit worried that if we enable scripts for XHR (they
are currently disabled in firefox) that sites would break. Though
chances are probably
On Jul 29, 2007, at 1:27 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
On Jul 28, 2007, at 4:04 AM, Anne van Kesteren wrote:
Jonas already mentioned it in another e-mail and this feature was
indeed planned (by me 8-)) for XMLHttpRequest level 2.
responseText already follows text
On Jul 27, 2007, at 12:09 PM, Jonas Sicking wrote:
Anne van Kesteren wrote:
I've been looking at overrideMimeType implementations in Gecko and
WebKit and it seems like they differ a bit. In Gecko it has to be
invoked before send(), but in WebKit it would work if you invoke it
just
On Jul 28, 2007, at 11:38 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
On Jul 27, 2007, at 12:09 PM, Jonas Sicking wrote:
Anne van Kesteren wrote:
I've been looking at overrideMimeType implementations in Gecko
and WebKit and it seems like they differ a bit. In Gecko it has
On Jul 28, 2007, at 4:04 AM, Anne van Kesteren wrote:
Jonas already mentioned it in another e-mail and this feature was
indeed planned (by me 8-)) for XMLHttpRequest level 2. responseText
already follows text/html rules for encoding detection etc. but for
parsing we probably need to
On Jul 27, 2007, at 8:49 AM, Anne van Kesteren wrote:
Internet Explorer 7 supposedly introduced a new responseBody member
for XMLHttpRequest that returns an array of unsigned integers.
Likewise, send() now accepts such an argument. However, I've been
unable to make it work. I'm
On Jul 27, 2007, at 9:00 AM, Anne van Kesteren wrote:
I've been looking into integrating progress events into
XMLHttpRequest. In general it is pretty trivial to do for the
request non-uploading scenario. loadstart is dispatched right after
the first readystatechange event is dispatched
On Jul 19, 2007, at 10:07 AM, Bjoern Hoehrmann wrote:
Hi,
The WebAPI Working Group is considering to conduct a poll to finally
put the method naming issue in the CSS Query API specification to
rest;
Charles asked us to propose alternatives to selectElement/
selectAllEle-
ments. To this
On Jul 2, 2007, at 11:17 AM, Doug Schepers wrote:
Hi-
Maciej Stachowiak wrote:
I don't have a strong objection either way, but I think the case
against Lachy's original names (selectElement, etc) has been laid
out more clearly than the case against cssQuery. I think
selectorQuery
On Jul 2, 2007, at 3:50 PM, Charles McCathieNevile wrote:
On Mon, 02 Jul 2007 20:17:40 +0200, Doug Schepers
[EMAIL PROTECTED] wrote:
Hi-
Maciej Stachowiak wrote:
I don't have a strong objection either way, but I think the case
against Lachy's original names (selectElement, etc) has
On Jun 27, 2007, at 11:38 AM, Doug Schepers wrote:
Hi, Jean-Yves-
Jean-Yves Bitterlich wrote:
We find it unfortunate that past resolutions within the working
group are being invalidated (unless of course there are new
evidences/information that justify this act) in particular because
On Jun 19, 2007, at 2:03 PM, Rotan Hanrahan wrote:
Despite my earlier indication to refrain from further comment, I
return because I observe some discussion is taking place.
I propose that the text that introduces an algorithm in the
normative section be phrased something like the
On Jun 5, 2007, at 10:15 PM, Boris Zbarsky wrote:
Cameron McCormack wrote:
This is probably not what browsers do in practice, though. For
example,
Opera 9 has an addEventListener method directly on the Node interface
prototype object
What Gecko does is to put all properties for all the
On Jun 5, 2007, at 10:52 PM, Ian Hickson wrote:
On Wed, 6 Jun 2007, Boris Zbarsky wrote:
To be honest, do we really think that specifying the exact prototype
chain is desirable? How likely are UAs to rework the mappings
between
their native code and ECMAScript to follow said spec?
On Jun 4, 2007, at 7:52 PM, liorean wrote:
On 05/06/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I think DOM properties (and sometimes methods and function arguments)
vary on this. Some use the raw ECMAScript ToString algorithm. Others
additionally map the null value to the empty string
On May 21, 2007, at 4:01 AM, Stewart Brodie wrote:
Anne van Kesteren [EMAIL PROTECTED] wrote:
On Mon, 21 May 2007 03:33:39 +0200, Cameron McCormack [EMAIL PROTECTED]
wrote:
Implementors that use the IDL to generate code for the
implementations:
which would you prefer?
Do implementors
On May 14, 2007, at 9:26 AM, Bjoern Hoehrmann wrote:
* Anne van Kesteren wrote:
It was added for compatibility with WebKit. I don't really feel
strongly
about it, ...
Excellent, I then look forward to a proposal that Jonas and I do not
regard as inappropriate.
I don't personally feel
On May 8, 2007, at 1:25 PM, Jonas Sicking wrote:
Anne van Kesteren wrote:
* text/xsl has been added as a MIME type that causes
responseXML to return a Document object (if the resource
can indeed be parsed according to the XML specfications.)
Again, for compatibility reasons.
On May 8, 2007, at 2:08 PM, Jonas Sicking wrote:
Jonas Sicking wrote:
Anne van Kesteren wrote:
On Tue, 08 May 2007 13:20:21 +0200, Stewart Brodie
[EMAIL PROTECTED] wrote:
The send() event seems to have changed considerably since the
previous
drafts that I saw. I think that you need
Maciej Stachowiak [EMAIL PROTECTED]
Maciej Stachowiak [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
05/07/2007 04:16 PM
ecblank.gif
To
ecblank.gif
Innovimax SARL [EMAIL PROTECTED]
ecblank.gif
cc
ecblank.gif
Anne van Kesteren [EMAIL PROTECTED], public-webapi@w3.org
ecblank.gif
Subject
On Apr 3, 2007, at 9:50 AM, Doug Schepers wrote:
Hi-
The issue of live vs. static lists is actually orthogonal to my
main question (though that would be a relevant argument to bring to
the Selectors spec, which uses a static list... I think that ship
may have sailed, though).
The
On Mar 30, 2007, at 2:31 PM, Simon Pieters wrote:
In the send(data) algorithm, step 3, says:
data is not a DOMString or Document
The stringification mechanisms of the host language must be
used on
data and the result must be treated as if data is a DOMString.
I'm not sure
Hi Everyone,
I've just joined the group, along with my Apple colleagues, Adele
Peterson and Dave Hyatt. I am starting to see some substantive
discussion on the public-html list, mostly in the archives.
I realize there is a desire for rapid progress. But can we please
hold off on making
On Mar 9, 2007, at 8:43 AM, Anne van Kesteren wrote:
Some initial drafts used to have this and it was removed because of
comments, iirc, from Maciej among other people. If enough authors
and implementors support this idea though I suppose we can
reconsider that. Anyone?
I think at
On Mar 7, 2007, at 12:45 AM, Anne van Kesteren wrote:
On Wed, 07 Mar 2007 08:38:41 +0100, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
When the size is known, that knowledge is not necessarily accurate.
Can you cite an example?
Content-Length: 2
Content-Type: text/plain; charset=us
On Mar 6, 2007, at 10:39 PM, Charles McCathieNevile wrote:
On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote:
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/
Progress.html?rev=1.8
I would
On Mar 7, 2007, at 4:40 PM, Web APIs Issue Tracker wrote:
ISSUE-113: How do we represent HTTP POST?
http://www.w3.org/2005/06/tracker/webapi/issues/113
Raised by: Charles Mccathienevile
On product: Progress Event
POST can upload a pile of stuff, and then download a body. So there
are
On Mar 6, 2007, at 5:18 AM, Anne van Kesteren wrote:
On Tue, 06 Mar 2007 14:02:42 +0100, Robin Berjon [EMAIL PROTECTED]
wrote:
On Mar 06, 2007, at 02:49, Maciej Stachowiak wrote:
This would require a change in XHR to adopt the Progress Events
spec, but would considerably simplify Progress
On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote:
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/
Progress.html?rev=1.8
I would appreciate review, and in particular propose to publish
this spec as a First Public Working Draft more or less in its
current shape.
I
On Mar 6, 2007, at 10:39 PM, Charles McCathieNevile wrote:
On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
- User agents may dispatch one or more ProgressEvent of type
progress while a network operation is taking place. -- per my
earlier use cases document
1 - 100 of 151 matches
Mail list logo
