«

On Sep 29, 5:43 am, timsamshuij...@gmail.com wrote:
> On Sep 28, 11:08 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > The biggest pain in writing a framework for widgets is positioning.
> > The second biggest is sizing.
>
> I am not experiencing any difficulties here yet. This is probably
> because I am not writing any general widgets that can be used
> anywhere. My widgets are used in my app environment where all elements
> are positioned absolute. My sizing, resizing, and drag routines are
> working fine, no pain yet. Or maybe you are referring to some
> difficulties that I have not yet encountered.

Try adding borders to the body or html elements. To compound the
problem, add margins to the html element. Then try to compute the
position of an absolute element in just the major browsers in
standards mode. I imagine you will need the viewport rectangle at
some point as well. Have fun with that.
>
> On Sep 29, 2:38 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > I started with the YUI libraries and tried to fix at least everything
> > that was wrong/less than optimal in my eyes.
>
> >http://forkjavascript.org
>
> > Peter
>
> I had a look at your code - great stuff! I had a look at your event
> routines to check whether my code is up to scratch (I am new to JS). I
> actually found your code "quite" similar to mine, which serves as a
> confirmation to me that I am on the right track. If I would have
> looked at your code previously then it would have saved me quite some
> work yesterday On the other had, in my opinion it is good to have
> written such stuff totally from scratch so that one fully understands
> the issues
> involved.
>
> For those interested, here is my (stripped) version of a simple event
> handler:
> (Comments, questions and suggestions are welcome)
>
> var TVSEvent = {
> Handlers: [],
> IndexOfHandler: function(aHandler) {
> var hidx = -1;
> for(var i = 0, length = this.Handlers.length; i < length; i++) {
> var hob = this.Handlers[i];
> if((hob.Handler == aHandler) || (hob.DOMHandler == aHandler)) {
> hidx = i;
> break;
> }
> }
> return hidx;
> },
> Add: function(aNode, aType, aHandler, aScope) {
> var domh = aHandler;
> if(arguments.length >= 4) {
> domh = function() {
> return aHandler.apply(aScope, arguments);
> }
> }
> this.Handlers[this.Handlers.length] = {
> Handler: aHandler,
> DOMHandler: domh
> }
> if(aNode.addEventListener) {
> aNode.addEventListener(aType, domh, false);
> } else if(aNode.attachEvent) {
> aNode.attachEvent('on' + aType, domh);
> }
> return domh;
> },
> Remove: function(aNode, aType, aHandler) {
> var domh = aHandler;
> var eidx = this.IndexOfHandler(domh);
> if(eidx >= 0) {
> domh = this.Handlers[eidx].DOMHandler;
> this.Handlers.splice(eidx, 1);
> }
> if(aNode.removeEventListener) {
> aNode.removeEventListener(aType, domh, false);
> } else if(aNode.detachEvent) {
> aNode.detachEvent('on' + aType, domh);
> }
> }
>

You should feature detect once and be done with it. And if you are
going to write a wrapper for event handling, you should smooth out the
basic differences between the two models. It doesn't make sense to
normalize everything for every event (like most libs do), but at least
pass along the event object and fix "this" handling for IE.

On Sep 29, 10:07 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Sep 29, 5:46 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Sep 29, 7:42 pm, "Richard Maher" <maher...@hotspamnotmail.com>
> > > I agree with all of the above but to be fair to the OP hasn't technology
> > > such as AJAX, in some ways, turned the clock back and created a hybrid by
> > > merging the web and client/server paradigms? There are people, certainly
> > > within this group, who'll contend that if it doesn't have a SUBMIT button
> > > then it's not a browser application. Others, myself
>
> > I'm not sure I follow, but a form without a submit button is a bad
> > idea.
>
> Are you sure it is *always* a bad idea?

Unless it isn't really a form (eg input elements that never submit
anything), in which case you can remove the form element, or if the
form is hidden for use with Ajax, IFrames, etc. I was talking about
forms that are used as forms by users. No submit button means that
some browsers will never submit the data (no matter how many times you
hit the enter key.)

>
> > included, can see
>
> > > browsers as the run-time environment for a genre of "new" lightweight
> > > client/server applications.
>
> > Yes, but light is relative. The OP proposal is too light, wasting the
> > capabilities of the browser and PC.
>
> Ironically, "too" light is also relative.

That's the point. The method described is relatively lighter than
Ajax applications.

>
> I'm not sure how you can make such categorical statements with such
> confidence. Different situations require different approaches and to
> throw away options a priori seems like a less-than-optimal choice.

What occasion requires turning a browser into a dumb terminal? Makes
no sense to me. Most of the world threw away dumb terminals decades
ago.