On Sun, 23 Apr 2006 02:34:08 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Otherwise, if the Content-Type header contains a media type (ignoring
any parameters) that is either text/xml, application/xml, or ends in
+xml, it must be an object that implements the Document interface
On Sun, 23 Apr 2006 05:18:24 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
That being said, whether all methods are uppercased or only the methods
that get significant use, is not really a major issue. But let's not
just casually increase spec complexity without doing our due
Web APIs Issue Tracker wrote:
ISSUE-77: DOM3EV: Effect of evt.currentTarget.add/removeEL
http://www.w3.org/2005/06/tracker/webapi/issues/77
Raised by: Bjoern Hoehrmann
On product: DOM 3 Events
The effects of evt.currentTarget.add/removeEventListener are well-
defined in the current draft but
Maciej Stachowiak wrote:
On Apr 21, 2006, at 9:33 AM, Mark Nottingham wrote:
[ from the big comment e-mail; raising as a separate issue, as
requested ]
The current draft says that:
If the method is POST or PUT, then the data passed to the send()
method must be used for the entity
* Jonas Sicking wrote:
I agree, i think having add and remove behave the same would be a good
idea. I'm not sure if we can actually change this though if the DOM L2
spec is indeed clear on the behaviour.
It certainly possible to change the specification, but we indeed need to
consider the
David Flanagan wrote:
Your XMLHttpRequest draft of 05 April 2006 specifies that XMLHttpRequest
should automatically include cookies in outgoing requests.
But it does not specify what should be done with cookies included in
incoming responses.
What does current implementations do? Are the
On Apr 23, 2006, at 11:51, Anne van Kesteren wrote:
On Sun, 23 Apr 2006 05:18:24 +0200, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
That being said, whether all methods are uppercased or only the
methods that get significant use, is not really a major issue. But
let's not just casually
On Apr 23, 2006, at 6:57 AM, Robin Berjon wrote:
On Apr 23, 2006, at 11:45, Anne van Kesteren wrote:
On Sun, 23 Apr 2006 02:34:08 +0200, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
Otherwise, if the Content-Type header contains a media type
(ignoring any parameters) that is either
At the moment, Gecko allows adding a single onreadystatechange listener that's
notified of changes in readyState. We would like to add the ability to add such
listeners via addEventListener; the event name would be readystatechange.
The timeline for this would be to make the change in
At the moment, Gecko allows adding a single onprogress DOMEventListener that's
notified of download progress.
We would like to make two changes to the progress event setup:
1) Allow adding progress event listeners via addEventListener, not just via
setting the onprogress property. The
* Maciej Stachowiak wrote:
Should this be taken to mean that for any other Content-Type,
implementations MUST NOT attempt to parse as XML? If so, please say
that. Optionally allowing XML parsing for types not specifically
mentioned would be bad for interoperability.
It should say that
On Apr 23, 2006, at 12:12 PM, Bjoern Hoehrmann wrote:
* Maciej Stachowiak wrote:
Should this be taken to mean that for any other Content-Type,
implementations MUST NOT attempt to parse as XML? If so, please say
that. Optionally allowing XML parsing for types not specifically
mentioned would
* Brad Fults wrote:
That said, I see this not as a case in need of additional
optimization, but a case requiring the removal of
specification-mandated bloat that is by no means temporary.
The case you've presented makes a number of assumptions, including that
* the extension actually comes
* vendors are not allowed or simply won't implement some other
vendors' proprietary extensions. The proposed text does not
prohibit that and e.g. ActiveXObject(Microsoft.XMLHTTP) has
been implemented in more than just one browser, even though it
follows a vendor-name naming
On Apr 23, 2006, at 12:34 PM, Bjoern Hoehrmann wrote:
* Brad Fults wrote:
That said, I see this not as a case in need of additional
optimization, but a case requiring the removal of
specification-mandated bloat that is by no means temporary.
The case you've presented makes a number of
On Apr 21, 2006, at 1:57 PM, Jim Ley wrote:
Well it pretty much says do what you want!
http://www.ecma-international.org/publications/files/ECMA-ST/
Ecma-262.pdf
section 2
A conforming implementation of ECMAScript is permitted to provide
additional types, values, objects,
properties,
* Maciej Stachowiak wrote:
None of the existing vendor extensions to XMLHttpRequest follow the
vendor prefix naming convention. So far as I know, every major
implementation has at least one extension relative to the current
proposed spec. Therefore, requiring a vendor prefix would put all
Hi Boris,
On Apr 23, 2006, at 20:51, Boris Zbarsky wrote:
At the moment, Gecko allows adding a single onreadystatechange
listener that's notified of changes in readyState. We would like
to add the ability to add such listeners via addEventListener; the
event name would be
* Maciej Stachowiak wrote:
Should implementations be allowed or required to use intrinsic
knowledge from other sources than media type registration? For
example, suppose my user agent recognizes image/svg-xml or text/
xsl. Should it then treat these as XML, even though they are
* Robin Berjon wrote:
Have you considered being compatible (if only by subset) with SVG
Tiny 1.2 progress events?
http://www.w3.org/TR/SVGMobile12/interact.html#EventsLoadProgress
http://www.w3.org/TR/SVGMobile12/svgudom.html#events::ProgressEvent
SVG could
On Apr 23, 2006, at 23:26, Bjoern Hoehrmann wrote:
SVG could http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-
LSParser
consider compatible with existing specifications also...
Weren't you at the meeting where D3LS was deemed unofficially
obsolete? ;)
More seriously, I think you
* Robin Berjon wrote:
More seriously, I think you meant LSProgressEvent no? It has various
issues, some of which being that it is defined in a way that assumes
XML by discussing external entities, and is also defined in terms of
parsing and not data acquisition. None of this makes much
Anne van Kesteren wrote:
On Fri, 03 Mar 2006 20:41:38 +0100, Jonas Sicking [EMAIL PROTECTED] wrote:
I think there is need for some perspective here. Mozilla isn't broken
in that .send doesn't work at all or that we in some cases have very
broken behaviour. We simply follow DOM convention
Maciej Stachowiak wrote:
The only one not on the current list that Safari supports is text/ xsl.
I don't care that much about it, but it is far more widely used than
the official application/xslt+xml and for various reasons (namely the
fact that IE insists on text/xsl for XSL stylesheets)
24 matches
Mail list logo
