Cameron McCormack wrote:
It seems to be possible to send a Document using XHR where the encoding
specified by the Content-Type charset parameter differs from the actual
encoding used to encode the serialisation.
For what it's worth, this got changed from Gecko 1.8 to Gecko 1.9.
Firefox 3
The section on maxlength in http://www.whatwg.org/specs/web-forms/current-work/
(the 12 October 2006 version) says nothing about what happens if script on the
page (or script from a bookmarklet, whatever) does:
myInput.value = some long string;
where the string length is longer than
Ian Hickson wrote:
The spec scatters the definitions around a bit (this will be solved
when WF2 is merged with the rest of HTML5, and is a legacy of the diff
design of the spec as opposed to a self-contained spec) but actually this
is defined in the DOM section:
Ah, excellent. Many thanks.
Ian Hickson wrote:
- by default, content in sandboxed browsing contexts, and any
browsing contexts nested in them
How do those nested browsing contexts come about, given that later you say:
- content in those browsing contexts cannot create new browsing
contexts or
Kristof Zelechovski wrote:
1. Nested browsing contexts in a sandboxed frame cannot be created
dynamically but they can be defined by the inner markup.
There was no mention of dynamically in Ian's proposal. My assumption
was that cannot create browsing contexts meant just that. If it
Simon Pieters wrote:
FWIW, this is defined for getting innerHTML in XML:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dynamic.html#innerhtml1
That's more like what I was looking for, yes. I would be happy if XHR adopted
that approach.
-Boris
Sunava Dutta wrote:
I think you mean compatible with browsers who enable
the technologies when you mean compatible with the web?
Compatible with the web means that when a UA implements the specification as
written it will encounter either no reports of pages broken due to that
Julian Reschke wrote:
For this one I used Dom L1 methods to create this document:
foox:y//foo
which isn't XMLNS-wellformed.
I'm not sure I see the problem here, to be honest... Using the
non-namespace-aware DOM methods one can indeed create documents that require a
non-namespace-aware
Julian Reschke wrote:
Since the UA has no idea what sort of XML parser is being used on the
server side, I'm not sure it makes sense to bail on attempts to
serialize such documents. In particular, if the document _is_ parsed
with a non-namespace-aware XML parser, there is no problem.
Bjoern Hoehrmann wrote:
Being able to send wf-but-ns-illformed documents would not make much
sense if you couldn't also read them back in
Which you can, with a non-NS-aware XML parser.
and the odds that some
wf-but-ns-illformed has been created deliberately for use with XHR
as opposed to
Julian Reschke wrote:
Yes, I noticed that. For instance, it happens for application/..+xml,
where it's really useless. Shouldn't this be restricted to text/*?
That could perhaps be done. The initial implementation just does it no matter
the MIME type so as to avoid making assumptions about
Julian Reschke wrote:
This assumes that every non-text/* mime type *can* take a charset
parameter, which IMHO is not true.
But this probably only becomes relevant once we have non XML/string
based ways to set the body.
For what it's worth, Mozilla does have such a way (only available to
Ian Hickson wrote:
I propose that we change the spec to explicitly say that if you call insertNode() on a
collapsed range, the end point offset is increased by one
Increased at what point in time, exactly? Specifically, if there is a
DOMNodeInserted listener that repositions the range when
Ian Hickson wrote:
DOM2 Range doesn't define anything to this level of detail yet,
unfortunately.
Indeed. The wonders of Conway's Law...
Nevertheless, this question is somewhat important in terms of deciding where the
range should be positioned.
For example regular old insertions and
João Eiras wrote:
1) How do we deal with node.querySelectorAll(foo) ?
That's come up on the list before, for what it's worth. Still undecided.
2) How should following pseudo-classes be handled?
:hover - make this use case clear. Should hovered element be matched,
or the class ignored ?
Scott Shattuck wrote:
This is possible today on IE and Mozilla with a single user-visible
security prompt.
That's only the case in Mozilla if:
1) The script is running at a file:// URI
or
2) The user has changed a hidden preference to allow random
sites to put up this prompt.
or
Scott Shattuck wrote:
1) The script is running at a file:// URI
I believe it's key that future specification work keep in mind that this
isn't the rare case it used to be, it's one definition of run offline.
While true, note that Gecko also supports actual running offline of http URIs,
Scott Shattuck wrote:
I'm not trying to be difficult, far from it. I'm just trying to truly
understand where you see things headed in this regard.
It's still in flux, but there's a general goal to not have ways for sites to
have expanded privileges. If you have use cases that require those,
Lachlan Hunt wrote:
I have updated the editor's draft to define a single NodeSelector
interface that is implemented by Document and Element nodes.
You can review the changes in the latest editor's draft.
http://dev.w3.org/2006/webapi/selectors-api/#documentselector
Please let me know
Lachlan Hunt wrote:
WebKit:Throws SYNTAX_ERR for both
For what it's worth, this is what Gecko's implementation currently does as well.
IE 8 Beta: Returns null or empty NodeList
Opera: Returns null or empty NodeList
What do they do if there is an element named null in the document?
Cameron McCormack wrote:
But the method signature in IDL is DOMString. So by the time it sees the
argument, it will be a DOMString. The only question is which DOMString.
Because DOMString is defined as:
typedef DOMString valuetypeunsigned short;
then the null value should be one of the
Subbu Allamaraju wrote:
The example in this section uses responseXML.getElementById(), which
AFAIK, can not work.
Why not? I'd expect it to work any time there's an element with an attribute of
type ID which has that value... Certainly in Gecko this should be the case.
-Boris
Subbu Allamaraju wrote:
Have you tried?
Yes. Have you? Here, just to help you out:
test.xhtml:
html xmlns=http://www.w3.org/1999/xhtml; id=one/
test.html:
script
var x = new XMLHttpRequest();
x.open(GET, test.xhtml, false);
x.send();
alert(x.responseXML.getElementById('one'));
/script
Lachlan Hunt wrote:
From my reading of the Selectors grammar, that certainly does seem to
be the case (but someone please correct me if I'm wrong).
That's my reading too.
2. Ask the CSS WG to modify the grammar of Selectors to allow leading
and trailing space.
3. Add a requirement to
Subbu Allamaraju wrote:
The difference is the xmlns declaration. The example requires an XHTML
resource to work.
Here's a test.xml which has no XHTML or indeed any namespace usage and still
works with the test.html from my last mail:
!DOCTYPE root [
!ATTLIST root identifier ID
João Eiras wrote:
But then getComputedStyle is simultaneously
affected by this issue, so either the behavior for both APIs has to be
specified
Yes, of course. There are proposals to this effect for getComputedStyle.
-Boris
Travis Leithead wrote:
To recap your proposal:
* :link - matches all links (essentially document.links, but without the href
constraint)
Without the href constraint?
-Boris
Lachlan Hunt wrote:
If I add the following paragraph to the security section, would this
adequately address this issue?
If, at any time, the implementation detects a situation which would
violate security policies, the implementation MAY abort and raise a
security exception.
That would
Jonas Sicking wrote:
1. Parse selector
2. Walk the DOM and create result using parsed selector.
That seems like the obvious approach.
This way it is ok if the NSResolver mutates the DOM in any fashion. The
result returned from the function will simply be based on what the DOM
looks like
Jonas Sicking wrote:
So this generally can't happen, except through implementation specific
quirks, no? I.e. a page can't create an NSResolver mutates nodes to the
point where it no longer has access to the page.
Sure it can. Setting document.domain will do the trick, easily.
-Boris
[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
[ccing the right list for this, and setting reply-to]
Nicholas C. Zakas wrote:
The try-catch statement does carry overhead with it in terms of an additional
scope. If you're doing a bunch of queries and you need to surround each of
them with a try-catch, it can affect performance (see
[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 =
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
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
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
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
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
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 =
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
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
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
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
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.
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
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
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
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
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
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
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
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
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:
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...
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
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
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
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
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
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
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
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
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;
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
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
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.
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
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,
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
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
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
1 - 100 of 131 matches
Mail list logo
