On Nov 18, 2008, at 9:32 PM, Gavin Kistner wrote:
I find these names rather cumbersome and not very self-explanatory.
Though it may be far too late for this suggestion, I would suggest
that they should be something such as:
findNode()/findNodes() or findNode()/findAllNodes()
selectNode()/se
I find these names rather cumbersome and not very self-explanatory.
Though it may be far too late for this suggestion, I would suggest
that they should be something such as:
findNode()/findNodes() or findNode()/findAllNodes()
selectNode()/selectNodes() or selectNode()/selectAllNodes()
findBy
Section 6 states:
"The querySelector() method ... must ... return the first matching
Element node ***within the node’s subtree***." [1]
"The querySelectorAll() method ... must ... return ... all of the
matching Element nodes ***within the node’s subtree***..." [2]
(Emphasis mine.)
In confli
On Nov 18, 2008, at 9:04 PM, Gavin Kistner wrote:
I recommend specifying a new derivative StaticNodeList type as the
return value. I do not recommend using an actual live NodeList, as I
agree with both the end-user usefulness and performance benefits of
not having a live NodeList.
Amusing
The second example in section 8 uses the following code:
var x = document.querySelector("#foo, #bar");
It goes on to rather explicitly state, "In the sample document above,
it would select the div element with the ID of foo because it is first
***in document order***" (my emphasis).
None
DOM Level 2 Core and DOM Level 3 Core both say:
"The NodeList interface provides the abstraction of an ordered
collection of nodes, without defining or constraining how this
collection is implemented. NodeList objects in the DOM are live." [1]
[2]
" NodeList and NamedNodeMap objects in th
The Selectors API document, section 8, has this example code:
var div = document.getElementById("bar");
var p = bar.querySelector("body p");
I assume that is supposed to be either...
var div = document.getElementById("bar");
var p = div.querySelector("body p");
...or...
var bar = docum
Hallvord R. M. Steen schreef:
If the header argument is in the list of request headers either use
multiple headers, combine the values or use a combination of those
(section 4.2, RFC 2616).
I think this needs to be way more specific. We probably need to verify
what existing UAs do for actual
Hi folks,
there is a new last call draft of the "Selectors API" spec:
http://www.w3.org/TR/2008/WD-selectors-api-20081114/
You are invited to review the document and send comments to
public-webapps@w3.org with "[selectors-api]" in the subject, through 12
December 2008. If you have pendin
Hallvord R. M. Steen wrote on 11/18/2008 6:50 AM:
> I think this needs to be way more specific. We probably need to verify
> what existing UAs do for actual header values, and make some sensible
> rules from that.
I saw this yesterday, it suggests using setRequestHeader() to replace the
default
Below is the draft agenda for the November 20 Widgets Voice
Conference (VC).
Inputs and discussion on the agenda topics before the meeting is
encouraged.
Logistics:
Time: 07:00 Boston; 13:00 Paris; 21:00 Tokyo
Duration = 60 minutes
Zakim Bridge +1.617.761.6200, conference 9231 ("WA
I've found a site that requires that any UA default value is overridden
with the new value when using setRequestHeader('Accept', ..).
(For reference: the site is mail.163.com, it uses XHR extensively to fetch
data and sets Accept header to "text/javascript" to fetch JSON content. If
that
Cameron McCormack:
> So, we probably need to keep requiring the spec using [NamedIndex] to
> specify in prose what the keys are. That should be sufficient to
> nominate operations to be the property creator/modifier/deleter
> handlers.
…
> Then the operations could still handle that common case o
13 matches
Mail list logo
