I've written some commentary on the Selectors API draft on WebGraphics.
uri:http://web-graphics.com/2006/05/12/javascript-and-selectors/
--
David liorean Andersson
uri:http://liorean.web-graphics.com/
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 suggest raising
transformations, overlays, most
client side manipulation, if you want to write your own Selectors API
for kicks, there are many cases where you are only interested in the
elements tree.
--
David liorean Andersson
for XML processing, generation or editing, I'd
agree. But for browser scripting this ability to entirely ignore
non-element content is very useful.
--
David liorean Andersson
will return the URI to the
page.
On Jun 4, 2007, at 5:45 PM, liorean wrote:
Seems to me like they are simply using the ECMAScript ToString
algorithm, unless I'm mistaken. That's probably a good thing to
specify for this, too.
On 05/06/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I think DOM
, liorean wrote:
Well, IE doesn't throw INDEX_SIZE_ERR, the others do, so I guess there
is that compatibility argument.
On 05/06/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
IE's DOM behavior is so divergent from the standard in so many areas
that most sites and JS libraries have two separate code
liorean:
(The ECMAScript built-in constructors all follow the pattern of having
[[Call]], so their [[Class]] is Function instead and their
[[Prototype]] is the initial Function.prototype. The DOM constructors
don't have [[Call]] so their [[Class]] should be Object instead. Or
some
say let the default take place. I.e. in ECMAScript
the this value would be the global object (window in browsers).
--
David liorean Andersson
On 26/06/07, Lachlan Hunt [EMAIL PROTECTED] wrote:
Lachlan Hunt wrote:
liorean wrote:
I think it wouldn't hurt to specify that an exception should be
propagated (or rethrown?) out to the caller.
Surely, if it were necessary to state that, it should be in DOM Level 3
Core where
.
--
David liorean Andersson
to the Element interface:
* getElementsByClassName
Does this make sense on Element? I mean, the class attribute and it's
semantics are HTML/XHTML specific.
--
David liorean Andersson
been changed.)
I think ES4 will make the standard library global constructor object
bindings {ReadOnly, DontDelete}, but IIRC there's been some discussion
that it might break more scripts than it helps, so it might not
happen.
--
David liorean Andersson
extension that only makes sence on elements
and not on any other nodes - element-rooted instead of
subtree-only-but-document-rooted queries. (I don't see any real
benefit from such an interface though, but I've seen the idea
mentioned on the mailing lists.)
--
David liorean Andersson
:46 AM, liorean wrote:
I can actually imagine one extension that only makes sence on elements
and not on any other nodes - element-rooted instead of
subtree-only-but-document-rooted queries. (I don't see any real
benefit from such an interface though, but I've seen the idea
mentioned
feature was
seen as inappropriate, and something that shouldn't be used for node
creation in the DOM.
--
David liorean Andersson
that implement either the Document, Element
or DocumentFragment interfaces.
Why not Entity and EntityReference as well? Both types can parent
nodes in a similar way to DocumentFragment.
--
David liorean Andersson
with too few arguments is handled as if the missing arguments
were filled in with ECMAScript undefined, which would cause a
TYPE_MISMATCH_ERR exception to be thrown (unless the DOM interface
explicitly allows Undefined I guess...).
Is that a reasonable behaviour for the DOM as well?
--
David liorean
of a prototype object will always be looked
up before that member will be looked up in it's own prototype object.
--
David liorean Andersson
18 matches
Mail list logo
