Ian Hickson wrote:
3) Forbid any non-presented Document to implement DocumentWindow (seems too
restrictive).
I am strongly in favour of 3. If we don't do 3, we're going to have to
require a whole heck more than 1 -- we're going to have to special case
every single API that requires a
Sjoerd Visscher wrote:
No, a synchronous XMLHttpRequest does not block the running javascript
thread.
I'm not sure what you mean by that, actually. It block execution of the script
in which the call was made.
But it will therefore also not block the onclick handler
It'll block it in
Maciej Stachowiak wrote:
We do that in Mac OS X Mail too, but each attachment is effectively a
subframe, and so gets its own Window object. Does Thunderbird give all
the attachments a single Window object?
It does.
(Does it even matter, since scripting is presumably off for all email?)
Maciej Stachowiak wrote:
So what does the document property of the Window return, if you have
multiple documents with a single window?
There's actually a simple document; I believe Thunderbird just concatenates all
the HTML or something weird along those lines.
-Boris
Boris Zbarsky wrote:
There's actually a simple document;
I meant single...
-Boris
Maciej Stachowiak wrote:
The name set by window.open persists across document loads normally,
and this seems analogous.
True, but there the name is set by the thing that owns the window, in some
sense
Can you think of a way the existing browser behavior might be exploitable?
Well,
Julian Reschke wrote:
Bizarre.
Why not just leave the value alone?
The value is atomized; the atom hashtable uses case-insensitive lookups.
-Boris
Jonas Sicking wrote:
One argument is that it's simply impossible to work around an XHR
implementation that changes the casing in a way that the server doesn't
expect. For example if the server wants a 'doit' method and the XHR
implementation case folds to uppercase, the script author will
The documentation for the |uri| argument to XMLHttpRequest.open says:
A URI, which MUST be resolved to an absolute URI using the script's context
window.location.href value as base if available.
What is the script's context exactly? It's not defined in the spec. Assuming
we limit
Brad Fults wrote:
Agreed. Also, I think the what if someone uses a good property name
for a lame implementation isn't as much of a concern because we're
talking about major browser vendors, not any random paster.
Are you talking about the same browsers we've been living with for the last 12
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
Anne van Kesteren wrote:
That bug talks about making the document empty, instead of returning
null as the specification says.
Those comments predate the specification, no?
Is it the plan to follow what the specification says or does it need to
be changed for the above reason for example?
Gorm Haug Eriksen wrote:
Btw, I found two strange behaviours while looking at it now. It seems
like the onprogress event is one cycle before responseText.length.
The interaction between the two in Gecko is undefined and subject to change.
Also, strange things seems to happen if the
Julian Reschke wrote:
Well, what I'm concerned with is form.submit() and XHR/PUT/DELETE in
things like onload events.
Yes, I'm aware of your position. My mail was a response to a specific statement
that Charles made, not a general response to the whole thread.
-Boris
Anne van Kesteren wrote:
What do implementors and authors think of having more optional method
arguments in the DOM where that makes sense?
I frankly think it's a bad idea. For UA-provided objects, it significantly
increases the implementation complexity. Since the IDL used can't express
Jim Ley wrote:
In ECMAScript DOM's definately, anything that accepts null should
definately work if a user doesn't explicitly define null, because ES
authors expect functions to behave that way, with all non-passed
functions simply set to undefined.
undefined and null are not at all the
Jim Ley wrote:
You're argument that a library would be difficult to write, it's easy
for a library not to use ===, so that's a rather strange argument.
My point was that there are suddenly all sorts of gotchas involved in writing a
library if you allow this sort of thing.
It's part of the
Anne van Kesteren wrote:
Basically, from the window you contruct the object in
How is that defined? Is it possible to take window1.XMLHttpRequest and use
apply() to call it with window2 as |this|? In that case, which window was the
object constructed in? Or is the window you construct
Anne van Kesteren wrote:
How is that defined? Is it possible to take window1.XMLHttpRequest
and use apply() to call it with window2 as |this|?
...
Sorry, it's the window from which you use the constructor.
That doesn't answer my question above. It just shifts the burden onto defining
Anne van Kesteren wrote:
On Fri, 22 Sep 2006 16:41:12 -, Boris Zbarsky [EMAIL PROTECTED] wrote:
That doesn't answer my question above. It just shifts the burden onto
defining what the window from which you use the constructor means.
Can you point out the problem in that definition
Jim Ley wrote:
It's a host object the apply is undefined in ECMA, so I see no reason
for the WEB API's WG to define it more than ECMA does.
Unless you want better interoperability than ECMA provides, of course. Which I
do.
I would encourage you to simply not support apply on such host
Maciej Stachowiak wrote:
You can't use apply with new. What part of the spec says you can?
I haven't been able to find the part of the spec that addresses this at all. So
the question could also be posed as What part of the spec says you can't? And
apply is just an example; I don't know
Maciej Stachowiak wrote:
I agree the definition should be clear, I'll try to review the existing
one and suggest more precise wording if needed.
Awesome. Thanks!
-Boris
Subbu Allamaraju wrote:
The current draft says that
If the url parameter doesn't match the syntax defined in section 3.2.2
of [RFC2616 http://www.w3.org/TR/XMLHttpRequest/#RFC2616] a
|SYNTAX_ERR| /must/ be raised
So does that mean that UAs MUST NOT support any non-HTTP schemes?
-Boris
Web APIs Issue Tracker wrote:
ISSUE-96: What happens if a Node StaticNodeList points to no longer exists?
Isn't the right solution to make sure the node cannot start existing while the
StaticNodeList exists? The spec should document this, imo.
-Boris
Anne van Kesteren wrote:
FWIW, the current editor's draft says that user agents must pass the
prefix argument lowercased (A-Z becomes a-z) to the lookupNamespaceURI
method of the NSResolver object or ECMAScript function. This should
solve this issue.
Doesn't that make it impossible to match
Ian Hickson wrote:
Selectors are case-insensitive; thus there can't be an uppercase prefix.
Ah, I think I had misunderstood the context for Anne's mail.
Thanks for the clarification,
-Boris
The draft does not indicate what happens to the readystatechange listener when
the request completes. If another request is then dispatched using the same
XMLHttpRequest object, does the readystatechange listener persist?
Gecko's behavior right now is to clear all event listeners (including
Charles McCathieNevile wrote:
3. Add an uploadprogress
It is possible to construct an XHR that is moving content up and down at
the
same time, so knowing when progress refers to one or the other is useful.
uploadprogress is a separate event one can listen for, right? So there are
João Eiras wrote:
If I'm downloading say 50kb, how many times will the progress event fire
? Now if I'm downloading 1MB how many times will it fire ?
I doubt it'll fire every byte, else listening for this event will
consume enormous amounts of cpu. I too doubt it'll fire every kilobyte,
else
Jim Ley wrote:
up to 54ms is used by other browser vendors in similar situations
I'd be interested in further information on this. We (Mozilla) found
that using anything bigger than 10ms (due to a problem in the timer impl
we were doing 16ms for a while) led to a lot of angst on the part
Robert Sayre wrote:
MSDN says it returns the first object.
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/getelementbyid.asp
For what it's worth, that's not what Gecko does, and I personally would
rather not try to enforce that -- it's somewhat expensive to do so in
the
Bjoern Hoehrmann wrote:
Note: .foo(#id) is not equivalent to document.getElementById('id')
if multiple elements have the same ID. This method returns the first
element in document order with the given ID, while getElementById's
behavior is undefined in this case.
I would like to put
Maciej Stachowiak wrote:
i.e. if you have a transfer-encoding or content-encoding, do you count
the transfer size before or after you are unpacking?
Seems to me that it makes more sense to count the data with the
relevant encodings applied - i.e. the number of bytes being pushed over
the wire
Maciej Stachowiak wrote:
Out of curiosity, has Mozilla already shipped a product that has the
uploadprogress event?
Not yet. It's been present in development builds of Gecko 1.9 for a
while, but not in anything shipped.
I suspect we'll just remove it in favor of the new setup, but wanted
Charles McCathieNevile wrote:
If this is added, should the list be live or static? I am inclined to
make this a static element list, a la the Selectors spec, since it
is intended to be a lightweight interface
Why does that make it more lightweight? Is that from an implementation
standpoint,
Stewart Brodie wrote:
Aren't those DOM events handy? Just what you need to keep these data
structures up to date. It sounds like you do exactly the same as me :)
Yeah, with a capturing DOM event listener on the root you could basically get
the notifications you need. Gecko doesn't
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 Firefox.
That's correct.
Ian Hickson wrote:
Quite frankly, I don't see how point 4 is compatible with the real
world.
...
I've broadened the allowances in the spec. How about now?
Now it effectively says UAs do whatever they want. Compatible with the real
world, and existing UAs, sure. Not that useful to future
Ian Hickson wrote:
And this doesn't really address the concern I raised about window.name
(and window targeting) seeing names set by some other site when it
opened you in a popup...
That wasn't what the bug was about; could you elaborate on this concern
further? I'm not sure I remember
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 interfaces an object
implements onto the closest
Maciej Stachowiak wrote:
I'm not even sure if it's intentional that global constructors in Mozilla have a
function-valued property named QueryInterface, or just an
implementation artifact.
It's an implementation artifact.
-Boris
Cameron McCormack wrote:
I wondered that myself, but it would help the case where script authors
want to mess about with the prototypes of various objects. Perhaps it
doesn’t need to be specified exactly, but with enough fixed down such
that you could reliably assign to
liorean wrote:
Is this the reason for:
var
div=document.createElement('div'),
span=document.createElement('span'),
text=document.createTextNode('What am I?');
Function.prototype.call.call(div.appendChild,span,text);
text.data+='\r\n'+text.parentNode.tagName;
Carsten Orthbandt wrote:
The (IMHO) valid reason here is:
- redundant header overhead
- the UA isn't even meant to interpret the response, so it doesn't need
any information on how to parse it
Actually, you're expecting the UA to convert the bytes in the response into
characters in this
Nicolas Mendoza wrote:
Specifically, with Mozilla Firefox, CSS style attributes from external
stylesheets are applied to the DOM tree before DOMContentLoaded is
fired.
In Mozilla DOMContentLoaded is fired when the end of the document is parsed (the
/html in HTML documents).
Depending on
Nicolas Mendoza wrote:
Try adjusting the timeout:
http://people.opera.com/nicolasm/test/domcontentloaded.html?timeout=10
http://people.opera.com/nicolasm/test/domcontentloaded.html?timeout=60
That test has a script after the link. Since scripts sometimes depend on
style information being
Oliver Hunt wrote:
* preventDefault on KeyDown will *not* prevent KeyPress events from
being fired (this matches Firefox behaviour, and is needed for a couple
of sites)
Actually, that doesn't match current Firefox behavior. But Firefox behavior
changed between Firefox Firefox 1 and 1.5 on
Oliver Hunt wrote:
Really? By my testing it matches Firefox 2 behaviour on both mac and
windows.
IE behaviour results in the keypress not being fired.
Oh, I see. Firefox behavior is to fire the keypress event but to call
preventDefault() on it first, so that the default action doesn't
Dan Connolly wrote:
function handler() {
alert(@@ handlder state, status: + this.readyState + / +
this.status);
}
client.onreadystatechange = handler;
and I get undefined for this.readyState and this.status.
I'm using firefox 2.0.0.6 on ubuntu linux.
In Gecko 1.8 (Firefox 1.5 and
Stewart Brodie wrote:
Out of curiousity, why has event.target not always been the XMLHttpRequest
object (in Gecko)? Was it simply an oversight?
onreadystatechange used to not be a DOMEventListener, and therefore the setup
that goes into making the call into a DOMEventListener wasn't really
Simon Pieters wrote:
HTML5 says that all Document objects must implement HTMLDocument and
other supported interfaces. I presume it says so in order to dodge the
question of when to implement which interface
And also because when using mixed-namespace documents it really does make sense
to
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 access (not allowed), unknown schemes (only
same-origin with
Bjoern Hoehrmann wrote:
The URLs are equivalent, if you send different Host headers, that's your
choice, but it's neither required nor otherwise necessary. As an example
Internet Explorer 6 will not send the default port in the Host header
For what it's worth, neither will Gecko. It will
Asbjørn Ulsberg wrote:
On Wed, 29 Aug 2007 09:03:05 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
P.S. If we do want to specify what an origin is we should perhaps
also think about URI schemes that do not have a host and port.
Can't we just reference RFC-3986, section 6.2.2 and 6.2.3?
I
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 same-origin checks...
Anne van Kesteren wrote:
Thanks Boris, Jonas and Maciej for your replies.
http://dev.w3.org/2006/webapi/XMLHttpRequest/Overview.html#same-origin
It would be nice to get some implementation feedback on what to do about
data:, javascript: etc.
If you're going to refer to RFC 3987, you
Maciej Stachowiak wrote:
I'm not sure offhand if baseURI is the right way to determine the
security domain.
It definitely isn't, for the reasons you list.
-Boris
Anne van Kesteren wrote:
Thanks. So it say the that the origin of the Document object associated
with the Window pointer is the origin of the request. With a reference
to HTML5 to see what the origin of such a Document object actually is.
Or should it simply be the origin of the script?
Anne van Kesteren wrote:
Yes. If I get all this stuff correctly a script could be running on
bar.com using the XMLHttpRequest from another frame which is on
foo.bar.com. Depending on which definition is used it can either access
bar.com or foo.bar.com content (but not both), right?
Anne van Kesteren wrote:
Hmm, actually, per HTML5 it seems that's impossible because the origin
of bar.com and foo.bar.com are not the same and therefore you can't
access any members of foo.bar.com from bar.com or vice versa.
document.domain can change this I suppose
Exactly.
but doesn't
Hallvord R. M. Steen wrote:
Note that document.domain (when set by both source and target frame)
also lets you ignore port and protocol differences, which once again
is not desirable for XHR.
I know we ignore port differences but I don't think we ignore protocol.
That's Gecko's behavior
Mike Wilson wrote:
The history of web browsers have been about getting new things done, so I
think there could be other vendors also not rushing to fulfill step (2)
but instead waiting for (3).
As far as I am aware, Opera, Safari, and Mozilla are all planning to implement
this specification
Boris Zbarsky wrote:
I rather question whether there are actual use cases for this that
justify the complexity in an area of code (security checks) where
complexity and the attendant potential for bugs is to be avoided at all
costs.
Just in case this wasn't clear, consider this implementor
Ian Hickson wrote:
The only special case I can think of is getting an XML or HTML file parsed
into a DOM
Frankly, either the innerHTML thing or something like Gecko's DOMParser seems
like a much much better approach to this than hacking together XMLHttpRequest
with a data: URI that you then
On Mon, 19 Nov 2007 12:00:35 +0100, Stewart Brodie
[EMAIL PROTECTED] wrote:
In such a case of a window having been deleted, and consequently the
document within that window, what is the base URI? Is it the base URI of
the last document that inhabited the window?
The Window is not deleted.
Anne van Kesteren wrote:
Yes. I'm not sure why it would be removed. After all, the Window object
has references to it.
In Gecko, it doesn't necessarily after the window has been closed. There might
be a document property on the JSObject (or there might not), but the internal
pointer is
Ian Hickson wrote:
Yes; at least according to the current HTML5 draft. The spec currently
splits navigation from rendering, so iframes (and browsing contexts in
general) work the same mostly independent of their location.
I'm not sure we'll want to implement this in Gecko.
Is script
Bjoern Hoehrmann wrote:
Is it conforming for a UA to drop the body for GET requests?
Not as far as I can tell.
I'd like to request that this be changed, then. Otherwise you're effectively
requiring UAs to rewrite their HTTP layers to support entity-bodies with GET
requests (or switch to
Bjoern Hoehrmann wrote:
That same as would happen with a different method; while this is not
always conforming, all requests can have a body, and my recollection is
the Working Group decided to give no special treatment to GET requests.
If you want the request to have no body, you have to pass
Julian Reschke wrote:
So please let the HTTPbis WG worry about how to resolve this issue; and
do not step into areas not owned by this WG.
Absolutely agreed. That's all I was asking for: that the XMLHttpRequest
specification not make conformance requirements regarding bodies for GET
Julian Reschke wrote:
It's also inappropriate to require implementations not to send the body
when HTTP allows it. So how about staying silent about it?
Let me just recap the start of this thread:
Laurens Holst sent
http://lists.w3.org/Archives/Public/public-webapi/2007Dec/0008.html, which
Jim Ley wrote:
Could you describe the use cases for defining this at all?
Interoperability. Specifying that Window stringifies to [object Window]
is probably unnecessary (and not true in all UAs anyway). But
specifying that, Location stringifies to its .href property is needed
(and is
* It's not clear what the DOM3Core reference at the end of the first
paragraph is there for. Is that a reference for the Document and
Element interfaces? This could use clarification.
* It's not clear which IDL, if any, is being used when defining the
DocumentSelector and ElementSelector
Bjoern Hoehrmann wrote:
* What is the expected behavior of lookupNamespaceURI when a null
DOMString is passed in? Should it match the behavior when an empty
string is passed in?
A bug report would be the appropriate course of action
That doesn't actually help define the behavior, though.
Sergey Ilinsky wrote:
the xml prefix is an exception whose
namespace doesn't need to be defined explicitly.
This is true in XML, but that's not the case in Selectors, and it's not obvious
that it should be true for this API.
For example, the following document:
html
Lachlan Hunt wrote:
* It's not clear what it means for a group of selectors to be
invalid. Does the term mean that the group of selectors is not
tokenizable according to the CSS grammar? Or that there are
unrecognized simple selectors or combinators in the group? Or both?
How should
Boris Zbarsky wrote:
has the must in lowercase and red text, whereas all other MUSTs I see
are uppercase and a different font from the rest of the text.
There are similar issues in section 2.1, in the text starting:
While resolving either a prefix or the default namespace
Lachlan Hunt wrote:
* What is the expected behavior of lookupNamespaceURI when a null
DOMString is passed in? Should it match the behavior when an empty
string is passed in? Note that in ECMAScript, for example, the tests:
This is not an interoperability concern because the NSResolver
Lachlan Hunt wrote:
I have now defined conformance requirements to handle all possible
input, and stated that implementations that are implemented by the
application instead of the user agent have specific requirements
relaxed.
That looks great. Thank you.
-Boris
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 things that don't match a conforming
Lachlan Hunt wrote:
I can modify the spec to require that, I just need to figure out the
best way to write it. But then I don't think there is anything special
an implementation would need to do to deal with the a misbehaving
resolver (beyond what the spec already requires for unexpected
Is there a reason to have identical interfaces called DocumentSelector
and ElementSelector that are identical? Would it not make sense to just
define a NodeSelector or something and require Document and Element
nodes to implement it? The confromance requirement could be easily
stated in
I've been thinking about this some more, and the requirement that the
caller be able to tell apart the NSResolver returning a String and some
other object that has a toString() method is actually a bit of a pain.
For example, in Gecko a C++ caller into this API would just get back a
string
Anne van Kesteren wrote:
The reason for two interfaces is to allow extensions to either going
forward. Though presumably for ECMAScript you can implement them however
you'd like as window.ElementSelector and window.DocumentSelector should
probably not exist. (Just prototype Element/Document
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 it doesn't seem like the
DocumentFragment case would be
liorean wrote:
As a disconnected node would not be in the node tree from document,
can it match a query at all?
That's a really good question! It seems to match in the webkit nightly
I just tried here, as well as in IE8. Simple testcase:
javascript:var n =
Jeff Schiller wrote:
Fx3 does not allow you to do this:
setting a property that has only a getter
That's because per the spec document.domain is readonly. See
http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGDocument.
There is a workaround in place for HTML documents (even though the
Ian Hickson wrote:
Webkit is correct. The Selectors spec defines :root as:
The :root pseudo-class represents an element that is the root of the
document.
OK. It wasn't obvious to me whether that was because people hadn't considered
matching against disconnected subtrees or whether
www-style: the discussion is about the :root selector in the Selectors
specification.
Yeah, it really should say a document.
That doesn't solve the problem, in some ways, since it might mean that multiple
nodes being rendered in the same window match :root, depending on what
transclusion
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
NodeSelector. Just that whatever nodes
Anne van Kesteren wrote:
If :scope needs to work matching in implementations might need to change
by the way. Currently matching is only against the subtree. So
div.querySelector(div) would only match descendant div elements.
I see no reason for this to change with :scope introduced, to be
Doug Schepers wrote:
Speaking as an author of many SVG Webapps and a contributor to several
SVG script libs, knowing the number of child elements is a really common
need; index-based access is less needed, and can be effected by other
means.
I would just like to point out, from my
Henri Sivonen wrote:
The childNodes feature seems to have caused a lot of
complexity in DOM implementations
Really? What sort? I'm only familiar with the Gecko implementation here, but I
don't see it causing extra complexity there...
The Selectors API, for example, returns comatose
Henri Sivonen wrote:
I'm not claiming it would be awfully hard, but it does change the impact
of Element Traversal from adding four or five methods on an existing
class (mere code footprint; super-simple)
That depends on what performance characteristics callers expect or UAs want to
Henri Sivonen wrote:
Allowing app code to index into platform
structures that are most commonly forward-iterated seems like an
anti-pattern in terms of what implementation constraints are placed if
the impression that the app developer gets is that indexing has the
performance properties of
Close, Tyler J. wrote:
I think Eric's point is that the client specified Content-Type header cannot
be trusted to accurately describe the content, so the server must parse the
content under the assumption that the header is misleading.
I don't think anyone is arguing about that.
There could
[moving this to the right mailing list]
Daniel Glazman wrote:
Oh come on. So to test if the childhood combinator is implemented
Why would you be testing that? What's the use case?
The way I see this working in practice is something like this:
var elements;
try {
elements =
[ccing the right list for this, and setting reply-to]
Garrett Smith wrote:
The point of debate seems to be whether or not throwing an error is
really a Good Idea.
No, the point of this debate is whether there needs to be a separate API for
determining selector support status, and if so why
1 - 100 of 131 matches
Mail list logo
