| Summary: | No prototype for elements | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | jordan.osete |
| Component: | kjs | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | maksim |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
I might add the mozillaish constructor object thing, but I can't think of any sensible way for the later construct to work or any reason for it to work the way you want it --- all this is setting is a fallback to a dynamic property, which is always there, just sometimes null, and hence is a no-op On Sunday 02 July 2006 18:11, Maks Orlovich wrote: > SVN commit 557310 by orlovich: Forgot to forward it to bugs... And note that this will probably need some additions to support everything, but they should be pretty easy... > > A bunch of DOM changes we'll need to support the new yahoo mail > and ATLAS stuff; this is neccessary but not sufficient, since they > also heavily use setters/getters, which I am not sure we want to support in > 3.5.x... (But this stuff is standalone) > > 1. Provide some emulation of mozillaisms like Node.prototype = ... . > These are incomplete, but should hopefully cover the important stuff. > Related to that, fix HTMLDocument to use a proper prototype. > > 2. Merge from Apple's tree: support the no-op debugger; statement, > it at least seems to be used by yahoo... > > 3. Readonly support for characterSet property. > > 4. Fix crash on reading some properties of mouse events that weren't > dispatched --- noticed on testing this stuff. > > > M +49 -0 khtml/ecma/kjs_binding.h > M +2 -0 khtml/ecma/kjs_css.cpp > M +2 -0 khtml/ecma/kjs_css.h > M +30 -74 khtml/ecma/kjs_dom.cpp > M +8 -12 khtml/ecma/kjs_dom.h > M +33 -51 khtml/ecma/kjs_events.cpp > M +1 -11 khtml/ecma/kjs_events.h > M +20 -21 khtml/ecma/kjs_html.cpp > M +2 -0 khtml/ecma/kjs_html.h > M +20 -2 khtml/ecma/kjs_window.cpp > M +3 -1 khtml/ecma/kjs_window.h > M +864 -841 kjs/grammar.cpp > M +57 -55 kjs/grammar.h > M +13 -0 kjs/grammar.y > M +1 -1 kjs/keywords.table > M +19 -1 kjs/lookup.h Thank you.
Actually, though prototypes are really useful, event inheritance might not be that much needed. I only proposed this because if it is not implemented, there can be some inconsistenties, for example if you try to define some event handler for anchors:
HTMLAnchorElement.prototype.onclick=function () {alert(this.href);};
It will not be activated when the user clicks on any link, BUT it will be activated if you try to simulate a click by doing, for example:
document.getElementsByTagName('a')[0].onclick();
Well, that is not that bad, just wanted to point the case.
As I said above, that does not make sense, since onclick is a dynamic property. Also note that we do not have pseudo-constructors for subclasses of HTMLElement. |
Version: 3.5.2 (using KDE 3.5.2, Debian Package 4:3.5.2-2+b1 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.15-1-k7 Actually, it is between bug and feature request. The default elements of a document (like HTMLElement, Element, etc.) should have an extendable prototype. If you add functions to the prototype, it should be added to elements. A very useful example (works in FF & Opera): HTMLElement.prototype.hasClass=function (className){ return true && this.className.match(RegExp('\\b'+className+'\\b'));} HTMLElement.prototype.delClass=function (className){ var c=this.className.replace(RegExp('\\b'+className+'\\b'), ''); var ret=(c!=this.className); if(ret)this.className=c.replace(/ {1,}/, ' '); return ret;} HTMLElement.prototype.addClass=function (className){ if(this.hasClass(className)) return false; else{ this.className=this.className+' '+className; this.className=this.className.replace(/ {1,}/, ' '); return true;}} Also note (related to bug 127236) that it should also work for events handlers, like that: Image.prototype.onload=function(){ alert ("image loaded, url: "+this.src);} No browser currently does that. Actually the best way to do it all would be to resolve the event handler only when it is called. Ie.: on click, check if the item has an onclick member, then if not, check if its prototype has one.