Use HTMLElement static methods with string-id as first parameter

[GoogleCodeExporter]

now: 
  HTMLElement.addClass(document.getElementById("some_id"),"selected");
idea, also support strings:
  HTMLElement.addClass("some_id","selected");

This would make the API much more clean, because we eliminate another potential 
use of the $-
method.

Original issue reported on code.google.com by doek...@gmail.com on 13 Jun 2007 at 1:30

[GoogleCodeExporter]

Let me think about it... :-)

Original comment by dean.edw...@gmail.com on 19 Jun 2007 at 7:12

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I'm still not sure about this. I have added some sugar to other static methods 
so
there is a precedent. If I do add it then how about allowing a CSS selector 
instead
of an ID?

e.g. HTMLElement.addClass("body", "enabled");
or   HTMLElement.addClass("#content", "enabled");

Thoughts?

Original comment by dean.edw...@gmail.com on 10 Jul 2007 at 3:00

• Changed state: Accepted

[GoogleCodeExporter]

CSS selector seems better. Makes you almost wish for a css literal (like there 
is a regex literal). Which "other 
static methods" are you talking about?

Maybe when I've played with JST, I have more thoughts ;-)

Original comment by doek...@gmail.com on 10 Jul 2007 at 9:30

[GoogleCodeExporter]

> Which "other static methods" are you talking about?

EventTarget.addEventListener() allows you to change the context of an event 
handler.
I'm thinking of getting rid of this though.

Original comment by dean.edw...@gmail.com on 10 Jul 2007 at 9:36

[GoogleCodeExporter]

Maybe it's an idea to create some seperate helper functions instead of classes?

Original comment by doek...@gmail.com on 11 Jul 2007 at 1:21

[GoogleCodeExporter]

I think that might be the way to go. We can also add "$" etc which people seem 
to
like. I'm thinking of putting all the sugar in JSB. I'd prefer base2.DOM to only
add/fix standards support.

Original comment by dean.edw...@gmail.com on 11 Jul 2007 at 2:14

[GoogleCodeExporter]

Are you actually planning XML DOM support?

Original comment by doek...@gmail.com on 11 Jul 2007 at 5:33

[GoogleCodeExporter]

Original comment by doek...@gmail.com on 14 Jul 2007 at 7:08

• Added labels: Browser-All, Module-base2.DOM

[GoogleCodeExporter]

What kind of XML DOM support?

Original comment by dean.edw...@gmail.com on 23 Jul 2007 at 9:07

[GoogleCodeExporter]

I'm busy with an WebDavFileSystem. I use XmlHttpRequest for that. And the 
xmlResponse object is not really 
consistent across browsers. I haven't used the methods, but "localName" is not 
implemented by IE6, and the 
nodeType-constants are not implemented by Safari2, IE6 and Opera9. Further, 
some properties return null in 
one browser, undefined in the other and an emtpy string in the third 
(nodeValue, prefix, namespaceURI).

But I don't like XML querying, so I'm actually writing a xml2js converter. 
First one following the Parker-
convention, and later maybe one with BadgerFish convention.

Original comment by doek...@gmail.com on 23 Jul 2007 at 9:36

[GoogleCodeExporter]

If you are talking about the XmlHttpRequest object then I do intend to fix 
that. Want
to make a start?

Original comment by dean.edw...@gmail.com on 23 Jul 2007 at 1:08

[GoogleCodeExporter]

I'm closing this bug. I don't want these kinds of shortcuts in base2.DOM. 
Standards only.

I'm hoping that JSB will provide the sugar on top of base2.DOM.

Original comment by dean.edw...@gmail.com on 27 Jul 2007 at 10:38

• Changed state: WontFix