Options would be:
1) forget about defaultView, just have parentWindow
2) don't add parentWindow
3) keep both
I favor #3.
I can't say that I feel strongly about it, but having both seems sort of
redundant. What is the advantage over having just one of the two? If we
add both only opera is
Cameron McCormack wrote:
Web APIs Issue Tracker:
Should Location.toString() be removed from the IDL? Both Java and JavaScript happen to have string
conversion methods named toString() already. Perhaps we should just define what happens when
converting to string regardless of the language
Anne van Kesteren wrote:
On Mon, 03 Apr 2006 18:05:56 +0200, Jim Ley [EMAIL PROTECTED] wrote:
The decision at the f2f was that the going to 4 was relied on by
people, used in situations such as hiding the please wait etc. I
think this should continue to be the resolution.
That doesn't
It's all done at the binding level, so I'm not sure it's a solution
that IDL-based implementations like Mozilla would like. Just look at
http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html, where
it says: Object EventListener: This is an ECMAScript function
reference (the
I would tentatively say the following are not valid reasons to restrict
a header:
4) It could result in content that the UA might not be able to parse as
text or as XML (this can happen anyway with no custom headers).
If a header will always cause the UA to not be able to parse the
However, exposing these functions to web pages does not sound like it
is a requirement to you, is that correct? If that is the case, but you
still want an API defined to access this information, maybe we could
define a separate API specifically for accessibility tools that DOM
Ian Hickson wrote:
But I would add one more. Authors are stupid. We shouldn't provide them
with features whose only possible use is for them to shoot themselves in
the foot. In other words, I would phrase the question not as which
headers should we restrict, but which headers should we allow,
Jim Ley wrote:
Jonas Sicking [EMAIL PROTECTED]
Though the usecase for Accept-Charset seems fairly weak. Why couldn't
the author simply filter responseText?
How would an author do that? Or do you mean the ASCII use case, and not
might accessibility tool use case?
The only use case I've
If we do go to state 4 then things will look almost exactly like a
successful response. The only difference is that .responseXML will be
null, but that is already the case for a lot of consumers that send
non-xml data.
I'd sort of disagree, the problem will manifest itself by the result not
The problem is that many formats can't detect that they have been cut
off. Even for something as strict as XML you could be loosing comments
and PIs at the end of the document if the transation is terminated.
The reason responseXML would be null in mozilla is that we'd get an
internal
Maciej Stachowiak wrote:
There's been some discussion of what request headers, if any,
XMLHttpRequest should disallow for setREquestHeader.
I think we really need a clear idea of what we are trying to do by
restricting headers. I propose that the following are valid reasons to
forbid
Anne van Kesteren wrote:
On Tue, 11 Apr 2006 23:54:43 +0200, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
* Web APIs Issue Tracker wrote:
ISSUE-75: Is method case-sensitive?
We resolved that yes, the parameter is case-sensitive. This implies that
scripts like those in the draft are
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
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
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)
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
In many cases the user might know the size even if the implementation
does not. Or it is even imaginable that the script knows the size even
if the XHR class does not. In both these cases the number of bytes
transferred is useful to present
The WebAPI WG would like to solicit feedback about Event Groups,
particularly from implementors. Do Event Groups fill a current need? Are
they implemented in your UA, or are you planning to do so? Are they used by
authors in the wild?
Basically, are there compelling reasons to either keep
Bjoern Hoehrmann wrote:
* Web APIs Issue Tracker wrote:
Bjoern proposes that it always have a value of 2. This would be
consistent with all known browsers except Safari on the Mac, since
that is currently the only browser to fire dblclick for even click
counts greater than 2.
I would
Boris Zbarsky wrote:
Anne van Kesteren wrote:
What we resolved for ISSUE-29 is that the XHR object has an intrinsic
property holding Window.document.baseURI from the Window it was
created in.
How is that defined? Say if I do:
var xmlHttp = new window.opener.XMLHttpRequest();
which
liorean wrote:
On 13/05/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Sat, 13 May 2006 21:08:26 +0200, liorean [EMAIL PROTECTED] wrote:
And StaticNodeList looks to me to be pretty array-like.
Well, if StaticNodeList looks that way NodeList would look that way too
and I'd therefore
Robin Berjon wrote:
On May 30, 2006, at 15:55, Ian Hickson wrote:
On Tue, 30 May 2006, Jonas Sicking wrote:
What we could maybe do though is to return a real ECMAScript array. I
actually like this idea a lot since that'll integrate much better with
scripts than a StaticNodeList would
Anne van Kesteren wrote:
On Wed, 31 May 2006 00:11:23 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
I'm not in love with having match in the name, but I could live
with matchAll() and matchOne().
I like these names. Having short names is nice and all, but having
clear ones is even better
Hi all,
Looking at the new progress event spec it looks great. I don't
understand why it requires that 'loadstart' and 'progress' be fired
before error though. For example if the requested uri can't even be
parsed as a real uri it seems sensible to fire an error event right away
and abort
Bjoern Hoehrmann wrote:
* Anne van Kesteren wrote:
The latest version of the draft (1.14) assumes (in an example) that you
take prefixes from left to right and requires (in prose) that you reuse
the result for each unique (after lowercasing) prefix.
I think the draft should only define
Anne van Kesteren wrote:
Given the input from Björn I suppose there's no real need for a method
that returns a single element node (assuming implementations make that
optimization). Given that, I propose we rename .getAll() to
.getElementsBySelector() and drop .get() (on both Document and
Lachlan Hunt wrote:
Jonas Sicking wrote:
Bjoern Hoehrmann wrote:
* Anne van Kesteren wrote:
The latest version of the draft (1.14) assumes (in an example) that
you take prefixes from left to right...
x|y:empty a|b
... In short, defining this would expose implementations details
Anne van Kesteren wrote:
On Sat, 21 Apr 2007 08:15:50 +1000, Jonas Sicking [EMAIL PROTECTED] wrote:
Looking at the new progress event spec it looks great. I don't
understand why it requires that 'loadstart' and 'progress' be fired
before error though. For example if the requested uri can't
Anne van Kesteren wrote:
On Sat, 21 Apr 2007 09:28:22 +1000, Jonas Sicking [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
Given the input from Björn I suppose there's no real need for a
method that returns a single element node (assuming implementations
make that optimization). Given
You can define getters and setters in javascript that throw. Please
refer to javascript tutorials for how to do this.
Best Regards,
Jonas Sicking
Subbu Allamaraju wrote:
I have a question on the nature of implementations possible for XHR. In
particular, would the following be a valid
Charles McCathieNevile wrote:
On Tue, 24 Apr 2007 08:25:58 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Mon, 23 Apr 2007 14:44:53 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
[...]
I think you do want at least one loadstart and progress event before
that event though.
Why
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.
There is no need for the draft to encourage use of
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 more explanation for the
bizarre readystatechange event during step 5 of the
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 more explanation for the
bizarre readystatechange event
Maciej Stachowiak wrote:
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
Maciej Stachowiak wrote:
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
Maciej Stachowiak wrote:
If we are making the list absolute, I feel weird about including
things like 'text/xsl' and 'text/rdf' as neither of them are real
mimetypes. Is there really a lot that would break if 'text/xsl' was
not included?
No clue. I don't think it's bad to make requirements
Alexey Proskuryakov wrote:
2) Firefox 2 recognizes anything with xml in it (e.g. fooxml/bar).
I really doubt that is the case. Could you provide a testcase showing
this to be true?
/ Jonas
Boris Zbarsky wrote:
Bjoern Hoehrmann wrote:
http://www.bjoernsworld.de/temp/axmlb-test.html alerts FAIL in browsers
treating axmlb/test as XML type, which my versions of Firefox do; so it
does seeem true to me. `text/rdf` btw, does not seem to be supported as
XML type for XHR purposes in
Maciej Stachowiak wrote:
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
liorean wrote:
For my purposes, if the application is processing element content, it
needs to raise an error if non-whitespace text is found. If it is
processing mixed content, it needs to pass the skipped content back to
the caller. I cannot think of the case where non-whitespace text
should
[EMAIL PROTECTED] wrote:
Hi folks,
we need to figure out what is really needed.
A big requirement is security. It must not be possible to connect to an
arbitrary port on the server and send anything, unless the server has
explicitly stated that it allows so using some sort of
Maciej Stachowiak wrote:
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
Julian Reschke wrote:
Jonas Sicking wrote:
The XHR spec currently allows users to set the Proxy-Connection
header using setRequestHeader method. I couldn't find a spec for it
other than some discussions here:
...
As far as I can tell, the spec doesn't even mention the header.
Are you
Hi All,
A couple of questions regarding the cross-site XHR proposal:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest
cross-site requests should alway have the headers set through
setRequestHeader removed. This
Jonas Sicking wrote:
Hi All,
A couple of questions regarding the cross-site XHR proposal:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest
cross-site requests should alway have the headers set through
Julian Reschke wrote:
Jonas Sicking wrote:
Jonas Sicking wrote:
Hi All,
A couple of questions regarding the cross-site XHR proposal:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest
cross-site requests should
it feels to me like
redirects and non-GET requests cross site is a rare edge-case and not
something that is particularly important. So we might as well do the
safe thing. I could even see disallowing redirects entirely, even for
the initial GET request.
Best Regards,
Jonas Sicking
Anne van Kesteren wrote:
On Mon, 23 Jul 2007 10:35:27 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
A couple of questions regarding the cross-site XHR proposal:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012
As detailed in http://wiki.mozilla.org/Cross_Site_XMLHttpRequest
Anne van Kesteren wrote:
It seems nicer however to not restrict it to XMLHttpRequest and define
the entire retrieval algorithm in the access-control specification
including how it works for other methods and in face of redirects.
I agree. I don't really want to hold up the [ac] spec though.
Anne van Kesteren wrote:
On Fri, 27 Jul 2007 21:09:37 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
It does seem fairly complicated to allow it to be set after the
download is finished though. You do have the stream stored in
.reponse[Text], but at that point all encoding information has
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 state that it needs to run with
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 to be
invoked before send(), but in WebKit it would work
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/html rules for encoding detection etc. but for
Alexey Proskuryakov wrote:
On 7/30/07 12:21 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
If XHR2 offers responseBody with a raw byte array of some kind, it will
be required for implementations to keep the raw bytes around anyway.
Yep. Though it still seems weird to me that responseText would
Anne van Kesteren wrote:
By the way, a request to a same-origin redirect that redirects to a
non same-origin resource should also work I suppose? Or is there some
reason you need to know in advance you're going to make a non
same-origin request?
For GET requests I don't see a reason to not
Anne van Kesteren wrote:
On Mon, 06 Aug 2007 23:39:28 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Given domain A and B I wonder if it's a problem if when a request is
done from A, B can feed information back to A (through the URL;
http://domain-a.org/?data=data) without any sort of access
Boris Zbarsky wrote:
Anne van Kesteren wrote:
I think HTML5 needs to define this as my understanding is that
document.domain is also relevant in deciding whether or not a request
is same-origin.
Actually, I don't think it is. I know IE and Gecko ignore
document.domain for the existing
Mike Wilson wrote:
But it turned out in the course of developing the spec that there
were enough individually small differences to make such an excercise
fruitless.
Considering that IE invented XHR (apart from the object
naming), couldn't the first version of the spec just
L. David Baron wrote:
There are a number of interfaces, used as callbacks, like
EventListener [1], NodeFilter [2], and UserDataHandler [3], and
XPathNSEventResolver [4] where an interface has a single method and
is intended to be implemented by the DOM user as a callback. In
ECMAScript
Anne van Kesteren wrote:
On Mon, 10 Dec 2007 15:47:37 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
3) The spec as written doesn't state nothing, it appears to clearly
require sending an entity body and does not allow ignoring the body or
throwing an exception regardless of what is
Stewart Brodie wrote:
Jonas Sicking [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
On Mon, 10 Dec 2007 15:47:37 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
3) The spec as written doesn't state nothing, it appears to clearly
require sending an entity body and does not allow ignoring
Mark Baker wrote:
On 12/14/07, Jonas Sicking [EMAIL PROTECTED] wrote:
Actually, once we're supporting cross site GET requests, I think we
there should definitely mention that the entity body of GET (and
probably HEAD) requests are dropped. Otherwise there is some risk that
there are servers
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 drop the body,
then it seems like it would help
Anne van Kesteren wrote:
Maybe the draft already says something about this, but I couldn't find
it. I think it would be good if there was a way in the IDL to say what
an object stringifies to. The Window object becomes [object Window]
and Location stringifies to its href attribute value.
Doug Schepers wrote:
Moreover, this is, in fact, what this WG was chartered to do regarding XHR:
This deliverable should begin by documenting the existing
XMLHttpRequest interface.
The question becomes, is IE's implementation to be considered canonical,
or is it up to interpretation vis a
Hi Sunava,
Thanks for your feedback. I had a couple of additional comments on top
of the ones Anne had.
On Thu, 07 Feb 2008 02:57:50 +0100, Sunava Dutta
[EMAIL PROTECTED] wrote:
o This spec is very different from existing HTML/CSS/DOM spec where
the functionality/API specification is the
Anne van Kesteren wrote:
On Fri, 15 Feb 2008 19:36:21 +0100, Jonas Sicking [EMAIL PROTECTED] wrote:
Lachlan Hunt wrote:
I have added the following text to the spec:
If the user agent also supports some level of CSS, the
implementation
must support the same set of selectors
Anne van Kesteren wrote:
On Tue, 19 Feb 2008 10:43:14 +0100, Boris Zbarsky [EMAIL PROTECTED] wrote:
The only solution I'm seeing so far to a hanging NSResolver is
terminating that script at some point.
Is that what you're doing for treewalker node filters?
Yes.
I'm not sure why we should
Lachlan Hunt wrote:
Boris Zbarsky wrote:
Anne van Kesteren wrote:
To ensure that naïve implementors don't overlook the potential
issue here. An implementation of NSResolver can be provided by the
script author as the specification explains and the script author
can do all kinds of weird
never have pipelining. That
won't lead to progress. This is our best opportunity to have an inroad
to pipelining, via consenting authors.
Kris
- Original Message - From: Jonas Sicking [EMAIL PROTECTED]
To: Kris Zyp [EMAIL PROTECTED]
Cc: public-webapi@w3.org; Mark Baker [EMAIL PROTECTED]
Sent
Stewart Brodie wrote:
Kris Zyp [EMAIL PROTECTED] wrote:
We are still faced with the fundamental problem that if a browser that
observes the two connection limit and two long-lived connections are
currently open and the user does something that triggers another request
(such as opening another
Collin Jackson wrote:
On Tue, Feb 19, 2008 at 1:10 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
specification we'd have to chose a header name that starts with
Proxy-. There have been many other proposals for new
security-related HTTP headers (e.g. content restrictions) so it would
be
Kris Zyp wrote:
you click on a link, does the link get followed? That is the same
sort of
scenario, isn't it?
At least firefox will abort any existing downloads for the current
page when the user clicks a link. But if you're downloading these
images in another tab you might have this
Morgan L wrote:
Hi, I'm writing about what appears to be an error in
the XHR TR.
In section 2 of http://www.w3.org/TR/XMLHttpRequest/,
it says that setRequestHeader should reject the
connection header.
However, there are web apps in existence (e.g., Gmail)
that set the connection: close
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 if I changed that to returning
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 allows a user-agent to not count this
connection
Jeff Schiller wrote:
I'm not well-versed on the history behind document.domain and how the
web depends on it being writable. Can someone send me a pointer?
I can understand not letting the embedded object get at the elements
outside of the HTMLObjectElement, but this seems like a weird design
Boris Zbarsky wrote (on 3/13/08 3:11 PM):
It would have
been great if HTMLObjectElement had an accessible params NodeList
readonly attribute :(
Yes, indeed. It's not too late to add that!
Boris, do you mean that it's not too late to add that to Fx3? What
about window.paramList?
It's
How do you define the Intranet, Internet, Restricted etc zones?
Without correct definitions for these zones it seems possible to attack
intranet servers by sending unsafe (such as POST or DELETE) requests to
intranet servers from internet pages.
I'd also recommend sending this to the web
Jonas Sicking wrote:
How do you define the Intranet, Internet, Restricted etc zones?
Without correct definitions for these zones it seems possible to attack
intranet servers by sending unsafe (such as POST or DELETE) requests to
intranet servers from internet pages.
I'd also recommend sending
Can you describe what you mean by persistent allow design?
/ Jonas
Chris Wilson wrote:
Oops. Obviously, this was not to go to the whole group.
I’ve been asked a lot, over the last week and a half, why we implemented
XDR rather than the current cross-domain XHR proposals. The short
as they relate to this exact subject.
/ Jonas
Jonas Sicking wrote:
So the worry here is a scenario where an attacker tricks a user to go to
evil.com which does an evil POST to webstore.com. And at the same time
the attacker launches a DNS rebind attack on the user for the
webstore.com domain name
Laurens Holst wrote:
Laurens Holst schreef:
Or, if you really do not want to increase the attack surface, you
should always send the content type application/x-www-form-urlencoded,
and only allow request entities constructed through an API. Because
servers only expect x-www-form-urlencoded
Lachlan Hunt wrote:
Anne van Kesteren wrote:
On Fri, 14 Mar 2008 01:18:27 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
Maybe the best solution would be to add a :scope pseudo-element which
is the target of the querySelectorAll call if not called on the
document. That would allow
,
Jonas Sicking
Eric Lawrence wrote:
Ian--
Thanks for sharing your opinions. I'd like to take the opportunity to clarify
a few points of confusion.
This is blatently untrue, a number of serious security problems with XDR
have already been raised (such as the fact that it encourages content-type
sniffing
Bjoern Hoehrmann wrote:
* Daniel Glazman wrote:
1. congrats for this spec, I love it ; I can't count how many times in
page or chrome script I am filtering out nodes that are not element
nodes.
2. the ElementTraversal interface has a |childElementCount| attribute
but misses access to
If we're not 100% compatible with SVG, why would they oppose an
improvement like the suggested one?
Content that uses childElements[...] would not function correctly
in SVG Tiny 1.2 implementations for no particularily good reason.
I'm not following this argument at all. Neither would
Julien Chaffraix wrote:
Hi everyone,
We are in the process of implementing XHR onprogress attribute on
WebKit and arises a compatibility issue with the Firefox
implementation.
Currently the XHR2 draft specifies that we use the ProgressEvent
interface for onprogress events whereas Firefox uses
Daniel Glazman wrote:
I'm actually not sure. How often do authors want to get the third
child without knowing anything more about it than that it's an
element? Iterating through the kids (by means of ET or '.childNodes')
gives you much more context information (what type of element it is,
Henri Sivonen wrote:
On Apr 2, 2008, at 12:44, Jonas Sicking wrote:
And to what end? To use indexing instead of list-style iteration.
Exactly. Something that I would imagine is quite commonly done. Note
that we're not just talking iterating over a full DOM tree, we're also
talking about
Anne van Kesteren wrote:
On Wed, 02 Apr 2008 08:54:17 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
This is definitely a good question, one that I'd like to see addressed
too.
I think that if the spec remains as is Firefox would likely fire
events that implements both the ProgressEvent
Daniel Glazman wrote:
Jonas Sicking wrote:
Bjoern Hoehrmann wrote:
We could also standardize the popular .getChildrenByTagName() method,
that would give the similar
myFooElement.getChildrenByTagName(*)[3]
This seems like an excellent idea. To do in addition to the
ElementTraversal spec
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
I'm not following this argument at all. Neither would content that uses
.globalStorage, .forms, .querySelector or anything else that's not in
the SVG Tiny spec.
We're trying to make a new API here, of course content that uses that
API isn't
Anne van Kesteren wrote:
Currently XMLHttpRequest Level 2 has restrictions on getting response
headers when doing a cross-site request. I have a feeling these may be
an artifact of the slightly older model.
getAllResponseHeaders() returns the empty string currently.
Jean-Yves Bitterlich wrote:
A few alternatives were proposed here, referred below as
(i) 'attribute NodeList childElements',
(ii) 'Node item(index)' and
(iii) xpath .querySelector.
I personally like (iii) because it is powerful (or is it just queries
that are powerful?), however it
Travis Leithead wrote:
From your link, it appears the only reason this was dropped was because the
folks in discussion at the time thought the only use case for this feature was
Accessibility venders (ATs).
It wasn't just dropped because it wasn't needed (because AT doesn't need
to use DOM
Boris Zbarsky wrote:
Jonas Sicking wrote:
oldAddEL = EventTarget.prototype.addEventListener;
Node.prototype.addEventListener = function(type,
I should note that this wouldn't work in recent Geckos, by the way...
I think it might actually, since addEventListener isn't on the nodes
1 - 100 of 142 matches
Mail list logo
